The riskiest thing in your AI estate was configured on somebody laptop. A developer adds an MCP server to their local agent config on a Tuesday. It holds a long-lived token for the issue tracker, or the CI system, or a production database, generated by them. From that moment every prompt their agent sends carries the ability to reach that system, and the model decides when to use it. There is no pull request, no procurement, no change ticket and no asset-register entry. A repository scan finds nothing, because the config lives in the home directory rather than in the repo.
The one place it is unavoidably visible is the request
Every request an AI coding agent makes carries the full list of tools it is offering the model: its own, 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-declared on every single turn rather than once per session. The firewall is already parsing that body to run your content guardrails. Reading the tools array is the same parse, which is why this needs nothing installed anywhere and costs nothing to run.
Four families, one grammar
Tools
tool_allow / tool_deny
Every tool name in the request: the agent own Bash, Read and Edit, and every tool a local MCP server has been flattened into the same array. Patterns are globs, so Bash means exactly Bash and mcp__github__* covers one server.
MCP servers
mcp_allow / mcp_deny
Remote MCP servers declared by URL for the provider to call directly. Protocol fact rather than convention, so strip removes the whole connection and the token that came with it.
Skills
skill_allow / skill_deny
Named skills offered through a dispatching tool. Skills are not a wire primitive, so these are read off a schema and from actual invocations, and the docs say so rather than pretending otherwise.
Clients
client_allow / client_deny
Claude Code, Codex CLI, Cursor, Claude Desktop, the SDKs, or unknown. Derived from headers any caller can set, so this is attribution and inventory rather than a security boundary.
Any enabled allow rule switches its family into allowlist mode, where anything not explicitly allowed is refused. That is the same sentence the model allow/deny lists already use, deliberately: one rule to learn, not two. Patterns are globs rather than regular expressions, because a name list is the one place regex power is a liability. Someone typing a tool name writes Bash and means exactly Bash, where an unanchored regex would also match Bashful.
Strip is the action that makes this usable
Blocking a request because it offers an unapproved tool makes the whole session unusable until the developer edits their config. That is a fine control and a poor default. Strip removes the one entry and forwards the rest, so the model is never offered the capability and the agent keeps working with a smaller reach. The developer does not lose their agent; they lose the ability to write to production from it. That is the difference between a control people accept and one they route around.
Strip has one guard worth knowing. If the tool being stripped also appears in the conversation history as already called, removing its declaration would leave an orphaned tool_use block and the provider would reject the whole request with an opaque 400 mid-session. The engine escalates to a readable 403 naming the rule instead. Loud and correct beats silent and broken.
An inventory built from what ran, not what is written down
Alongside the rules, every tool, MCP server, skill and client your agents carry is recorded, with the client that carried 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 nobody reads a convention as a protocol fact. It runs for every organisation on every plan, independent of the paid inference-logging switch.
That is affordable because of one mechanic. A Claude Code turn declares around forty tools and re-declares the same forty on every request for hours. The gateway hashes the capability set, keeps a cache of the ones it has already written, and issues one statement per distinct configuration per window. Steady-state cost is one database write an hour rather than forty a second.
What it costs
The gateway and the BYOK vault are free on every plan, and so is the inventory: an organisation that cannot yet write rules is exactly the one that most needs to see what its agents are carrying. Provider and model allow/deny unlock on Pro. Content guardrails and agent governance unlock on Teams. There is no markup on your tokens at any tier. Compare plans.
Configuration, not usage
The inventory records that your estate offers a capability. It does not record that anyone used it, what they asked it to do, or what came back. No prompt, no completion, no tool argument, no tool result. MCP server URLs are reduced to scheme, host and path before storage, because the Anthropic mcp_servers entry carries an authorization_token right beside the URL and query-parameter authentication is a real pattern. The inference log is about conversations and stays a paid opt-in; this is the list your rules are written against, in the same way the provider and model catalogs are, which is why it sits outside that switch.
A scan finds what is written down. This finds what ran.
Vulnetix already ships an AI Bill of Materials: it scans a repository across four evidence passes and reports every AI coding agent, SDK and model it can find in config files, environment-variable names, source literals and commit trailers. That is the declared half of an AI asset inventory, and it is the half every other vendor stops at. The firewall watches the wire and reports what an agent actually carried. Neither half is complete alone: a scan cannot see a laptop-local MCP server, and runtime observation cannot see a model referenced in code that has not run yet. Together they are the inventory an ISO 42001 or NIST AI RMF conversation is actually asking for, and the shape an EU AI Act record-keeping question expects.
What this cannot do
Said here rather than in a footnote, because it changes what the feature is for. A tool runs on the developer machine before the firewall sees anything. When an agent runs a shell command, the gateway first sight of it is the request carrying the result back. A rule stops the capability being offered so the model cannot call it again, and refuses a request whose history shows it was used. It cannot un-run a command. Client identity comes from headers anyone can set, so it is attribution and inventory rather than a security boundary. Both limits are on the documentation pages, at the top, not buried at the bottom.
Against the alternatives
LiteLLM, Portkey, OpenRouter and Cloudflare AI Gateway are operations products that happen to have some security features. This is a security product that happens to be a gateway. As of August 2026 none of their published documentation describes tool-level policy, an agent capability inventory, or client identification. That does not mean it cannot exist or is not planned; check for yourself before repeating it. In the other direction, there are no rate limits, budgets or spend caps here and no plans for them, and our own documentation names which competitor to use instead. We would rather be the honest answer to one question than a vague answer to five.