The question every security review asks
The moment an AI gateway sits in front of your traffic, your security team asks the right question: what happens to our prompts? Most vendors answer with a policy PDF. Policies are promises — and promises don't survive a vendor-risk assessment, let alone an incident. The answer has to be architectural: something a reviewer can verify from the wire, not something they have to trust you on.
Retention is a per-org setting, not a company-wide policy
NeuroRoute gives every organization three retention modes, not one blanket default. "zero-strict" stores nothing at all — response caches are bypassed on both read and write, server-side conversation memory is refused outright, and even provider-side prompt caching is disabled so a cache header can't re-enable retention behind your back. "zero" also persists nothing, but allows provider-side prompt caching for the latency and cost benefit. "retain" stores conversations and cache entries for a configurable window — one to 365 days — after which a daily sweeper permanently deletes them. New organizations default to "zero" on signup; nobody has to remember to opt out of retention.
The part your auditor will actually like: every single API response carries an X-Data-Retention header stating the posture it was served under — "zero-strict", "zero", or "retain:<N>d". Retention isn't a settings page you screenshot once a year for a compliance binder. It's an assertion on every request, verifiable from your own client logs without ever trusting a dashboard.
What you keep is encrypted under a key you can hold
Orgs that opt into retention get their stored content encrypted at rest with a per-organization AES-256-GCM data key. That key is itself wrapped by a key-encryption key in Google Cloud KMS — envelope encryption, the standard pattern — and the wrapping key is pluggable. The default is a platform-managed KMS key; enterprises can instead supply a customer-managed key (CMEK) that lives in their own cloud project. When you use CMEK, revoking NeuroRoute's IAM grant to your key is an instant, unilateral kill switch: every byte of your stored content, including backups, becomes unreadable in one action on your side of the fence, with no ticket to file and no vendor to wait on.
Keys rotate on a schedule too. A background job mints a new data-key version, re-encrypts existing content in batches, and only retires the old key version once zero rows still reference it — ordering that matters, because retiring a key before the sweep finishes would make readable ciphertext permanently unreadable. If a sweep pass is interrupted, the old version simply stays active and the next pass retries; nothing is ever left half-migrated.
Erasure that ends with evidence, not a support ticket
- An organization admin requests erasure, with a 7-day cancelable grace period so a bad click isn't a catastrophe.
- On execution: conversation content and semantic-cache entries are deleted, API credentials are revoked, and user identities are anonymized (UUIDs are kept intact — because usage and billing records reference them — but names, emails, and profile data are scrubbed).
- The organization's encryption key is crypto-shredded: deactivated so that all prior ciphertext, including anything sitting in backups, is permanently unrecoverable. This step runs last, deliberately — a failure earlier in the sequence must never leave you in a state where the key is gone but the content it protected is still sitting there.
- You receive a machine-readable completion certificate with per-scope counts: how many conversations, how many keys, how many users. Billing and usage metadata is retained afterward on a lawful basis — tax and accounting law requires it — but every trace of the content itself is gone.
And you don't have to wait for an incident, or an offboarding, to see your own data. GDPR Article 20 gives you export — streaming JSON, or CSV inside a ZIP for spreadsheet tools — covering your organization's profile, users, API key metadata, billing records, conversations, and usage events. The export path is structurally incapable of leaking a secret: it is built from dedicated projection types that simply don't have fields for key material or another tenant's data, so there's no risk of "we forgot to redact it" — the field to leak doesn't exist in the struct being serialized.
The boring parts that matter more than they sound
- PII detection with checksum-validated algorithms — Luhn for card numbers, Verhoeff for many national ID formats — so an invoice number that happens to be 16 digits long doesn't trip a false positive and get routed away from your preferred model for no reason.
- Prompt-injection detection at two tiers: a free heuristic scan for instruction-override phrasing and known jailbreak patterns, and an optional paid LLM-based semantic check for paraphrased attacks that don't match a keyword.
- Org-scoped SQL on every read path, so a bug in one query can't accidentally return another tenant's rows — this is enforced at the query level, not just in application logic that could be bypassed.
- Metadata-only request logs. Prompt and response bodies are never written to logs — a log line records the model, the org, the cost, and the latency, never the content.
- OAuth 2.1 for agent and MCP tooling, an audit log of every privileged admin action, and every customer-supplied URL validated at dial time against SSRF before the platform will connect to it.
What a security review actually checks, in order
Strip away the specific mechanisms above and a typical vendor security review asks four questions, in roughly this order, and the answer to each is meant to be checkable rather than asserted. First: what is your default posture for a customer who does nothing? New organizations default to "zero" retention — the safe answer is the one nobody has to opt into. Second: if we do choose to retain, who can read it? Content is encrypted per-organization, and enterprises can supply their own key so the answer is genuinely "not even the platform operator, once you revoke access" rather than "trust our access controls." Third: if we leave, does our data actually leave with us? Export is self-service and structurally leak-proof by the shape of the code, not by a promise to redact carefully. Fourth: if something goes wrong, what's the blast radius and how fast do we know? Metadata-only logging bounds what a breach could even expose, and a 72-hour regulatory breach-notification commitment is a real operational deadline the platform is built to meet, not an aspiration in a policy document.
For the reviewer who needs paperwork alongside the architecture, that's also available on request: a security whitepaper, a CAIQ-Lite response, and a provider zero-retention checklist — documentation that describes the same mechanisms this post does, so the paperwork and the platform are never telling two different stories.
Privacy that survives a real procurement conversation isn't a feature you bolt on at the end. It's the order of operations: store nothing by default, encrypt what you choose to keep, make erasure end with proof instead of a promise, and let the customer hold the key that decides whether any of it is readable at all.