Trust: data, failures, streaming, and deployment

This page answers the questions reviewers ask before they route traffic through ValGuard. Where does data go? What happens when something fails? What does streaming cost? How do you evaluate without a local runtime? Where a limit exists, we state it.

Last reviewed: 2026-10-04.

Related: Security, Privacy, DPA, SLA, and self-host docs.

Procurement TL;DR

Full questionnaire-style page: Procurement.

• Product: OpenAI-compatible validation and policy proxy with optional playbooks. Not a workflow engine, connector catalog, or local OSS runtime.
• Data: Hosted SaaS on cloud infrastructure (subprocessors); prompt/completion text stored only if you enable payload logging, with plan caps in Privacy.
• Evidence: See Published evidence below and Security. Benchmarks and methodology are published; SOC 2 / pentest summaries are available on request under NDA.
• Assessments: Contact or security@valguard.ai for assessment artifacts (scope, date, assessor, and findings confirmed per document).
• Outage behavior: ValGuard fails closed. Client fallbacks that call providers directly bypass rules; your app must own that choice (see below).

Data residency

Hosted SaaS (default): ValGuard runs on infrastructure operated by subprocessors listed at /legal/subprocessors. That list currently includes Vultr for hosting and storage, Amazon Web Services (SES) for email, and Stripe for billing. The DPA describes cross-border transfers and Standard Contractual Clauses where they apply.

Enterprise self-host: The same application stack can run in your VPC or on-prem under license. That deployment keeps AI payloads in infrastructure you control; license heartbeats still reach ValGuard cloud without customer AI content (see self-host docs).

LLM providers: Models you route to via BYOK or Provider Vault are your providers, not ValGuard subprocessors. You choose regions and contracts with each vendor.

We do not claim a specific EU-only SaaS region on this page unless your order form or DPA amendment states one. Confirm residency requirements with sales before sending regulated data.

What ValGuard is

ValGuard is a runtime validation and policy-enforcement layer for LLM calls and agent steps. Deterministic rules run on every completion before the next model, tool, or customer-facing action. It includes a lightweight step graph so rules apply at handoffs. It is not a general workflow engine, connector platform, or durable-execution system.

Data flow

1. Your app or agent SDK sends an OpenAI-compatible chat request to ValGuard.
2. Optional input validators run on the prompt.
3. ValGuard forwards the request to the provider you configured, or to a custom endpoint in Provider Vault.
4. Output validators run on the completion, or on the assembled stream for streaming calls.
5. The response returns to your app with validation headers such as X-VG-Validation-Status.

What we store. By default, request metadata for billing, limits, and observability. We do not write prompt or completion text unless you turn on payload logging for an agent.

If you enable payload logging. Content is kept for the period you set, up to your plan's cap. The caps are 7 days on Free and Developer, 30 on Growth, 90 on Production, and 365 on Enterprise. A daily job removes expired payloads.

Provider keys. Keys in Provider Vault are encrypted at rest with AES-256-GCM. We use them only to call the providers you configure.

Self-host license checks. On Enterprise self-host, a heartbeat sends license status to ValGuard cloud. It carries no customer AI payloads.

Evaluating without a local runtime

There is no public Docker image, CLI validator, or open-source runtime. To evaluate ValGuard, use shadow mode on the hosted service.

Hosted shadow mode is not local or offline evaluation. Requests still pass through ValGuard and the configured model provider, even when payload logging is off. Start with synthetic or sanitized test cases if your data policy permits hosted processing.

If your policy prohibits that processing, hosted shadow mode does not satisfy it. Review the licensed Enterprise self-host option with your security team before sending sensitive data.

In shadow mode enabled rules run on the traffic you send. Failures are logged. Nothing is blocked by those rules. Shadow mode is available on every plan, including Free.

Review the would-block rate, tune the rules, then turn enforcement on. The shadow mode rollout tutorial walks through it, and the blog post on validating before you enforce explains why.

One caveat applies to playbooks. Shadow mode is a per-agent setting. If an agent is a step in a playbook, a failure on that step does not trigger block routing while shadow is on. Turn it off on any step you want to gate before the playbook goes live.

Streaming

If any enabled rule can block or re-ask, ValGuard buffers the full reply before it sends a token. The user waits for model completion and validation before seeing output. A re-ask adds another model attempt to that wait.

Warn, log, and shadow mode can pass tokens through, but they do not stop a violating reply from reaching the user. Choose buffering when an output must pass checks before release. Do not relax a required blocking policy just to preserve streaming.

Measure time to first visible token and time to a complete accepted reply separately. Engine microseconds and mocked HTTP latency do not measure this UX cost. See benchmark methodology.

Failure modes

A rule fails. You choose the action per rule: block, reask, warn, or log. A block returns a block envelope instead of the model's text. A re-ask sends the request to the model again, within your plan's re-ask limit.

ValGuard is unreachable. The request fails. ValGuard does not skip rules and pass the call through. If your feature must survive an outage, build the fallback in your client: call the provider directly, queue the work, or degrade the feature. That choice stays with you, and it should be explicit.

ValGuard is an additional availability dependency on the model request path. An SLA is a service commitment, not a client recovery mechanism. Test your outage behavior before enforcing rules in production.

Do not treat a direct-provider fallback as equivalent protection. For an action that requires validation, stop or defer it until the required checks can run.

Client-side fallback (explicit bypass)

When ValGuard is unreachable, your application must choose fail-closed, queue, or direct-provider bypass. Example pattern:

async function chat(messages: Message[]) {
  try {
    return await vg.chat.completions.create({
      model: "openai/gpt-4o-mini",
      messages,
    });
  } catch (err) {
    if (!process.env.ALLOW_DIRECT_PROVIDER_FALLBACK) {
      throw err;
    }
    // Auditors: this path skips ValGuard rules and audit rows.
    return await openai.chat.completions.create({ model: "gpt-4o-mini", messages });
  }
}

Gate ALLOW_DIRECT_PROVIDER_FALLBACK behind feature flags, runbooks, and risk sign-off. Do not leave it on by default.

The provider fails. Provider errors and open circuit breakers affect the model call. Validators do not invent a completion when the provider returns nothing.

Availability

Current service status is on the status page.

Published evidence

Contractual terms and privacy commitments remain on Privacy and DPA. Published product evidence is not an independent attestation unless labeled as such.

Benchmarks are ValGuard measurements; methodology documents mocked upstreams and reproduction limits.

Deployment

Default: hosted SaaS.

Enterprise self-host: the same web app, Go engine, Postgres, and Redis in your VPC or on-prem, under a license. It is not a free or open-source runtime. See the self-host docs and pricing.

Portability

Playbooks export as JSON (valguard-playbook-template/1). The file holds agents and, optionally, their validator rules. The same format imports through a validate-then-apply flow. Per-agent validator lists and audit export are also available through the API.

Export works per playbook and per agent today. A single org-wide policy file is on the roadmap. Until it ships, do not plan around a full org export.

Honest limits

Passing configured rules does not establish that an answer is true, complete, or useful (for example, valid JSON with no PII can still state the wrong refund deadline). Grounding overlap is a bounded check, not proof that a source supports every claim.

• Validation enforces contracts you encode; it does not prevent every hallucination or measure overall model quality.
• Hosted shadow mode is not air-gapped or offline evaluation.
• ValGuard is not a replacement for n8n, Temporal, or LangGraph when you need connectors, schedules, or durable execution.

Related

• Benchmarks and methodology
• Orchestration: playbooks and workflow engines
• Validation
• ValGuard vs Guardrails AI
• Integrations: n8n, LangGraph, OpenAI Agents SDK
• MCP security
• Contact for Enterprise and procurement questions