Guardrails are filters that sit on the input and the output of your LLM app. Input guardrails check what comes in before the model sees it. Output guardrails check what the model produces before the user sees it.
Input guardrails#
| Check | What it catches |
|---|---|
| Blocked topics | Requests your app should not handle |
| PII detection | Personal data that should not reach the model |
| Injection detection | Inputs a classifier flags as likely prompt injection |
| Toxicity | Abusive content, filtered before it influences the model |
Output guardrails#
| Check | What it catches |
|---|---|
| Blocked content | Answers your app must not give |
| PII in output | Personal data the model repeated from its context |
| Format validation | Output that does not match the expected schema |
Not a complete defense#
Guardrails reduce the attack surface. They do not remove it.
- A sophisticated injection can get past an injection classifier.
- A toxicity filter can be fooled by subtle rephrasing.
Treat guardrails as one layer in defense in depth, never the only layer.
They also have costs:
- Every check adds latency, and a model-based check adds cost.
- A filter that is too aggressive creates false positives that block legitimate requests.
The lethal trifecta#
An agent becomes a serious exfiltration risk when it has all three of these at once:
| Leg | Examples |
|---|---|
| Access to private data | The user's inbox, internal documents, a customer database |
| Exposure to untrusted content | Web pages, incoming emails, uploaded files |
| A way to send data out | Web requests, an email tool, links in rendered output |
With all three, a successful injection in the untrusted content can tell the model to read private data and send it out, silently.
The fix is to remove at least one leg. For example, an assistant that reads web pages and private documents should have no tool that makes outbound requests. Or an assistant that can send email should not also read untrusted content without a human approving every send.
Short line#
Input guardrails filter blocked topics, PII, likely injections and toxicity before the model, and output guardrails filter blocked content, leaked PII and bad formats after. They are one layer, not a complete defense. An agent with private data, untrusted content and a way to send data out can be made to exfiltrate, so remove at least one of the three.
Key takeaways#
- Input guardrails: blocked topics, PII detection, injection detection, toxicity.
- Output guardrails: blocked content, PII the model repeated, format validation.
- Guardrails can be bypassed. Use them as one layer of defense in depth.
- Each check adds latency and cost, and over-aggressive filters block legitimate requests.
- The lethal trifecta: private data, untrusted content and a way to send data out.
- Remove at least one leg of the trifecta.