What Is an LLM Firewall? Prompt-Layer Defenses Explained

If you are evaluating a chatbot or agent deployment and someone asks what is an LLM firewall, the working definition is this: a filtering layer that sits between untrusted text and your language model, inspecting prompts on the way in and completions on the way out, and blocking or rewriting anything that matches a threat pattern. The name borrows from network security on purpose. A network firewall enforces policy on packets it does not trust; an LLM firewall enforces policy on natural language it does not trust. The difference is that packets have structure and language does not, which is why these products are built on classifiers rather than port rules, and why none of them should be treated as a complete answer to prompt-layer attacks.

What an LLM firewall inspects

Most products in this category run two pipelines.

Input scanning runs before the prompt reaches the model. Typical checks include prompt-injection detection and jailbreak detection (a classifier scoring whether the text is trying to override system instructions), PII detection and redaction, secret detection, topic filters, and token or length limits. Cloudflare’s AI Security for Apps, the renamed Firewall for AI, is a representative example at the network edge: per Cloudflare’s docs it runs three detections on incoming LLM traffic, covering PII, unsafe topics, and prompt injection, and exposes the results as fields you can use in WAF custom rules or rate limiting.

Output scanning runs on the completion before it reaches the user or a downstream system. Common checks include sensitive-data detection (did the model leak something from its context?), malicious URL detection, format validation such as JSON-schema enforcement, and content-safety classification. The open-source LLM Guard project from Protect AI illustrates the breadth of the category well: it lists 15 input scanners and 20 output scanners, from Anonymize and Secrets on the way in to Deanonymize, Relevance, and MaliciousURLs on the way out. One procurement note worth knowing: that repository was archived in July 2026 and is now read-only, a useful reminder that open-source guardrail tooling carries maintenance risk you should price in.

A newer subcategory targets agents rather than chatbots. Meta’s LlamaFirewall paper describes a framework with three parts: PromptGuard 2 for jailbreak detection, an experimental alignment checker that audits an agent’s chain of reasoning for signs its goal has been hijacked by injected content, and CodeShield, a static-analysis pass over generated code. That second component matters because agent compromise often shows up not in the injected text itself but in what the agent decides to do afterward.

Where it sits in the request path

Deployment shape is the main architectural decision, and there are three common ones.

At the edge, the firewall is part of your WAF or API gateway and inspects traffic before it reaches your application. Cloudflare’s implementation works this way: it scans requests to endpoints labeled as LLM endpoints, currently JSON request bodies only, and the full detection ruleset is an Enterprise add-on per their docs. Edge deployment buys you coverage without code changes, at the cost of only seeing what crosses the network boundary.

As a proxy or gateway service, the firewall is a dedicated hop between your application and the model API. This is where most commercial LLM-firewall vendors sit. You get centralized policy and audit logging across every model you call, and you add one network round trip of latency to every request.

In-process, the firewall is a library your application calls directly, the LLM Guard and LlamaFirewall model. This is the only shape that can see everything the model sees, including retrieved documents in a RAG pipeline, which matters because indirect prompt injection arrives through that retrieved content rather than through the user’s request. The trade-off is that you own the integration, the model updates, and the compute.

The threats it maps to

In OWASP terms, an LLM firewall primarily addresses LLM01:2025 Prompt Injection, which OWASP describes as crafted inputs manipulating the model into unauthorized access, data leakage, or compromised decisions. Output scanning additionally addresses LLM05:2025 (Improper Output Handling) by validating completions before downstream code consumes them, and LLM02:2025 (Sensitive Information Disclosure) by catching leaks of PII or secrets in responses. If you want the attacker’s view of these techniques, the offensive side of prompt injection and jailbreaking is covered in depth at aisec.blog, and it is worth reading before you evaluate any detector, because the evasion techniques are what you are actually buying protection against.

What an LLM firewall does not stop

This is the section vendors tend to skip. A 2025 empirical study, Bypassing LLM Guardrails, tested evasion techniques against six production detection systems, including Microsoft’s Azure Prompt Shield and Meta’s Prompt Guard, and found that character-injection and adversarial-ML techniques achieved up to 100% evasion success in some configurations while keeping the attack functional. That result should calibrate your expectations: these are probabilistic classifiers, not policy enforcement, and a motivated attacker who can iterate against them will eventually get through.

The residual risks to plan for:

• Classifier evasion, as above. Detection rates from vendor marketing are measured against known payload sets, not adaptive attackers.
• Indirect injection through content the firewall never inspects, such as a poisoned document entering your RAG index through a batch pipeline.
• False positives. Every input filter will eventually block a legitimate user, and topic filters in particular need tuning against your real traffic before you enforce in blocking mode.
• Anything past the prompt layer. An LLM firewall does not constrain what a compromised agent’s tools can do. That requires tool allowlists, sandboxing, and least-privilege credentials, which are separate controls.

The defensible position is layered: an LLM firewall as one control, alongside output validation, agent sandboxing, and monitoring. Policy frameworks such as NeMo Guardrails sit next to the firewall pattern and add conversation-flow rules a classifier cannot express. For the broader guardrail and safety-tooling landscape beyond the firewall pattern itself, guardml.io tracks the defensive side of this space.

How to evaluate one

Four questions separate the serious products from the rest. Where does it sit, edge, gateway, or in-process, and does that shape see your RAG content? What is the measured false-positive rate on your traffic, not the vendor’s benchmark? What latency does it add at p95, since every check is inline? And can you get raw detection logs out, because a firewall you cannot audit is a firewall you cannot tune.

Related across the network

• Jailbreak Detection for LLMs Explained: How Runtime Filters Work — aidefense.dev
• The AI Security Tools Directory: 40+ Tools Compared (2026) — aisecbench.com
• How Prompt Injection Detection Works: Classifiers, Monitors — aisecreviews.com
• Best LLM Firewall Tools in 2026: A Buying Guide — aisecweekly.com
• Prompt Injection Detection Tools: The 2026 Landscape — aisecweekly.com