Limitations

Every security control has a boundary. A control whose boundary you do not know is a control you will misuse. This page is the honest list.

Only requests are inspected. Never responses.

Guardrails run on what you send. What the model sends back is relayed to your client untouched, unscanned, and unmodified.

So the firewall will not:

  • Catch a model that has been successfully prompt-injected and is now emitting attacker-controlled instructions.
  • Redact PII that the model produces — from its training data, from a RAG context, or by hallucination.
  • Detect data exfiltration through a model’s output.
  • Filter toxic, unsafe, or off-policy generated content.

If your requirement is output filtering, the AI Firewall does not do it, and no combination of rules will make it. This is a design boundary, not a gap we are about to close by accident.

The arguments a model generates for a tool call are not scanned

When a model decides to call a tool, the arguments it produces for that call pass through unscanned.

What is scanned is the tool result — the file contents, command output, or fetched page that comes back and gets fed into the conversation. That is the direction organisational data actually flows outward, and it is covered.

The gap is narrow but real, and it is the one place a determined party could route data around a content rule.

Pattern matching is not comprehension

Guardrails match strings. They do not understand meaning.

  • A secret described in words rather than pasted verbatim is not matched.
  • An injection that achieves instruction override without using the phrases you matched on sails through. See prompt injection — there is no ML classifier, no jailbreak model, and no semantic detection.
  • There is no evasion detection: no base64 decoding, no homoglyph normalisation, no handling of s p a c e d o u t text. If you want those, you write patterns for them, and you will still not be complete.

A broken rule fails silently

Warning

A rule whose regex does not compile — or whose max_messages pattern is not an integer — is silently skipped. It stays in your policy, shows as enabled, and enforces nothing.

A typo can therefore disable a control while leaving every dashboard green.

Mitigations, in order of strength:

  1. Manage policy with apply — it validates every pattern and rejects the whole file if one is bad, so a broken rule never reaches your policy.
  2. Run vulnetix ai-firewall status after any change — it compiles patterns locally and reports guardrail_pattern_invalid.
  3. Enable inference logging and watch the inspected count. A request that parses cleanly but exposes nothing to inspect is a firewall screening nothing, and it otherwise looks exactly like a clean pass.

There is no allowlist

You cannot exempt a phrase, a user, a repository, or a client from a rule. A rule that is enabled applies to every request the organisation makes. See tuning false positives for what to do instead.

No quantitative controls beyond message count

There are no rate limits, no budgets, no spend caps, and no cost tracking. max_messages bounds how many messages a request carries; it does not bound their size, their token count, or your bill. The only size limit is an 8 MiB request-body ceiling, which is a transport limit and returns a 413.

Redaction has costs

  • It is silent. The client gets a 200 and an answer about redacted text, with no indication why. Tell your developers.
  • It breaks prompt caching. Rewriting text inside a cached prefix causes a cache miss, so a rule that fires on every turn of a Claude Code session means you pay full price on every turn. Keep redaction rules narrow on agent traffic.

The firewall is a control, not a cage

A developer who unsets an environment variable is talking to the provider directly. An agent configured outside your policy is outside your policy. The firewall enforces on the traffic that reaches it, and nothing else.

This is not a weakness peculiar to us — it is what “client-side configuration” means. It is why vulnetix ai-firewall status has a bypasses_firewall check, and why verification is a thing you should actually do rather than assume.

Some traffic bypasses it by design and you cannot fix it: Cursor’s tab completions and Auto mode never route through BYOK. If you assume all of Cursor’s traffic is firewalled, you have a compliance hole. See Cursor.

What the firewall does not promise about the provider

Once a request passes policy and is forwarded, it is in the provider’s hands. Their retention, their training policy, their jurisdiction, their breach — none of that is ours to control, and we do not claim otherwise. See the threat model.