Firewall every LLM call, across every provider.

One line in any SDK

There is no proxy to run, no certificate to install and no agent on the machine. The provider and your organisation are both path components, so a client needs nothing beyond a base URL and an API key.

base_url = "https://guardrails.vulnetix.com/openai/<org-uuid>/v1"
api_key  = "<your Vulnetix API key>"

Three request surfaces are served, so one policy covers the whole estate: chat (OpenAI Chat Completions, the OpenAI SDKs, LangChain), responses (what Codex CLI requires) and messages (what the Anthropic SDKs, Claude Code and Claude Desktop speak). A guardrail written for a curl covers a Codex turn and a Claude Code turn without modification. Note that the Anthropic SDK appends /v1 itself, so an Anthropic base URL stops at the organisation uuid.

12 providers, one key

Every provider below is free. Provider keys stay in the vault; your applications never hold one.

Provider policy is per organisation: allow, deny, or leave unset for default-allow. A denied provider returns a 403 naming the policy, and a provider with no stored key is refused outright rather than silently falling back to anything. Note that OpenRouter is a router rather than a vendor, so allowing it grants reach to many underlying vendors and the firewall sees only openrouter.

Model allow and deny lists

Deny entries always block a model. Adding any allow entry for a provider switches that provider into allowlist mode, where only allowed models pass, which is the behaviour that surprises people and is worth knowing before you add the first one. "Any provider" expands to every provider currently listing the model. A model unknown to the catalog passes unless allowlist mode is on, because the hourly catalog sync can lag a provider release.

The catalog is synced hourly, and GET /v1/models serves it filtered by your policy, rendered in the dialect the provider speaks. That matters for exactly one client: Claude Desktop populates its model picker from this endpoint, and an OpenAI-shaped list is a parse error to it rather than a graceful degradation.

Seven rule types across two planes

Content rules govern what a request says. Capability rules govern what it can do. Capability rules are evaluated first, as a group, because a request offering a forbidden tool should be refused before the firewall pays to scan its text.

Four actions

Roll a rule out on the ladder: flag for a week to get the signal with no risk, then redact or strip, then block. The failure mode of an LLM firewall is not a missed detection, it is a rule that fires on legitimate work, blocks a developer mid-task and gets the whole thing switched off by lunchtime.

What gets inspected

Everything you send: the system prompt, every message, multi-modal text parts, and, the one that matters most for coding agents, tool results. When an agent reads a file, runs a command or pastes a diff back into the conversation, that content is a tool result and it goes through your guardrails. That is the direction organisational data actually flows outward.

Two things are not inspected, and both are design boundaries rather than gaps about to close. Responses are never inspected: guardrails run on the request, and what the model says back is relayed untouched. The arguments a model generates for a tool call are not scanned, though the result that comes back is.

Govern the tools, not just the model

Every request an AI coding agent makes carries the full list of tools it is offering the model: its own Bash and Read, every tool from every MCP server the developer wired in, and any remote MCP server the provider is being asked to call. These APIs are stateless, so that list is re-sent on every turn rather than once per session. The firewall reads it, and can refuse it.

A local stdio MCP server has no separate identity on the wire, because the client flattens its tools into the ordinary array before sending anything. It is reachable through its tool-name prefix (mcp__jira__* in Claude Code, <server>__<tool> in Codex), which is a naming convention rather than a protocol guarantee, and the inventory marks anything derived that way as inferred rather than presenting it as fact. Remote MCP servers are the exception: those are declared with a URL and can be denied by name.

# The agent declared, this turn and every turn
tools: Bash, Read, Edit, Task, WebFetch,
       mcp__github__create_pull_request,
       mcp__prod_db__query

# One rule, and the model is never offered it
tool_deny  mcp__prod_db__*  action: strip
200 OK   (tool removed, session continues)

# Or refuse the whole request instead
tool_deny  mcp__prod_db__*  action: block
403 policy_violation - tool_denied

A runtime AI inventory, free on every plan

A repository scan finds the AI that is written down. It cannot find the MCP server a developer added to a local config on Tuesday with a token for the issue tracker, because there is no pull request, no procurement record and no asset-register entry, and the config lives in a home directory rather than in the repo. The one place it is unavoidably visible is the request.

The inventory lists every tool, MCP server, skill and client your agents offer, with the client that offered it and first-seen and last-seen dates. Each row is marked declared (read verbatim from a request field), invoked (seen actually being called) or inferred (derived from a naming convention), so evidence strength is never guessed at. One click turns an observed capability into a rule about it.

It is configuration rather than usage: it records that your estate has a capability, never that anyone used it, what they asked it to do or what came back. That is why it is free on every plan and sits outside the inference-logging switch. It pairs with the Vulnetix AI-BOM, which scans repositories for declared AI across four evidence passes. Static discovery plus runtime observation is a complete AI asset inventory, and the shape an ISO 42001, NIST AI RMF or EU AI Act record-keeping question actually asks for. Either alone is not.

Your keys, in a vault you can audit

Each provider key is encrypted per organisation with AWS KMS and decrypted just in time for the upstream call, bound to that organisation and provider through the KMS encryption context so a ciphertext lifted from one row is useless anywhere else. Keys are never returned by the API: the dashboard and the CLI can set, replace or remove one, and nothing can read one back. Your applications carry a single Vulnetix API key instead of a key per provider, which is one secret to rotate rather than twelve.

If the guardrail backend is unreachable the gateway fails closed by default, refusing with a 503 rather than forwarding a request unscreened. Authentication and provider and model policy are always fail-closed and cannot be configured otherwise, so a backend outage can never turn into an unauthenticated request reaching a provider.

Wire a coding agent in one command

curl -fsSL https://cli.vulnetix.com/install.sh | sh
vulnetix ai-firewall key set anthropic     # stored KMS-encrypted, never returned
vulnetix ai-firewall install claude-code   # writes the base URL and token
vulnetix ai-firewall status                # verify, including a bypass check

Claude Code, Claude Desktop, Codex CLI, Cursor, Continue and Aider are all documented, each with its own verification step. Manage the whole policy as code in .vulnetix/ai-firewall.yaml and apply it from CI, which validates every pattern and rejects the file if one is bad, so a rule that would silently enforce nothing never reaches your policy. Full guides live in the AI Firewall documentation.

AI Firewall: frequently asked questions

What is free, and what is paid?

The gateway and the BYOK vault are free on the Community plan, across all 12 providers, along with the AI inventory of the tools and MCP servers your agents carry. A firewall you cannot route through is not a product, so routing is never behind the paywall. Pro adds provider and model allow/deny lists and inference logging. Teams adds content guardrails and agent governance over tools, MCP servers, skills and clients. You keep your own billing relationship with each provider at every tier: the firewall applies no markup and takes no cut.

Are my prompts logged?

No. There is no code path that stores a prompt or a completion, so this is not a setting that can be misconfigured. Even with inference logging enabled the row is metadata only: model, decision, which rules fired by name, token counts, latency and status. A violation records that a rule matched, never what it matched.

Where are my provider API keys?

Encrypted per organisation with AWS KMS and decrypted just in time for each upstream call, bound to that organisation and provider by the KMS encryption context. They are never returned by the API, so the dashboard can only set, replace or remove one. Your applications carry a single Vulnetix API key instead of a key per provider.

Which clients work with it?

Three request surfaces are served, which covers most of the ecosystem: OpenAI Chat Completions for the OpenAI SDKs and LangChain, OpenAI Responses for Codex CLI, and Anthropic Messages for the Anthropic SDKs, Claude Code and Claude Desktop. Each is a base URL change and nothing else. No proxy to run, no certificate to install, no agent on the machine.

Can it stop an agent running a shell command?

No, and no LLM gateway can. The command runs on the developer machine and the firewall first sees the request carrying the result back. What a tool rule does is stop the capability being offered to the model so it cannot be called again, and refuse a request whose history shows it was used. That is a real control over a real risk, and it is not a sandbox.

What is in the capability inventory?

The names of the tools, MCP servers and skills your agents offer the model, and which client offered them. It is configuration rather than usage: it records that your estate has a capability, never that anyone used it, what they asked it to do or what came back. It exists so a tool rule can name a real tool, which is the same reason the provider and model catalogs exist.

Does it do rate limits or spend caps?

No, and there are no plans to. There are no rate limits, budgets, quotas or cost tracking of any kind. If cost control is your requirement, LiteLLM, Portkey and Cloudflare AI Gateway all do it and our own documentation names them. We would rather be the honest answer to one question than a vague answer to five.

How does it compare to LiteLLM, Portkey or Cloudflare AI Gateway?

Those are operations products that happen to have some security features; this is a security product that happens to be a gateway. They have retries, fallback, caching, budgets and load balancing, and this has none of them. As of August 2026 none of their published documentation describes tool-level policy, an agent capability inventory or client identification. Use LiteLLM if you must self-host, Portkey if you need response filtering, and this if you care most about what leaves.

The gateway is free. Policy is what you pay for.

Every provider is available on every plan, and your keys stay in the KMS-encrypted vault whatever you pay, with no markup on your tokens at any tier. A firewall you cannot route through is not a product, so routing is never the thing behind the paywall.

Community gives you the gateway across all 12 providers, the BYOK vault, and the AI inventory of every tool and MCP server your agents carry. Pro adds provider and model allow/deny lists and inference logging. Teams adds content guardrails for secrets and PII, and agent governance over tools, MCP servers, skills and clients. Compare plans.

Get Free API Key →