Limitations & roadmap

The honest list. If a capability is not here and not documented elsewhere on this site, assume it does not exist.

No cost controls of any kind

There are no rate limits, no budgets, no spend caps, no quotas, and no cost tracking. The firewall applies no markup and takes no cut — you keep your billing relationship with each provider, and their limits are the only limits.

The single quantitative control is max_messages, which bounds how many messages a request carries. It does not bound their size, their token count, or your bill.

If you see a 429, it came from the provider, against your own account.

No response inspection

Guardrails run on what you send. What the model sends back is relayed untouched.

So there is no output filtering, no redaction of model-generated PII, no detection of a successfully-injected model, and no toxicity or safety filtering on completions. This is a design boundary, not an oversight. See guardrail limitations.

No fallback, no retries, no load balancing

One request goes to one provider. If it fails, it fails — the error is relayed to you and nothing is retried. There is no automatic failover to a second provider, no model fallback chain, and no load balancing across providers.

No ML guardrails

No prompt-injection classifier, no jailbreak model, no semantic detection, no NLP entity recognition, no evasion detection (base64, homoglyphs, spaced-out text).

Guardrails are RE2 regular expressions. That is a real defence with real limits, and the prompt-injection page is explicit about both.

No guardrail 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. See tuning false positives.

Tool rules cannot un-run a tool

The firewall can govern which tools an agent offers the model, which MCP servers a session connects, and which client is calling — see agent context. What it cannot do is intercept the execution: when a coding agent runs a shell command, that happens on the developer’s machine, and the firewall’s 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 can refuse a request whose history shows it was used. It is not a sandbox and it is not an approval workflow. Agent context limitations is the full list.

Client identity is not authentication

The client name on a request is derived from headers the caller chose to send. curl -H 'User-Agent: claude-cli/2.1.0' is Claude Code as far as this firewall is concerned.

It is useful for attribution and for finding agents nobody procured. It is not a security boundary, and a client_allow rule is a hygiene control rather than a defence. The authentication boundary is the Vulnetix API key.

No region pinning or data residency

The gateway runs in a single region. There is no per-request inference region, no EU-only endpoint, and no residency guarantee for the transit hop.

The lever that does exist is choosing which vendors you allow — see jurisdictional control.

No cross-surface translation

The three request surfaces (chat, responses, messages) are proxied, not translated. You cannot send an Anthropic-shaped request to OpenAI, or an OpenAI-shaped request to Anthropic, and have the gateway convert it.

A provider serves the surfaces it serves; asking for another is a 404. See base URLs & request surfaces.

No per-key or per-user policy

Policy is organisational. There is one Vulnetix API key per organisation, and one policy that applies to every request made with it.

There is no per-team policy, no per-project policy, no per-developer policy, and no key scoping. If you need different policies for different groups, you need different organisations.

No admin API

Policy is managed through the dashboard, the CLI, and policy as code. The gateway itself exposes no policy CRUD endpoints — it enforces, it does not administer.

Known gaps

Cursor’s tab completions and Auto mode never route through BYOK. This is a limit of Cursor, not of the firewall, and we cannot fix it. If you assume all of Cursor’s traffic is firewalled, you have a compliance hole. See Cursor.

Tool-call arguments are not scanned. The arguments a model generates for a tool call pass through unscanned. Tool results — the file contents and command output an agent feeds back — are scanned, which is the direction that matters. But the gap is real.

A broken guardrail pattern fails silently. An uncompilable regex is skipped; the rule shows as enabled and enforces nothing. Mitigate with policy as code, which validates before applying, and vulnetix ai-firewall status, which compiles patterns locally.

Redaction breaks prompt caching. Rewriting text inside a cached prefix causes a cache miss. Keep redaction rules narrow on agent traffic.

Not supported

Junie (JetBrains) hard-codes its provider and offers no base-URL override. It cannot be pointed at the firewall, by us or by you.

OpenCode, Hermes Agent, and OpenClaw may support a custom OpenAI-compatible endpoint via their config files, but we have not verified it against the gateway and will not publish a tutorial we have not tested. See other clients.

Roadmap

Things we intend to build. None of them exist today, and none should appear in a plan that depends on them:

  • A guardrail allowlist with mask-before-detect semantics — exempting a phrase without blinding the scanner to the rest of the message.
  • A Cursor compatibility shim so agent-mode tool calls work.
  • Response inspection. The largest gap, and the hardest to do without compromising the zero-retention property that makes the rest of it trustworthy.
  • More providers — Bedrock, Vertex, and self-hosted endpoints. These are data, not code, so they are cheap.