"Add a guardrail" sounds like one decision. It is four. The open-source ecosystem never converged on a single shape for the checks that wrap a model call — it split into four archetypes that barely resemble each other: a programmable rails DSL (NeMo Guardrails), a validator library (Guardrails AI), a family of safety-classifier models (Llama Guard), and a scanner pipeline (LLM Guard). Pick the shape that doesn't match your problem and you fight the tool for months. And the ground is moving: a 2025-26 consolidation wave swept most of the commercial guardrail vendors into security platforms — LLM Guard into Palo Alto and now archived, Lakera into Check Point, Invariant into Snyk — leaving NeMo, Guardrails AI, and Meta's Llama stack as the independent OSS survivors. This post puts all four on one map so you can tell which shape your problem actually needs — and why none of them, alone, stops prompt injection.
At a glance
Four projects, four different answers to "what is a guardrail." The table fixes the basics — shape, license, and whether anyone is still maintaining it; the chart and matrix beneath it show community surface area and where each one leans hardest.
| Project | Shape | License | Maintained? |
|---|---|---|---|
| NeMo Guardrails | Programmable rails DSL — five rail types in Colang; can reject, alter, redirect, and orchestrate other checks | Apache-2.0 | Yes — actively maintained (NVIDIA) |
| Guardrails AI | Validator library — Input/Output Guards built from ~60+ reusable Hub validators; Pydantic + RAIL schemas | Apache-2.0 | Yes — actively maintained; most stars of the four |
| Llama Guard family | Safety-classifier models — Llama Guard 4 (content), Prompt Guard 2 (injection), + LlamaFirewall framework | Llama Community License — open weights, not OSI-open | Yes — actively maintained (Meta) |
| LLM Guard | Scanner pipeline — ~35 chained input/output scanners mixing heuristic + model-based | MIT | No — repo archived ~2026-07-09 (EOL) |
Snapshot: 2026-07-15. Star counts are approximate as of that date and move fast — re-check each repo before you commit. NeMo's GitHub license reads "NOASSERTION" only because its LICENSE.md format isn't auto-detected; it is Apache-2.0. And read the last row carefully: LLM Guard's star count belongs to a project that is now archived — a headstone, not momentum.
Where a guardrail actually sits
Pre/post checks around the model, not a wall
Every tool here does the same structural thing: it inserts checks before the prompt reaches the model and after the model responds. That framing matters because it sets the ceiling on what any guardrail can do. A guardrail wraps a model; it cannot reach inside and make an unsafe model safe. It can refuse to send a bad input, rewrite or redact one, or block and replace a bad output — but the intelligence and the failure modes still live in the model. Confusing "we added guardrails" with "the model is now safe" is the first and most expensive mistake in this space.
Deterministic checks vs probabilistic ones
Within that pre/post frame there are two very different kinds of check, and every one of these tools mixes them. Deterministic checks catch things with a definite answer: does the output match a schema, does it contain a known-pattern secret or a credit-card number, does it use a banned substring, does it stay on an allowed topic. These are near-free, reliable, and non-negotiable — a regex either matches or it doesn't. Probabilistic checks — toxicity, jailbreak, prompt-injection, hallucination — run a classifier or an LLM judge and return a score with false positives and false negatives baked in. They are genuinely useful and genuinely fallible, and no amount of tuning turns a probabilistic check into a deterministic guarantee. The best production setups run the cheap deterministic filters first and reserve the expensive probabilistic ones for what's left.
The agent case: the input isn't just the prompt
In a plain chatbot the untrusted input is the user's message. In an agent it is far more than that. The dangerous text arrives as tool output, retrieved documents, and injected content — a web page the agent browsed, an email it read, an MCP tool's description, a row from a database. Any of those can carry instructions aimed at the model, and the agent then acts on them with real tools. That is why the newer guardrail features are agent-aware: NeMo's retrieval and execution rails, Meta's AlignmentCheck, Invariant's mcp-scan. It is also why structured-output validation is the quiet workhorse of agent safety — validating a tool call's arguments against a schema is the one guardrail that is cheap, deterministic, and reliably catches a malformed or unsafe tool invocation before it executes.
Four shapes of a guardrail
Why "guardrail" is four things, not one
The word hides the disagreement. A rails DSL (NeMo Guardrails) treats safety as dialogue control: you write flows in a small language and the rails decide what conversation is allowed to happen at all. A validator library (Guardrails AI) treats it as schema validation: you compose reusable validators into Guards that check inputs and outputs against rules and types. A classifier model (Llama Guard) treats it as a machine-learning problem: a trained model reads text (or images) and returns safe/unsafe plus a category — no policy engine, just a verdict you wire in. A scanner pipeline (LLM Guard) treats it as a firewall: a fixed catalog of scanners you chain, each screening one thing. These are not competing implementations of one idea; they are four different ideas of what the job even is. Which is why the useful question is never "which is best" but "which shape is my problem."
NeMo Guardrails
Colang and the five rail types
NeMo Guardrails, from NVIDIA, is the programmable-rails answer. You describe allowed and disallowed behavior in Colang, a Python-like DSL for modeling dialogue flows, and the runtime enforces it through five rail types wrapped around the model call: input rails screen the user's message, dialog rails steer the conversation itself, retrieval rails check retrieved chunks before they reach the prompt, execution rails guard tool/action calls, and output rails vet the response. A rail can reject a turn, alter it, or redirect it — and because rails are programmable, a single dialog rail can orchestrate other checks (a classifier, Presidio for PII) into one coherent layer instead of a pile of disconnected filters. It runs as an in-process Python library, and the execution rails are what make it relevant to agents rather than just chatbots.
What it's uniquely good at
NeMo's home turf is topical and conversational control — "only talk about X, never about Y, and if the user pushes, deflect this way." Nothing else here models a conversation as a first-class object. If your requirement is a support bot that must stay strictly on-policy across a multi-turn dialogue, or an assistant that has to refuse whole categories of request gracefully, the rails DSL expresses that directly. Its second strength is orchestration: because a rail is code, NeMo is a natural place to compose the other shapes — call a classifier, run a PII check, apply a fact-check — and present them as one guardrail layer.
Where it strains
The power has a price. Colang is a real learning curve — you are learning a DSL and a dialogue-modeling mental model, not dropping in a one-line validator. NeMo is heavier to stand up and configure than a simple "scan this string" library, and the dialog and retrieval rails add LLM and embedding calls, which means latency. For a task that is genuinely just "check this output for PII and toxicity," NeMo is overkill; you want a validator or a scanner. It shines when the problem is conversational shape, not when it is a single stateless check.
Guardrails AI
Validators, Guards, and the Hub
Guardrails AI, from the company of the same name, is the validator-library answer — and, at roughly 7.2k stars, the most-starred of the four. You build an Input Guard and an Output Guard by composing validators, and the Guardrails Hub supplies ~60+ community validators off the shelf: PII detection, toxicity, competitor mentions, hallucination/grounding, format and value checks, and more. Each validator declares an on-fail action — reask (send it back to the model to try again), fix (repair it programmatically), filter (strip the offending part), or exception (raise and stop). The mental model is close to schema validation for LLM I/O: declare the rules, wrap the call, get typed and checked output.
Structured output: Pydantic and RAIL
Its sharpest strength is structured-output and schema enforcement. There are two paths: define the expected shape as a Pydantic BaseModel, or write it in RAIL, Guardrails' own XML-ish schema language. Either way you get output validated against a declared structure, with the reask loop available to coax the model into conformance when it drifts. This is exactly the guardrail agents need most — validating a tool call's arguments against a schema is cheap, deterministic, and catches malformed calls before they run — and it composes cleanly with model-judged checks so you can mix deterministic and probabilistic validators in one Guard. It runs as an in-process Python library plus a server mode, and a commercial Guardrails Pro managed offering sits on top of the OSS core.
Where it strains
The Hub is a strength and the weakness in one. Validator quality is uneven — it's a community ecosystem, and many validators wrap other models or external APIs, so their latency and accuracy vary widely from one to the next. Your injection coverage is only as good as the specific validator you install; there's no single blessed injection defense. And the reask action, useful as it is, adds cost and latency because it means extra model calls. Guardrails AI gives you a broad, pluggable toolkit; it does not guarantee that every tool in it is production-grade, and that vetting is on you.
Llama Guard family
Classifiers, not a framework
Meta's contribution — under the umbrella repo meta-llama/PurpleLlama, now marketed as "Llama Protections" (older brand: "Purple Llama") — is a different animal from the other three. It is a set of safety models and reference tools, not a rails framework. Llama Guard 4 (12B, natively multimodal text+image, released 2025-04-05) classifies content against the MLCommons hazards taxonomy and returns safe/unsafe plus a category. Prompt Guard 2 (86M and 22M, ~2025-04) is a dedicated jailbreak/prompt-injection detector designed to sit in front of Llama Guard — because Llama Guard, being an LLM itself, is injectable. Code Shield screens code output. You get best-in-class content-safety classification — multimodal, multilingual, standardized taxonomy — and cheap injection screening (the 22M Prompt Guard) as a front-door filter, all self-hostable as open weights.
Open weights, Llama license — not OSI-open
This needs saying plainly: Llama Guard is open weights, not open source. The models are released under the Llama Community License — source-available and self-hostable, but carrying acceptable-use restrictions and a clause that trips above 700M monthly active users, which is why it is not an OSI-approved open-source license. (The evaluation code in the repo is MIT; the model weights are not.) For most teams that distinction is academic — you can download and run the weights. For a company with a strict OSI-open-license requirement, it is disqualifying, and it's the reason Llama Guard sits in a different legal category from the Apache-2.0 and MIT projects here.
LlamaFirewall: the framework member
The family also has a framework member: LlamaFirewall (2025), Meta's open-source guardrail framework that orchestrates Prompt Guard 2, AlignmentCheck (a chain-of-thought auditor that watches for agent goal-hijack and injection), and CodeShield into one agent-native layer that runs in production at Meta. It is the living successor to the "scanner for agents" idea — the closest thing in the Llama family to the pipeline shape, but built for agents. The weakness of the whole family is the flip side of its strength: on their own these are just classifiers, with no orchestration, policy, or dialogue logic (you wire them in yourself, except through LlamaFirewall), each check is an extra model inference (a 12B model is not cheap), the license is not OSI-open, and — like every classifier — they can be evaded, and Llama Guard is itself injectable. They run as self-hosted model inference, in-process or as a sidecar microservice.
LLM Guard
⚠️ Archived — read this first
Before anything else: the repo protectai/llm-guard was archived around 2026-07-09 and is no longer maintained. That is not a footnote — it changes the recommendation. An archived security tool gets no new scanners, no security patches, and no model updates, so its model-based scanners will gradually bit-rot as the threats they detect evolve past their training. LLM Guard began as Laiyer.ai, was acquired by Protect AI, and Protect AI was in turn folded into Palo Alto Networks; the lineage now lives inside Palo Alto's Prisma AIRS platform (managed, closed). The OSS project is a snapshot in time — usable today, but on a clock.
The scanner pipeline
What it is, as a shape, is the cleanest scanner pipeline in open source: a fixed catalog of ~35 scanners (about 15 input, 20 output) that you chain. It deliberately mixes two kinds. Heuristic/deterministic scanners — Regex, Secrets, TokenLimit, BanSubstrings, and Anonymize/Deanonymize for PII — are near-free and exact. Model-based scanners — PromptInjection (a DeBERTa-class classifier), Toxicity, Bias, FactualConsistency/grounding, MaliciousURLs — bring the probabilistic checks. Both input and output sides are covered. Its standout trick is the PII anonymize→deanonymize round-trip: redact sensitive spans before the model sees them, then restore them in the response. As one MIT-licensed, self-hosted library it was the cleanest single answer to "scan every prompt and response for injection + PII + secrets + toxicity, with no data leaving my infrastructure."
What lives on
Past the archive flag, the ordinary caveats still apply: the model-based scanners add latency, the heuristic ones are bypassable by a determined adversary, and none of it is a dialogue or policy engine — it's a firewall, not a conversation manager. It ran as an in-process Python library or a self-hosted API/sidecar. If the scanner-pipeline shape is what you want and you need it maintained, the honest path now is either a maintained fork, a different tool, or the managed successor: LLM Guard's DNA lives on inside Palo Alto Prisma AIRS, but that is a closed, commercial platform, not the MIT library.
Cross-cutting comparison
Mechanism
Line the four up by how they work and the four shapes fall out cleanly. NeMo Guardrails runs a programmable state machine over the conversation — Colang flows and five rail types that can reject, alter, or redirect a turn and orchestrate other checks. Guardrails AI runs a validation pass — reusable validators composed into Input and Output Guards, each with a reask/fix/filter/exception action. Llama Guard runs a model inference — feed text or an image to a classifier, get a safe/unsafe verdict plus a category, with nothing wrapped around it unless you add LlamaFirewall. LLM Guard runs a scanner chain — a fixed list of heuristic and model-based scanners applied in sequence to input and output. Dialogue engine, validation library, classifier, and pipeline: the mechanisms don't overlap, which is precisely why they excel at different jobs.
What it catches, and the injection problem
On deterministic hazards the four converge: schema and format violations, known-pattern PII, secrets, banned substrings, and disallowed topics are all reliably catchable — Guardrails AI via validators, LLM Guard via heuristic scanners, NeMo via input/output rails, and Llama Guard, notably, not in this column since it's a probabilistic classifier by nature. On probabilistic hazards — toxicity, injection, jailbreak, hallucination — Llama Guard is the strongest by design (its whole purpose is best-in-class content and injection classification), Guardrails AI and LLM Guard depend on which model-based validator or scanner you enable, and NeMo depends on what you orchestrate. But none of them solves prompt injection, and it's worth being blunt about why. Every injection detector is a classifier, and classifiers can be evaded by an adversary who iterates against them. Meta's own architecture is the proof: they put a separate Prompt Guard in front of Llama Guard precisely because Llama Guard, being an LLM, is itself injectable. Treat injection like XSS or SQL injection — a class of attack you mitigate in layers, not a bug you patch with one filter.
Latency and cost
The cost structure is the same story told four ways, and it's structural, not incidental. Heuristic checks — LLM Guard's Regex and Secrets scanners, Guardrails AI's deterministic validators, NeMo's simple input rails — are near-free but brittle and bypassable. Every model-based check is an extra inference on top of your actual model call: Guardrails AI's model-judged validators, LLM Guard's PromptInjection and Toxicity scanners, NeMo's dialog and retrieval rails (which add LLM and embedding calls), and Llama Guard's classifier passes. The canonical contrast lives inside the Llama family itself — a 12B Llama Guard 4 is thorough but expensive, while a 22M Prompt Guard is cheap enough to run on every request. The production pattern that follows is universal: run the cheap deterministic filters first, and spend an expensive model check only on what survives them.
OSS vs managed, and the consolidation wave
Licenses and corporate homes diverge sharply. Three are genuinely permissive OSS you can self-host with minimal friction — NeMo (Apache-2.0), Guardrails AI (Apache-2.0), and LLM Guard (MIT) — while Llama Guard is open weights under the Llama Community License, not OSI-open, which is the one to clear with legal if strict licensing matters. But the bigger story is the 2025-26 consolidation wave that reshaped the field around them. Lakera Guard went to Check Point (Sept 2025, reportedly ~$300M) as a managed API, not OSS. Invariant Labs went to Snyk (June 2025), staying Apache-2.0 and agent/MCP-native, shipping mcp-scan to scan MCP servers for tool-poisoning. Protect AI — and with it LLM Guard — went to Palo Alto, where the scanner lineage now lives inside closed, managed Prisma AIRS. Alongside them sit the always-managed platforms — OpenAI's Moderation API, AWS Bedrock Guardrails (which added an agentic per-step InvokeGuardrailChecks API in 2026), and Azure AI Content Safety (whose Prompt Shields cover direct and indirect/cross-document injection) — none of them OSS. The net: the scanner-pipeline space got absorbed into managed platforms, and the independent OSS survivors are NeMo, Guardrails AI, and Meta's Llama/LlamaFirewall stack.
The agent case
Agents change the threat model, and the four adapt unevenly. The dangerous input is no longer just the user prompt — it's untrusted tool output, retrieved documents, and injected content (a web page, an email, an MCP tool description). NeMo answers with retrieval and execution rails that check content mid-pipeline and guard tool calls. Meta answers with LlamaFirewall and AlignmentCheck, a chain-of-thought auditor built to catch agent goal-hijack. The broader ecosystem answers with tools like Invariant's mcp-scan, which inspects MCP servers for tool-poisoning before they're ever called. And underneath all of it, the deterministic backbone is structured-output validation — Guardrails AI's home turf: validating a tool call's arguments against a schema is the one guardrail that is cheap, deterministic, and reliably catches a malformed or unsafe tool invocation before it executes. For agents, that quiet check earns its keep more consistently than any classifier.
When to pick which
| Need | Pick NeMo if… | Pick Guardrails AI if… | Pick Llama Guard if… | Pick LLM Guard if… |
|---|---|---|---|---|
| Topical / dialogue control | The pick — Colang models multi-turn on-policy conversation directly. | Not its shape; it validates I/O, it doesn't steer dialogue. | No — it classifies content, it has no conversation logic. | No — a scanner chain, not a dialogue engine. |
| Structured-output / schema validation | Possible via rails, but heavier than you need. | The pick — Pydantic/RAIL Guards are built exactly for this. | No — a classifier returns safe/unsafe, not a validated schema. | Partial — format scanners exist, but schema validation isn't the core. |
| Content-safety classification / injection screening | Only by orchestrating a classifier inside a rail. | Only as good as the validator you install for it. | The pick — best-in-class multimodal safety + cheap Prompt Guard screening. | Was solid via model scanners — but now archived, so it will bit-rot. |
| Self-hosted scan-everything firewall | Overkill — it's a dialogue engine, not a firewall. | Workable, but you assemble the scanners from validators yourself. | Only the classifiers — you wire the pipeline around them. | Was the cleanest single answer — but pick a maintained fork or successor now. |
| Strict OSI-open-license requirement | Yes — Apache-2.0 (ignore GitHub's "NOASSERTION"). | Yes — Apache-2.0. | No — Llama Community License is open weights, not OSI-open. | Yes — MIT — but the repo is archived, so weigh maintenance. |
| Lowest-latency cheap checks | Simple input rails are cheap; dialog/retrieval rails are not. | Use its deterministic validators; avoid the reask loop on the hot path. | The 22M Prompt Guard is cheap enough per request; the 12B is not. | Its heuristic scanners (Regex, Secrets) are near-free — if you accept EOL. |
FAQ
Do guardrails stop prompt injection?
No — not any of them, not alone. Every injection detector is a classifier, and classifiers can be evaded by an adversary who iterates against them. The strongest signal is Meta's own architecture: they place a separate Prompt Guard in front of Llama Guard precisely because Llama Guard, being an LLM, is itself injectable. Treat prompt injection the way you treat XSS or SQL injection — a class of attack you mitigate in layers, not a bug one filter patches. That means defense-in-depth: input screening, least-privilege tools, output checks, and human-in-the-loop for consequential actions. A guardrail lowers the odds; it does not close the door.
Is Llama Guard open source?
Not in the OSI sense. Llama Guard is open weights — you can download, self-host, and run the models — but they ship under the Llama Community License, which carries acceptable-use restrictions and a clause that trips above 700M monthly active users. That is source-available, not OSI-approved open source. (The evaluation code in the PurpleLlama repo is MIT; the model weights are not.) For most teams the distinction doesn't bite — you run the weights and move on. For anyone with a hard OSI-open-license requirement, it rules Llama Guard out, and it's why we put it in a different license category from the Apache-2.0 and MIT projects.
LLM Guard is archived — should I still use it?
Be careful. The protectai/llm-guard repo was archived around 2026-07-09, so it gets no new scanners, no security patches, and no model updates — and a security tool that stops getting updates slowly stops working, because its model-based scanners bit-rot as threats evolve past their training. For a quick internal prototype the current snapshot is fine. For anything you'll run and trust over time, prefer a maintained fork, a different tool, or the managed successor — LLM Guard's lineage now lives inside Palo Alto's Prisma AIRS, though that is a closed commercial platform rather than the MIT library.
One tool or several?
Usually several, because the four are different shapes, not competing brands. A realistic agent stack might use Guardrails AI to validate tool-call arguments against a schema, a Llama Guard / Prompt Guard classifier for content-safety and injection screening, and NeMo rails to keep a conversation on-policy — with the cheap deterministic checks running first and the expensive model checks only on what survives. The mistake is expecting any single tool to be the whole guardrail. Pick the shape that matches each job and compose them; NeMo in particular is designed to orchestrate the others into one layer.
Do guardrails add a lot of latency?
It depends entirely on which checks you turn on, and the cost is structural. Heuristic checks — regex, secrets, banned-substring, schema validation — are near-free. Every model-based check is a whole extra inference stacked on top of your actual model call, and they add up fast if you run several. The canonical contrast lives inside the Llama family: a 12B Llama Guard 4 is thorough but expensive, while a 22M Prompt Guard is cheap enough to run on every request. The production answer is to layer them — cheap deterministic filters first, expensive model checks only on what those don't resolve — so you pay for the heavy inference only when you actually need it.
What about Lakera, Bedrock/Azure guardrails, or Invariant?
Those are the managed and acquired side of the same field. Lakera Guard went to Check Point (Sept 2025) and is a managed API, not OSS. Invariant Labs went to Snyk (June 2025), stayed Apache-2.0, and is agent/MCP-native — its mcp-scan inspects MCP servers for tool-poisoning, which is worth knowing if you run MCP tools. The cloud platforms — OpenAI's Moderation API, AWS Bedrock Guardrails (which added an agentic per-step InvokeGuardrailChecks API in 2026), and Azure AI Content Safety (Prompt Shields for direct and indirect injection) — are all managed, not open source. If self-hosting and OSS aren't hard requirements, they're reasonable picks; this post focuses on the independent OSS survivors instead.
Further reading
On this wiki:
- Guardrails 101 — the companion concept: what a guardrail is, where it sits around the model, and the deterministic-vs-probabilistic split this whole post rests on. Start here.
- Prompt Injection 101 — why no guardrail "solves" injection, and the defense-in-depth mindset that replaces the one-filter fantasy.
- Structured Outputs — the deterministic backbone of agent safety, and Guardrails AI's home turf: validating tool-call arguments against a schema.
- What Is MCP — the protocol behind the agent threat surface: tool descriptions and outputs are untrusted input too.
- Prompt-Injection Defense 2026 — the layered mitigations (input screening, least-privilege tools, output checks, human-in-the-loop) that guardrails are one part of.
- Policy-as-Code for Agents — the discipline NeMo's rails DSL and LlamaFirewall are reaching toward: safety as code, not vibes.
- MCP Tool Poisoning — the attack Invariant's mcp-scan targets: a malicious tool description as an injection vector.
Project sources:
- NeMo Guardrails on GitHub — Apache-2.0 source (GitHub shows "NOASSERTION"), Colang, and the five rail types. Repo moved from the old
NVIDIA/NeMo-Guardrails. - Guardrails AI on GitHub — Apache-2.0 source, the validator/Guard model, the Hub, and the Pydantic + RAIL structured-output paths.
- PurpleLlama on GitHub — Meta's "Llama Protections": Llama Guard, Prompt Guard, Code Shield, and LlamaFirewall (models under the Llama Community License, evals code MIT).
- LLM Guard on GitHub — MIT source and the ~35-scanner pipeline. Note: the repo is archived (~2026-07-09) and no longer maintained.