Zero data retention

The gateway never stores your prompts or completions. Not when logging is off. Not when logging is on. There is no configuration that turns it on, because there is no code path that writes them.

That is a stronger claim than “we do not log by default”, so it is worth showing why it is true rather than asking you to take it on faith.

How it is enforced, not promised

There is nowhere to put them. The inference log table has no column for a prompt and none for a completion. The columns that once existed were dropped in a migration, deliberately, so that the schema itself makes content storage impossible. A future bug cannot accidentally start persisting prompts, because there is no field to persist them into.

Responses are never buffered. When a request is proxied, the upstream response is relayed straight through to your client. When logging is enabled, it is passed through a sniffer whose only job is to find the token counts — it scans bytes, keeps the two integers, and discards everything else. Completion text is never accumulated, never assembled, and never handed to anything that could write it down.

Streaming is a byte relay. A streamed response is forwarded frame by frame as it arrives. Nothing reassembles it into a message.

Requests are held only long enough to inspect them. Your prompt is parsed, evaluated against your guardrails, re-serialised if a redaction rule rewrote it, and forwarded. Then it is gone. It exists in memory for the duration of one request.

What about the guardrail matches?

This is the question worth asking, because a naive implementation would record the matched text — and that would be a repository of exactly the most sensitive strings in your organisation.

It does not. A recorded violation contains the rule name, rule type, action, and a generic detail string. It never contains the content that triggered it.

So a flag rule tells you that it matched, 40 times this week. It cannot tell you what matched. That is a real trade-off — it makes tuning harder — and it is the right one, because the alternative is that adopting a guardrail creates a new sensitive datastore.

What the gateway does write

Structured operational logs — method, path, HTTP status, and duration. No bodies, no headers, no content. The same thing any HTTP server writes.

Inference log rows, if and only if your organisation has opted in. Metadata only: which model, which surface, what the policy decision was, which rules fired, token counts, latency, status code. Never content.

What this does not cover

Warning

Zero retention applies to the firewall, not to the provider.

Once your request clears policy and is forwarded, it is in OpenAI’s hands, or Anthropic’s, or Groq’s. What they retain, for how long, and whether they train on it is governed by your agreement with them — the account whose key is in the vault. The firewall does not and cannot change it.

If you need zero retention end-to-end, you need it in your provider contract too. The firewall guarantees the middle hop; you still own both ends.

This is also why jurisdictional control is a provider allow/deny question rather than a routing flag: the only lever that meaningfully constrains where your data is retained is which vendors you let it reach.

Verifying the claim

You cannot inspect our storage, so the meaningful checks are these:

  • Nothing to opt out of. Look for the setting that turns off prompt logging. There isn’t one, because there is nothing to turn off.
  • The logging toggle changes what metadata is recorded, not whether content is. Switch logging on and look at the fields available. There is no prompt field to display.
  • The dashboard cannot show you a prompt. No API returns one. If we retained them, the product would show them to you — every observability tool does.