Key custody & BYOK

Most LLM gateways are, structurally, a company holding your API keys. That is a supply-chain risk you have taken on, and it is worth being precise about what makes one different from another.

The AI Firewall’s position: your provider keys are encrypted under a key the gateway can use and nobody can export, bound to your organisation, and never returned by any API.

The mechanism

Envelope encryption with AWS KMS. A stored provider key is a KMS ciphertext blob, not an encoded or obfuscated string. Decrypting it requires a KMS Decrypt call, by a principal with permission to make it, against a customer master key whose material never leaves KMS.

Bound to your organisation and that provider. The ciphertext is produced under a KMS encryption context naming both your organisation and the specific provider. KMS enforces the context on decrypt — it is authenticated additional data, not a label. So:

  • A ciphertext lifted from your organisation’s row and replayed under another organisation does not decrypt. It fails, cryptographically.
  • A ciphertext moved between providers does not decrypt.
  • Stealing the database does not get you the keys. An attacker with a full dump has ciphertext blobs and no ability to use them, because the decrypt is gated by KMS and bound to a context they cannot forge.

Separate write and read authority. The service that stores your key can encrypt and cannot decrypt. The gateway that uses it can decrypt and cannot encrypt. A compromise of the dashboard does not yield the ability to read keys.

Write-only, permanently. No API returns a stored key — not the dashboard, not the CLI, not an admin endpoint. There is no read path anywhere in the system. The dashboard can tell you that a key exists and when it changed. That is the entire surface.

Decrypted just-in-time. The key is decrypted at the moment it is needed, injected into the upstream request, and never written to a log, a trace, or an error message.

Your credential never reaches the provider

The Vulnetix API key your applications send is stripped before the request goes upstream. The provider sees its own key, in its own credential header, and nothing else of yours.

The reverse is also true: your provider key never reaches your applications. They carry one Vulnetix key; they have no idea what your OpenAI key is, and cannot leak what they do not have.

What is not changed

Your billing relationship with the provider is untouched. The firewall does not proxy your payment, pool your key with other customers, resell your tokens, or take a markup.

Your provider quotas, spend limits, rate limits, and organisation controls all apply exactly as they did before — because it is still your account making the call. If you have a zero-retention agreement with OpenAI, it still holds. If you have an enterprise DPA, it still holds.

This is not incidental. Key pooling and token markup are the two things that make a gateway a middleman in your provider relationship, and both are absent here — which is also why the firewall can be free.

Rotation and revocation

vulnetix ai-firewall key set openai --from-env NEW_KEY   # rotate
vulnetix ai-firewall key remove openai                   # revoke

The stored key is read fresh on every request, so a removal takes effect on the next request rather than at the end of some cache lifetime. Revocation is immediate.

Revoking the Vulnetix key is the bigger hammer: it cuts off every application in your organisation at once, in one action, without you having to find and rotate credentials scattered across developer machines and CI configs. That consolidation is one of the main reasons to run a gateway at all.

Secret hygiene at the edges

The vault protects the key at rest and in transit. Two places it can still end up on disk, and both are your call:

--embed-key writes the literal Vulnetix key into a client config instead of a reference. The CLI hard-errors if the target path is not git-ignored — it will not help you commit a secret. Use it only where a client genuinely cannot read an environment variable.

Continue is that case. ~/.continue/.env holds a literal key because the IDE extension cannot read your shell environment. The CLI writes it chmod 600. If a literal key on a developer’s disk is unacceptable in your environment, do not wire Continue.

Audit what ended up on disk:

vulnetix secrets

What we still ask you to trust

Honesty matters more than marketing here. See the threat model for the full accounting, but the short version:

The gateway can decrypt your provider key — it has to, in order to use it — and it can see your prompts in memory, because it has to, in order to screen them. It does not persist either. You are trusting an operator not to run modified code, in exactly the way you trust every hosted service you use.

What the cryptography buys you is that a database breach is not a key breach, and that a stolen ciphertext is worthless. That is a real, meaningful reduction in blast radius. It is not the same as us being unable to see anything, and we will not claim that it is.