Provider catalog

The provider is the first path segment of your base URL: https://guardrails.vulnetix.com/{slug}/{orgUuid}/v1.

Every provider requires a stored key before it will proxy anything. For kiro that key is a Kiro login rather than an API key (see Kiro below). Every provider is subject to your provider policy and model policy.

Custom providers

An organisation can register its own OpenAI-compatible, OpenAI Responses or Anthropic Messages endpoint. It is addressed exactly like a built-in, by its slug (https://guardrails.vulnetix.com/{slug}/{orgUuid}/v1), and is subject to the same authentication, provider policy, model policy and guardrails. What differs is trust, because the base URL is text an organisation typed:

• Private to its organisation. Another organisation requesting the same slug gets the ordinary 404 unknown_provider.
• A built-in always wins. A custom provider cannot take the slug of a built-in provider, and if a row ever existed with one the built-in is what is served.
• Public https endpoints only. The gateway refuses to connect to loopback, link-local (including the cloud metadata address), private (RFC 1918), CGNAT, unique-local or multicast addresses. The check is made when the connection is opened, on the address the host name resolves to at that moment, so it holds against DNS rebinding. Such a request is a 502 with code upstream_blocked.
• Redirects are never followed, and are not passed on to your client either. The request carries your provider key, so it only ever goes to the URL that was registered.
• No Kiro. Custom providers cannot serve the kiro surface (400 unsupported_api).
• Authentication to the endpoint uses the credential template stored on the provider, such as Authorization: Bearer {apiKey}, x-api-key: {apiKey} or cf-aig-authorization: Bearer {apiKey}; the key itself comes from your stored key.

Surfaces, and why they matter

• chat — POST /v1/chat/completions. What almost everything speaks.
• responses — POST /v1/responses. Only openai serves it. This is what Codex CLI requires, which is why Codex can only be wired to the openai provider.
• messages — POST /v1/messages. Only anthropic serves it. This is what Claude Code and Claude Desktop speak.
• kiro — POST /v1/generateAssistantResponse. Only kiro serves it. This is the AWS CodeWhisperer / Q Developer API that Kiro and belai’s kiro provider speak. The response is a binary AWS event stream.

Asking a provider for a surface it does not serve is a 404 telling you what to use instead. See base URLs & request surfaces.

Kiro

Kiro has no API key. Instead you sign in once, and the gateway mints a short-lived Kiro access token from that sign-in for every request:

vulnetix ai-firewall kiro login                          # AWS Builder ID
vulnetix ai-firewall kiro login --start-url https://my-org.awsapps.com/start --region eu-central-1
vulnetix ai-firewall kiro login --import                 # reuse the Kiro IDE / kiro-cli sign-in

The sign-in is saved to the secrets vault as the kiro provider’s key, granted to the AI Firewall. Your client then sends only its Vulnetix API key:

• base URL: https://guardrails.vulnetix.com/kiro/{orgUuid}/v1
• inference: POST …/generateAssistantResponse
• models: GET …/ListAvailableModels

Things to know:

• GitHub and Google Kiro sign-ins cannot be used. They have no AWS SSO-OIDC refresh path. Sign in with an AWS Builder ID or IAM Identity Center.
• When AWS stops accepting the sign-in, requests are refused with 403 vault_kiro_relogin. Run vulnetix ai-firewall kiro login again to fix it.
• The profile is fixed by the sign-in. For an Identity Center sign-in, the gateway sets the vault’s profileArn on every request, replacing any the client sent.

Model names are the provider’s own

The gateway passes the model string through verbatim — it does not rewrite, prefix, or normalise it. Use exactly the name the provider uses:

Get the name wrong and you get the provider’s own “unknown model” error, relayed verbatim — not one of ours. That is usually the fastest way to tell the two apart.

OpenRouter is a router, not a vendor

The model catalog

The list of models at each provider is synced hourly. It is what GET /v1/models serves, and what the dashboard’s model pickers are populated from.

A model that is not in the catalog still works — unless the provider is in allowlist mode. This is deliberate: a model released this morning should not be an outage while the sync catches up.

The consequence is worth stating: a deny list cannot block a model that does not exist yet. If you need that guarantee, you need an allowlist.

Adding a provider

Providers are data, not code. If you need one that is not on this list — a self-hosted endpoint, Bedrock, Vertex, an OpenAI-compatible gateway of your own — get in touch. Anything that speaks one of the chat, responses or messages surfaces and authenticates with a static header can be added without a code change.

Related

• Base URLs & request surfaces
• BYOK — storing a key for a provider.
• Jurisdictional control — choosing vendors deliberately.