A guardrail is a mitigation, not a boundary
Input and output filters reduce how often something bad gets through. They are probabilistic controls and cannot be relied on the way an access check can: a security boundary either holds or is a bug, while a guardrail has a false-negative rate by construction.
Why it is like this
Both are worth having — defence in depth is cheaper than perfection — but they belong in different places in a threat model. Conflating them produces architectures whose only thing standing between a hostile input and a privileged action is a classifier.
Not to be confused with
Useless. A guardrail that catches most attempts is valuable precisely as a mitigation; what it cannot be is the sole control on an action you could not tolerate happening.
In practice
The test: if the filter fails open once, what happens? If the answer is unacceptable, the filter was never the right control — permissions were.
Source: OWASP Top 10 for Large Language Model Applications, 2025 — LLM01 and LLM06. Read on .
The OWASP Top 10 for LLM Applications is © the OWASP Foundation and published under a Creative Commons licence; NIST AI 600-1 is a US Government work in the public domain. These cards are independent commentary written in our own words. ytyk.org is not affiliated with or endorsed by the OWASP Foundation or NIST.
Predict Check yourself
An agent can issue refunds. The only thing preventing a fraudulent refund is a prompt-injection classifier on its input. What is wrong?
Show the answer
A classifier has a false-negative rate by construction, so it cannot be the sole control on an irreversible privileged action — that needs a permission or a human check.
Guardrails lower probability; permissions bound consequence. Irreversible actions need the second kind.