LLM Firewall Tools

What an LLM firewall does, and what it can't

An LLM firewall sits at the boundary between your application and the model. Inbound, it inspects the assembled prompt — including retrieved RAG content and tool outputs, which is exactly where indirect prompt injection hides — and blocks or flags attacks before they reach the model. Outbound, it inspects the response for data leakage, PII, and policy violations before it reaches a user or a downstream system. Placed at the LLM gateway, one policy covers every app.

What it cannot do is fix the underlying weakness. A model still cannot reliably tell instructions from data, and every classifier-based filter has been bypassed by a determined attacker. The right mental model is the web application firewall: it blocks the bulk of attacks, buys detection time, and is one layer in a stack — not the thing that makes you safe. Pair it with the architectural controls in the prompt injection guide.

Build or buy

Build the cheap, application-specific checks and own them: schema validation on outputs, allowlists, PII detection on the outbound path, and constrained tool permissions. They are high-value and nobody understands your app’s policy better than you. Buy the runtime firewall for what is expensive to keep current: maintained detection for evolving prompt-injection and jailbreak techniques, centralized policy across many apps, and audit logging. Keeping classifier content ahead of attackers is a full-time job most teams should not staff.

The common end state is layered: open-source guardrails (Guardrails AI, NeMo Guardrails) inside the app for cheap deterministic checks, a commercial runtime firewall at the gateway for maintained detection and central policy, and model supply-chain scanning (Protect AI, HiddenLayer) as a separate control for the model layer. They are complementary, not substitutes.

The gap: developer agents on laptops

Every vendor above sits between an application and a model. That is the right placement for the application estate and the wrong one for the surface growing fastest inside most engineering orgs: a coding agent running on an engineer's workstation with shell access. Claude Code, OpenAI Codex, Cursor's agent mode and the agentic modes in GitHub Copilot do not route through your LLM gateway, and the risky moment is not the text the model returns. It is the command that text turns into: rm -rf against the wrong path, a read of ~/.aws/credentials, a force-push, a curl that posts a file somewhere. An inbound/outbound content filter has nothing to inspect at that moment because the model call already happened somewhere else.

The control that fits this layer is pre-execution rather than classification. The agent proposes an action, something evaluates that action against policy before the operating system sees it, and the decision is recorded. Three properties separate it from the gateway firewall:

• Local-first. The check has to run on the workstation, in the path between the agent and the OS. A network hop cannot mediate a local file write or a subprocess.
• Approval, not scoring. The unit of policy is a command and its arguments, not a probability on a string of text. Allow the test runner, deny writes outside the working tree, ask before anything that touches a credential file.
• Receipts. A retained, attributable record of what the agent actually executed and which rule allowed it. Shell history does not tell you which agent session ran a command, and that is the first question an incident review asks.

Some of this already ships inside the agents. Claude Code has permission modes and tool allowlists, Codex runs commands in a sandbox, Cursor supports command allow/deny lists. Treat those as the floor, then check what they do not give you: policy that is the same across four different agents, enforcement a developer cannot flip off mid-session, and one audit trail across the fleet rather than per-tool settings on 200 laptops. That is a separate budget line and a separate control from the gateway firewall, not a feature of it.