Threat model
Security products earn trust by being precise about their boundaries. This page is the one to read before you write the firewall into a compliance document.
What we guarantee
Your prompts and completions are never stored. Not by default, not with logging on, not anywhere. This is enforced structurally: the log schema has no column that could hold them. See zero data retention.
A database breach is not a key breach. Provider keys are KMS ciphertext bound by encryption context to your organisation and that provider. A full database dump yields blobs an attacker cannot decrypt — they cannot forge the context, and the key material never leaves KMS. See key custody.
Your keys are not pooled or resold. Your billing relationship with each provider is unchanged. No markup, no shared credentials.
Policy is enforced on every request. There is no bypass token, no exception list, and no per-user override. A denied provider is denied for everyone.
Authentication never fails open. If the authentication backend is unreachable, requests are refused — not waved through. The same is true of provider and model policy. Only guardrail evaluation has a fail-open switch, and it is off by default.
Guardrail matches never record content. A violation names the rule, never what triggered it.
What we do not guarantee
The provider is still the provider
Once a request clears policy and is forwarded, it is in the provider’s hands. Their retention, their training policy, their jurisdiction, their subprocessors, their breach — none of it is ours to control and we do not claim otherwise.
The firewall guarantees the middle hop. Your agreement with the provider governs the far end. If you need zero retention end-to-end, you need it in their contract too.
We can see your prompts in memory
The gateway parses your request in order to screen it. During that request, the plaintext is in the process’s memory. It has to be — that is what inspection means.
It is not persisted, not logged, and not transmitted anywhere but the provider you addressed. But we are not claiming we cannot see it. Anyone who tells you a gateway can filter content it cannot read is describing something other than what they have built.
We can decrypt your provider key
The gateway holds decrypt authority for the vault, because it must inject your key upstream. The cryptography constrains where that key can be used and makes a stolen ciphertext worthless. It does not, and cannot, put the key beyond the reach of the service that has to use it.
You are trusting an operator
The two facts above amount to this: you are trusting Vulnetix to run the code it says it runs, in the way it says it runs it — the same trust you extend to every hosted service in your stack. The cryptography meaningfully reduces the blast radius of a breach. It does not eliminate the operator from your trust boundary, and we will not pretend it does.
If your threat model excludes trusting an operator, you need self-hosted inference, not a gateway.
No region-pinning, no data residency
The gateway runs in a single region and your request transits it. There is no per-request region selection and no residency guarantee. See jurisdictional control for the lever that does exist.
Guardrails are regex, not comprehension
No ML classifier, no semantic detection, no evasion handling. Pattern matching catches the common cases and is trivially evaded by someone who knows it is there. Responses are not inspected at all. See guardrail limitations.
It is a control, not a cage
A developer who unsets an environment variable is talking to the provider directly. An agent configured outside your policy is outside your policy. The firewall enforces on the traffic that reaches it.
This is what “client-side configuration” means, and it is why
vulnetix ai-firewall status has a bypasses_firewall check. Run it.
Some bypass is structural and unfixable: Cursor’s tab completions and Auto mode never route through BYOK. If you assume all Cursor traffic is firewalled, you have a hole. See Cursor.
Who has to be compromised for what
A rough blast-radius table, which is usually the thing an auditor actually wants:
| Compromise | Your prompts | Your provider keys |
|---|---|---|
| The firewall’s database | Not exposed — they are not there | Not exposed — ciphertext, cryptographically bound |
| A developer’s laptop | Exposed for that developer’s traffic | Not exposed — the laptop holds only the Vulnetix key |
| Your Vulnetix API key leaks | Attacker can send prompts as you, and spend your provider quota | Not exposed — the key is never returned |
| The provider | Whatever they retain, per your contract with them | Their copy of your key |
| The firewall operator | Prompts in flight, if they ran modified code | Decryptable, by design |
The middle rows are the interesting ones. A leaked Vulnetix key is bad — it lets someone spend your provider budget — but it does not leak your provider credentials, and you revoke it in one action that cuts off every application at once. That consolidation is the point.