Alternatives

The AI Firewall is a security product that happens to be a gateway. Most of the tools it gets compared to are operations products that happen to have some security features. That difference explains most of the table below.

If you need what they are good at, use them. A docs page that pretends otherwise is not worth reading.

Quick comparison

When to use something else

Use LiteLLM if you must self-host

It is open source, you run it, and nothing leaves your infrastructure — which is the only answer if your threat model excludes trusting an operator. It also has the routing, retry, and budget features we do not.

The trade: guardrails are your problem, the operational burden is yours, and you are maintaining a proxy.

Use Portkey if you need output filtering and budgets

It is the closest thing to a direct competitor and it does things we do not: response inspection, spend caps, semantic caching, richer observability. If output filtering is a hard requirement, we cannot do it and they can.

Use OpenRouter if you want one key for hundreds of models

Different product. It is a router — its job is model access and failover, and it is excellent at that. It takes a markup on tokens, and it holds the provider relationship rather than you.

You can also use both: put OpenRouter behind the firewall as a provider. Note the caveat — allowing openrouter grants reach to many underlying vendors, and our provider policy sees only openrouter. See the provider catalog.

Use Cloudflare AI Gateway if you want caching and analytics

Strong at caching, rate limiting, and observability, and cheap to run if you are already on Cloudflare. It is not a content firewall — no guardrails, no allow/deny policy — and it logs by default.

When to use the AI Firewall

Be honest about the shape of the fit:

• You care most about what leaves. Secrets, PII, credentials in prompts. That is the thing this product is built to stop, and everything else is secondary to it.
• You want zero retention without configuring it. It is not a setting here — there is no code path that stores a prompt. Nothing to get wrong.
• You want your provider relationship intact. No key pooling, no markup, no middleman. Your contract, your quota, your DPA.
• You need to govern coding agents. Claude Code, Codex, Cursor and Continue are first-class, the CLI wires them, and tool results — where an agent’s file contents and command output actually leave — are screened.
• You want it enforced, not requested. Org-wide policy with no per-user exceptions and no bypass token.

When not to use it

Stated plainly, because you will find out anyway:

• You need spend caps or rate limits. We have none. Use LiteLLM or Portkey.
• You need output filtering. We do not inspect responses.
• You need provider failover or retries. One request, one provider, no fallback.
• You need per-team policy. Policy is organisational. One key, one policy.
• You cannot trust an operator. Self-host LiteLLM.
• You need caching. We have none, and a redaction rule will actively break your provider’s prompt caching.

The full list is limitations & roadmap.

Running more than one

These compose. A common shape:

• AI Firewall at the edge, for the security policy — what may leave, which vendors, which models.
• LiteLLM or Portkey behind it, for routing, retries and budgets.

You get the enforcement without giving up the operational features. The firewall does not care what is upstream of it, as long as it speaks one of the three surfaces.