LLM guardrails are controls placed around a language model: checks on what users and documents send in, checks on what the model returns, and limits on which tools and data it can touch. They reduce risk but do not make a model safe on their own, so they sit alongside least privilege and human approval.
Where do guardrails sit?
Think of three positions.
Input. Screen prompts and retrieved content before the model sees them. This is where you look for instructions hidden in documents, personal data that should not leave, and requests outside the product's purpose.
Output. Check the answer before it reaches a user or another system. Look for leaked secrets, unsafe content, malformed structure, and claims that should be grounded in a source.
Action. Limit what the model can do. This is the strongest position, because it works even when the model is fooled. A model that can only read one table cannot drop another.
What are the risks they address?
The OWASP Top 10 for LLM Applications is the neutral list to use. It includes prompt injection, sensitive information disclosure, insecure output handling and excessive agency, among others. Check the current version on the OWASP GenAI site, since the list is revised and numbering changes between releases.
NIST's Generative AI Profile, NIST AI 600-1, sits under the AI Risk Management Framework. It identifies risks specific to or made worse by generative AI and suggests actions for managing them. It is a planning document, not a product checklist.
What can guardrails not do?
Filters based on patterns miss rephrased attacks. Classifiers make mistakes in both directions, blocking real requests and passing bad ones. A guardrail that is itself an LLM can be manipulated by the same text it is judging.
For that reason, treat input and output checks as a layer that lowers volume, and put hard limits in the action layer, where rules are code and not judgement.
A constructed example
A support assistant reads customer emails and can issue refunds through an internal tool. An email contains text telling the assistant to refund a large amount to another account.
Input screening might catch the phrasing, or might not. The action guardrail does not depend on that: the refund tool caps the amount, accepts only the original payment method, and requires a human approval above a small threshold. The attack fails even if the model was persuaded.
How do you test guardrails?
Build a set of cases before you ship. Include normal requests that must pass, known bad requests that must be blocked, and borderline ones. Run the set on every change to the prompt, model or filter, and track both missed attacks and wrongly blocked requests. Keep the cases in version control. Review production logs for new patterns and add them to the set.
Do not publish working attack strings in public test suites. Keep those in a private repository.
How to check or apply this
- List every tool and data source the model can reach. Remove what it does not need.
- Give each tool the narrowest permission that works, and add limits and approvals for risky actions.
- Add input checks for untrusted content, especially retrieved documents and web pages.
- Add output checks for secrets, personal data and structure before results are used.
- Log prompts, tool calls and decisions with a trace ID.
- Build the test set and run it in CI.
- Define who reviews blocked and flagged events, and how often.
Safeguard's MCP Guardrail is built for the action layer when agents use tools over MCP, and the Safeguard MCP server at mcp.safeguard.sh has unlimited tool calls on every plan. Both are for teams wiring agents to developer and security tools.
Quick check
Are guardrails the same as a content filter?
No. A content filter is one kind of output check. Guardrails also include input screening, tool permissions, rate limits and approvals.
Which guardrail matters most?
Limits on actions. They hold even when the model is tricked, because they are enforced in code outside it.
Sources
Last reviewed: 18 October 2026.
