OpenAI Agents SDK Guardrails: Input, Output, or Tool — Which Stops What?

Three Guardrail Types, Three Different Jobs

The Agents SDK treats guardrails as checks that run alongside an agent, not inside its prompt. An agent can carry input_guardrails and output_guardrails as configuration properties, and separately, individual tools can carry their own guardrails.

Input guardrails validate what came in, output guardrails validate what's about to go out, and tool guardrails validate a specific function call's arguments or result. The SDK documentation is explicit about where each one applies: input guardrails run only for the first agent in a chain, output guardrails run only for the agent that produces the final output, and tool guardrails run on every guarded function-tool invocation, including local MCP tools when their server configures guardrails, with input checks before execution and output checks after.

That scoping matters more than it looks. If your bot hands a task from a triage agent to a billing agent to a refund agent, an output guardrail attached only to the triage agent never looks at what the refund agent actually says to the customer — because output guardrails only fire on the last agent in the chain, not every agent that produces text along the way.

Sources: Agents - OpenAI Agents SDK, Guardrails - OpenAI Agents SDK.

Worked Example: A Refund Tool With All Three in Place

Illustrative case: a support bot has a billing agent with one tool, issue_refund. You want three things checked — that the customer's request isn't a prompt-injection attempt, that the agent's reply never leaks an internal customer ID, and that the refund tool's arguments never contain a raw card number.

Each check maps to a different guardrail type. The injection check is an input guardrail, since it needs to run before the agent does anything with the request. The customer-ID leak check is an output guardrail, since it needs to see the finished reply, not the agent's intermediate reasoning. The card-number check is a tool guardrail attached directly to issue_refund, since it only matters at the moment that specific tool is about to be called with specific arguments.

A tool input guardrail returns an allow or a reject_content result; a rejection stops that one tool call and sends a message back to the model instead of a hard exception, which lets the agent try a different approach rather than crashing the run. That's a meaningfully different failure mode than an input or output guardrail tripwire, which raises an exception that the calling code has to catch.

Sources: Guardrails - OpenAI Agents SDK, Tool guardrails - OpenAI Agents SDK.

Parallel Checks Save Latency, Blocking Checks Save Tokens

Input guardrails can run in two modes. The default, parallel execution, runs the guardrail concurrently with the agent itself, which gives the best latency since both start at the same time. The cost shows up only when the guardrail actually trips: if it fails, the agent may have already consumed tokens and executed tools before being cancelled.

The alternative, blocking execution, runs the guardrail to completion before the agent starts, so a tripwire means the agent never executes at all — no tokens spent, no tool calls made. For a cheap, fast classifier checking for obviously malicious input, parallel is usually fine; the rare false negative costs little. For a guardrail that's the only thing standing between a user and an irreversible tool call, the latency cost of blocking execution is worth paying, because the alternative is a tool call that already happened by the time the check fails.

There's a related timing knob specific to tool guardrails with approval flows: by default, a tool's input guardrails run after approval and immediately before execution. If you want the input check to run before the approval prompt is even shown — so a human never has to approve a call that was going to be rejected anyway — the SDK lets you set that ordering explicitly on the run configuration.

Sources: Guardrails - OpenAI Agents SDK.

Where Guardrails Don't Reach

Two gaps are easy to miss. First, output guardrails are intended to run on the final agent output, so an agent's output guardrails only run if that agent is the last one in the chain — a guardrail attached to an earlier agent in a handoff sequence never checks that agent's intermediate output, only its final one if it happens to be last.

Second, handoffs run through the SDK's own handoff pipeline rather than the function-tool pipeline, so tool guardrails do not apply to the handoff call itself. If your safety story depends on a tool guardrail catching something during a handoff from one agent to another, it won't — that check only fires on actual function-tool invocations, not on the handoff mechanism that moves control between agents.

Practically, put customer-facing output checks on each agent that may actually finish the run. For a handoff boundary, add an explicit application-level validation step at that boundary: an input guardrail on a receiving middle agent or an output guardrail on the departing agent does not automatically run. Continue enforcing checks on every guarded function-tool invocation after control transfers.

Sources: Guardrails - OpenAI Agents SDK.

Decision Rule: Match the Guardrail to the Risk

Official guidance frames the choice around what you're trying to stop and when: use input guardrails to block disallowed 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 specific function tool call, and human-in-the-loop approvals to pause before side effects like cancellations, edits, shell commands, or sensitive MCP actions.

That last category is worth separating from the first three. Guardrails are automated checks; human review is a pause for a person to decide. Together they define when a run should continue, pause, or stop — but a guardrail that reject_content's a bad tool call and a human approval gate that waits for a person to click approve are solving different problems, and conflating them tends to produce either too many pings to a human or too much blind trust in an automated check for something that actually warranted a person's judgment.

Sources: Guardrails and human review.