A guardrail is a classifier on the text going into or out of a model. It reads a prompt, a retrieved document or a completion, scores it against a taxonomy, and blocks or rewrites what scores badly. That is a useful thing to own. It is also a complete description of the category's limit: a guardrail never sees the action the model is about to take, only the words around it.
What do the open-source frameworks actually ship?
| Project | Owner | Licence | What it is |
|---|---|---|---|
| NeMo Guardrails | NVIDIA | Apache-2.0 | Programmable rails for conversational apps, written in Colang, a Python-like modelling language for dialogue flows |
| Guardrails AI | Guardrails AI | Apache-2.0 | Input and output Guards assembled from validators, plus structured output from Pydantic models |
| LLM Guard | Protect AI | MIT | A scanner library: 15 input scanners and 20 output scanners, including a PromptInjection scanner |
| Rebuff | Protect AI | Apache-2.0 | A dedicated prompt-injection detector with four layers |
NeMo Guardrails is the most structural of the four. It defines five rail types at different points in the pipeline: input rails on the user's message, dialog rails on how the model is prompted and what happens next, retrieval rails on content pulled in for RAG, execution rails on custom actions and tool inputs and outputs, and output rails on the completion. Execution rails are the closest thing in this survey to acting on an action, and they still run inside the application that is calling the tool.
Guardrails AI describes its own job in two parts: running Guards that "detect, quantify and mitigate specific types of risks", and generating structured data from LLMs. Validators are the unit, and the Guardrails Hub is the library you install them from. It is strongest on output shape and grounding rather than on adversarial input.
LLM Guard is the broadest scanner set of the four, and the one whose input list names prompt injection directly, alongside anonymisation, secrets, banned topics, invisible text and token limits. Note before you adopt it: the repository was archived in July 2026 and is read-only, with the maintainers stating the project and its models are no longer under active development.
Rebuff layers four detectors: heuristics to filter obviously malicious input, a dedicated model that analyses the prompt, a vector database of prior attacks, and canary tokens that reveal a leak after the fact. Its own README calls the project a prototype and says plainly that it cannot fully prevent prompt injection. The repository was archived in May 2025.
Hosted commercial classifiers exist on the same model, sold as a service rather than a library. The limits below apply to them identically.
What is the limit they share?
They enforce a public taxonomy, not your policy. A scanner knows about injection patterns, banned topics, PII and toxicity. It does not know that this account is a partner allowlist entry, that this host is a domain controller, or that a refund above a threshold needs two signatures. Those facts live in your policy, and no classifier ships with them.
They read the text the model could not disambiguate. A guardrail sits on the same undifferentiated token stream that caused the problem. Meaning-level attacks written in fluent, ordinary prose have no lexical signature to catch.
They degrade against an attacker who adapts. Out-of-band defences re-evaluated adaptively lose much of their reported effect (arXiv 2606.26479). This is the measured version of Simon Willison's objection to the category: vendors advertise catching 95% of attacks, and in security "95% is very much a failing grade" (Willison).
The standard body agrees about the ceiling. OWASP, in LLM01: "it is unclear if there are fool-proof methods of prevention for prompt injection" (OWASP).
Two of the four above are archived. That is not an argument against the category, but it is an operational fact: a detector that stops tracking new attack shapes is a detector whose effect decays while the deployment stays live.
So should you run one?
Yes, if you treat it as cost imposed on the attacker rather than as the control that lets you sign off. A scanner catches published payloads, encoded text and careless attempts, and it is cheap. Run it, measure it honestly with adversarial evaluation, and do not let its pass rate stand in for an answer about what the agent may do.
Three practical rules:
- Never let a guardrail's verdict be the only thing between a model and an irreversible action. It is a probability, and the action is not.
- Log what it blocks, and review it. The blocked set tells you what is being tried against you.
- Keep the taxonomy separate from the policy. A rule about what an agent may do belongs somewhere a person signs, not in a classifier's config.
Related: defences and their limits, containing a successful injection, and protecting agents from indirect injection.
If a guardrail cannot decide an action, what can?
An authorization layer, which is what ZIFFER is. ZIFFER is not a guardrail. It reads no prompt, scans no document, scores no text, and detects no injection.
It grades a proposed action. The agent holds no credential, so the result of a successful injection is a proposal rather than an effect, and the credential that performs the action sits with an executor on your side of the line. That proposal is graded against your signed policy, with the risk, the reversibility and the owner of the target recomputed from the policy rather than read from what the agent sent. Irreversible actions are held for a quorum of two named humans who sign the exact bytes that will run, and a hold nobody signs expires with nothing run. Every outcome, refusals included, leaves a signed receipt.
That is a different layer from the four above, not a better version of them. See agent authorization, the agent audit trail and every refusal.