Your two keys

There are two credentials in play, they are used at different hops, and mixing them up produces a 401 that sends people hunting in the wrong place. This page exists to stop that.

Warning A provider key sent to the gateway is a 401, not a passthrough. If you paste sk-ant-... or sk-proj-... into your client’s api_key field, the firewall rejects it — that is not the credential it authenticates you with.

The Vulnetix API key — you → the firewall

This is what your client sends. One per organisation.

It is derived from your organisation, and it is the only credential your applications ever carry.
It goes in Authorization: Bearer <key> (OpenAI SDKs and most clients) or x-api-key: <key> (Anthropic SDKs, Claude Code). Both are accepted on every route, so you do not have to think about which.
Conventionally it lives in the VULNETIX_API_KEY environment variable. That is the variable vulnetix ai-firewall install writes references to.
Revoke it and every application is cut off at once — which is the point.

Find it on the AI Firewall dashboard alongside your organisation UUID (you need both — the org UUID is part of the base URL).

The provider key — the firewall → the provider

This is what the gateway sends. One per provider, per organisation.

You store it once, in the vault. Your applications never see it and never carry it.
It is encrypted with AWS KMS and bound to your organisation and that provider.
It is write-only: it can be replaced or removed, never read back — not by you, not by any API.
Your billing relationship with the provider is unchanged. The firewall does not proxy your payment, mark up your tokens, or resell them.

Store one with the CLI, or on the dashboard:

vulnetix ai-firewall key set openai --from-env OPENAI_API_KEY

See BYOK for rotation, removal, and how the encryption actually works.

The CLI has a third credential, and it is not either of these

vulnetix auth login authenticates you, the operator to the Vulnetix API so you can manage firewall policy. It is unrelated to what your applications send at inference time. So:

Credential	Who sends it	To what	Set by
CLI login	you, at a terminal	the Vulnetix API	`vulnetix auth login`
Vulnetix API key	your app / agent	the firewall	`VULNETIX_API_KEY`
Provider key	the firewall	the provider	`vulnetix ai-firewall key set` (stored, not sent)

Diagnosing a 401

What you see	What it means
`missing Vulnetix API key: send it as Authorization: Bearer or x-api-key`	No credential reached us at all. Check the variable is exported in the shell your client actually runs in.
`invalid Vulnetix API key`	Something arrived, but it is not your org’s key. Nine times out of ten it is a provider key in the client’s `api_key` field.
`unknown organisation`	The org UUID in the base URL is wrong, malformed, or inactive.

A 403 saying provider_key_missing is the other direction: you authenticated fine, but there is no provider key in the vault for that provider yet. Store one.