AI guardrails are the checks and limits you put around a language model so your app or agent only does what you intend. They work in layers: screen what goes in, validate what comes out, restrict which tools and data the model can touch, and require a human to approve risky actions. No single layer is enough on its own, because models can be tricked or simply make mistakes.
OpenAI's Agents SDK guardrails docs state the core idea: "Guardrails enable you to do checks and validations of user input and agent output." OpenAI's guardrails and human review guide adds the second half: "Use guardrails for automatic checks and human review for approval decisions. Together, they define when a run should continue, pause, or stop."
This page covers each layer, with what Anthropic, OpenAI and Claude Code document for it. Sources were checked on 27 October 2026.
What are the layers of AI guardrails?
Think of guardrails as a set of controls at different points in a request:
| Layer | Where it runs | Example |
|---|---|---|
| Input checks | Before the main model | Block off-topic or jailbreak attempts with a small classifier |
| Instructions | In the system prompt | State boundaries and how to refuse |
| Tool checks | Before and after each tool call | Validate arguments, screen tool results for injected instructions |
| Permissions | In the runtime, outside the model | Allow, ask or deny rules for shell commands and file edits |
| Sandboxing | Operating system level | Limit filesystem and network access for every process |
| Human approval | Before side effects | Pause until a person approves a deploy or deletion |
| Output checks | Before the answer leaves | Validate format, filter leaked secrets, check claims |
| Monitoring | After the fact | Review logs for signs a guardrail was bypassed |
OpenAI's guide maps the first few to concrete controls: input guardrails to "Block disallowed user requests before the main model runs," output guardrails to "Validate or redact the final output before it leaves the system," tool guardrails to "Check arguments or results around a function tool call," and human-in-the-loop approvals to "Pause before side effects like cancellations, edits, shell commands, or sensitive MCP actions."
How do input guardrails work?
A fast check runs on the request and either lets it through or stops the run. Anthropic's guide to mitigating jailbreaks and prompt injections recommends harmlessness screens: "Use a lightweight model such as Claude Haiku 5.5 to pre-screen user input before it reaches your main conversation." It suggests using structured outputs so the screen returns a simple classification, and notes that Claude Haiku 5.5 can decline the screening request itself, so you should "treat a response with stop_reason: "refusal" as a harmful verdict."
In OpenAI's Agents SDK, an input guardrail returns a result with a tripwire flag. If the tripwire is triggered, the SDK raises an InputGuardrailTripwireTriggered exception so your code can respond. The SDK offers two execution modes:
- Parallel (the default,
run_in_parallel=True): best latency, but "the agent may have already consumed tokens and executed tools before being cancelled." - Blocking (
run_in_parallel=False): "If the guardrail tripwire is triggered, the agent never executes, preventing token consumption and tool execution."
Use blocking mode when the main agent can take actions with side effects.
How do output guardrails work?
They check the final answer before it reaches the user or another system. Common checks include schema validation, filters for secrets or personal data, and claim checks against source documents.
Anthropic's guide to reducing prompt leak suggests post-processing: "Filter Claude's outputs for keywords that might indicate a leak," using regular expressions, keyword filters or a prompted LLM for subtler cases. It also advises trying "monitoring techniques first, such as output screening and post-processing," before making the prompt itself more complex.
For factual accuracy, Anthropic's guide to reducing hallucinations recommends letting the model say "I don't know" and having it verify each claim with a supporting quote, retracting claims it cannot support. It is candid that these techniques "don't eliminate them entirely." See LLM hallucinations for more.
Enforcing a schema is itself an output guardrail. OpenAI's Safety in building agents guide, written for its Agent Builder (which OpenAI is deprecating, with shutdown scheduled for November 30, 2026), says that defining structured outputs between nodes (enums, fixed schemas, required field names) eliminates "freeform channels that attackers can exploit to smuggle instructions or data." The advice applies to any multi-step workflow. See structured outputs.
Where should tool guardrails go?
Next to the tool that causes the side effect. OpenAI's docs explain why: agent-level guardrails do not run everywhere. "Input guardrails run only for the first agent in the chain," and "Output guardrails run only for the agent that produces the final output." Its advice: "If you need checks around every custom tool call in a manager-style workflow, don't rely only on agent-level input or output guardrails. Put validation next to the tool that creates the side effect."
The Agents SDK's tool guardrails wrap function tools: input tool guardrails run before the tool and "can skip the call, replace the output with a message, or raise a tripwire," and output tool guardrails run after it. The docs also list tool types that do not use this pipeline, including hosted tools and built-in execution tools such as the shell tool, so check coverage for the tools you use.
Tool results are also where indirect prompt injection arrives. Anthropic recommends delivering third-party content "inside tool_result blocks, never in system prompts or plain user text blocks," stating in the system prompt that tool content is untrusted data, and screening tool outputs with a small classifier before the main model acts on them. The prompt injection guide for coding agents covers this threat in depth.
Why are permissions stronger than prompt instructions?
Because they are enforced by code, not by the model's judgment. Claude Code's permissions docs are direct about this: "Permission rules are enforced by Claude Code, not by the model. Instructions in your prompt or CLAUDE.md shape what Claude tries to do, but they don't change what Claude Code allows."
Claude Code uses allow, ask and deny rules, and "Rules are evaluated in order: deny, then ask, then allow." A broad deny rule wins even over a narrower allow rule: "An allow rule can't carve an exception out of a deny rule." The docs also note that Bash rules match command text, so for "filesystem and network enforcement that doesn't depend on the command text, use sandboxing." PreToolUse hooks add custom logic, and a hook that exits with code 2 "stops the tool call before permission rules are evaluated."
Anthropic's general advice for agents follows the same principle of least privilege: "don't give Claude access to secrets it doesn't need, run tools in sandboxed environments, and scope permissions as narrowly as possible." For setup details, see Claude Code permissions and Claude Code sandbox.
When should a human approve an action?
Before anything hard to undo. OpenAI's guide describes approvals as "the human-in-the-loop path for tool calls. The model can still decide that an action is needed, but the run pauses until you approve or reject it." The run records an approval interruption, your app approves or rejects it, and you resume the same run from saved state. If the review might take time, the guide says to serialize and store the state and resume later, still as the same run.
Prompts can reinforce this. Anthropic's prompting best practices include a sample instruction to "Consider the reversibility and potential impact of your actions" and to ask the user before actions that "are hard to reverse, affect shared systems, or could be destructive," listing examples such as deleting files or branches, git push --force, and commenting on PRs.
Treat that prompt as a second line, not the main control. Claude Code's docs warn that its bypassPermissions mode, which skips prompts, should only be used "in isolated environments like containers or VMs where Claude Code can't cause damage."
How do you know your guardrails work?
Test them on purpose, then keep watching. Anthropic recommends you "Red-team your own agent": before deploying, feed it documents, emails and tool outputs that contain injection attempts and confirm the screens and confirmation steps catch them. It also recommends continuous monitoring: "Regularly analyze outputs for signs of successful injection."
Anthropic's Building effective agents adds a design tip for screening: running one model on the user's request while another screens it "tends to perform better than having the same LLM call handle both guardrails and the core response." For autonomous agents it recommends "extensive testing in sandboxed environments, along with the appropriate guardrails."
Screening prompts and approval policies are worth versioning like code. Kipt keeps prompts as Markdown in a private GitHub repo you own, with {{name:default}} blanks, so a tested screening prompt can be reused across projects instead of rewritten.
What should you read next?
Prompt injection in coding agents explains the main attack guardrails defend against. Claude Code permissions and Codex approvals and sandbox show runtime controls in two coding agents. Prompt chaining covers where gates fit between steps of a workflow.