Limitations

The guardrail limitations page exists because a control whose boundary you do not know is a control you will misuse. This is the same list for the capability plane.

A tool runs before the firewall sees it

This is the big one.

When Claude Code runs Bash, the command executes on the developer’s machine. The firewall’s first sight of it is the request that carries the result back on the following turn. There is no point at which the gateway sits between the agent and the shell.

So a tool rule will not:

  • Stop a command that has already run.
  • Sandbox, review, or approve an individual tool call.
  • Prevent a file being read, a token being exfiltrated by a local process, or a package being installed.

What it will do, and this is worth stating as clearly as the limitation:

  • Remove the tool from the request so the model cannot call it again on this or any later turn.
  • Refuse a request whose history shows the tool was used, so the result never reaches the model and the block is recorded.

Both are real controls over a real risk. Neither is “the firewall stops agents running commands”, and anyone who describes it that way to an auditor is going to have a bad meeting.

Client identity is self-reported

Every signal in client identity is a header the caller chose to send. curl -H 'User-Agent: claude-cli/2.1.0' is Claude Code as far as this firewall is concerned.

Use it for attribution and inventory. Do not put it in a threat model. The authentication boundary is the Vulnetix API key, and nothing else on this page participates in it.

Body-side rules are more honest, but not magic

A client can lie about the tools it declares too. The difference is that this lie is self-defeating: to use a tool, the client must declare it, so a tool hidden from the firewall is also hidden from the model.

That makes tool rules meaningfully stronger than client rules. It does not make them a sandbox. An agent configured to talk to the provider directly is outside your policy entirely — see the firewall is a control, not a cage.

Local MCP detection is a naming convention

mcp__server__tool is a convention Claude Code follows. Codex uses server__tool, Cursor uses mcp_server_tool, and nothing in the protocol requires any of them.

A client that names its MCP tools differently is invisible to a prefix rule, and the inventory marks these rows inferred precisely so that nobody reads a convention as a guarantee. Remote MCP servers are the exception: those are declared with a URL and are protocol fact.

Skills are read off a schema

There is no skills field on the wire. What the firewall reads is the enum in a dispatching tool’s input schema, and the skill named in a tool_use when one actually runs. The first is a guess at a shape and will drift as clients change; the second is exact but arrives after the fact.

The deterministic control is denying the dispatching tool. See skills.

Tool arguments are not inspected

Same boundary the content guardrails have: the arguments a model generates for a tool call pass through unscanned. What is scanned is the tool result coming back, which is the direction organisational data actually flows outward.

A capability rule governs whether a tool exists, never what is passed to it.

Strip changes the request

A stripped request is not the request the client sent. That is the point, and it has two consequences worth knowing:

  • The model may reference a capability it no longer has, because the agent’s system prompt still describes it. You get an apology, not an error.
  • Rewriting the tools array changes the cached prefix, so a strip rule that fires every turn causes a prompt cache miss every turn. On heavy agent traffic that is a real cost. Prefer allowlisting at the client, and use strip where you cannot.

No approval workflow

There is no “ask a human before this tool runs” flow, no per-call review queue, and no escalation path. Rules are static policy evaluated per request. If you need in-line approval, MCP’s own require_approval on remote servers is the mechanism, and it lives in the client’s configuration rather than here.

No rate limiting per tool

The firewall has no quantitative controls and this plane adds none. You cannot cap how many times a tool is called, or budget one agent’s tool use against another’s.