OpenAI Agents SDK Guardrails: What They Cover, and the Gaps

OpenAI Agents SDK guardrails validate an agent's input before it runs and its output after it finishes, each able to halt execution via a tripwire flag — but per OpenAI's own documentation, that validation applies only to specific agents in a multi-agent chain, not to every agent a request passes through. The gap is not a bug; it is a scoping rule disclosed in the docs that a tutorial-style walkthrough tends to skip.

What Agents SDK guardrails actually check

Guardrails come in two kinds: input guardrails validate what the user sends before the agent starts working, and output guardrails validate what the agent produces after it finishes.

Each guardrail function returns a GuardrailFunctionOutput and can set a tripwire_triggered flag; when that flag is set, the SDK raises an exception and halts the flow before further processing continues (OpenAI Agents SDK docs). This is the SDK's primary mechanism for keeping an agent from acting on disallowed input or returning disallowed output — a chatbot guardrail that blocks off-topic requests, or an output guardrail that catches a response violating a content policy, are both implemented this way.

A separate, narrower mechanism — tool guardrails — wraps individual FunctionTool instances and runs before and after every invocation of that specific tool. Tool guardrails apply only to custom function tools; they do not cover hosted tools (the SDK's built-in tool implementations) or handoffs between agents (OpenAI Agents SDK docs).

Read across a row and the pattern is consistent: every guardrail type in the SDK is scoped to one thing — one agent's input, one agent's output, or one tool's calls — and none of the three is scoped to the workflow as a whole. That is a deliberate, documented design, not an oversight, but it means "we added guardrails" is not a workflow-level claim until someone has checked which agents and tools in the chain actually have one attached.

The design choice that creates the timing gap

Input guardrails default to running in parallel with the agent, not before it, which is a latency optimization with a governance cost.

Per the docs, running in parallel means the agent may already have consumed tokens and taken actions before a tripwire fires and cancels the run — the guardrail and the agent race, and the guardrail does not necessarily win first. A blocking mode exists that waits for the guardrail to finish before the agent starts, closing that exposure window at the cost of added latency (OpenAI Agents SDK docs). Which mode is appropriate depends entirely on what the agent's first action can do: an agent whose first tool call is read-only tolerates the parallel default reasonably well; an agent whose first action can send an email, make a payment, or call an irreversible tool does not.

The two scoping gaps that matter for multi-agent workflows

Both gaps below are stated directly in OpenAI's own documentation — they are the SDK's designed behavior, not an unpatched flaw, and they matter specifically once an agent workflow uses handoffs.

Scoping gap #1 — input guardrails run only for the first agent in the chain. In a multi-agent handoff workflow, the entry-point agent's input is checked once; when that agent hands off to a downstream agent, the downstream agent's input is not independently re-validated by the same input guardrail (OpenAI Agents SDK docs). If the handoff carries content from an untrusted source — a document, a tool result, another agent's output — that content reaches the downstream agent without the input guardrail's checks having run against it.

Scoping gap #2 — output guardrails run only for the agent that produces the final output. Intermediate agents in a handoff chain can produce outputs that are never checked, because only the last agent's final output passes through the output guardrail (OpenAI Agents SDK docs). A workflow where an early agent drafts a customer-facing message and a later agent merely forwards it can end up with unchecked content reaching the user, if the output guardrail was written assuming it covers everything the workflow produces.

Neither gap is exotic — they follow directly from a guardrail being attached to a specific agent definition rather than to the workflow as a whole, which is the same coverage-boundary mistake covered more generally in excessive agency controls for OWASP LLM06: a control that is real but scoped narrower than the surface it is assumed to protect.

The failure mode this produces in practice is a false sense of coverage rather than an outright missing control. A team that added an input guardrail to its entry-point agent and an output guardrail to its final agent has, correctly, satisfied both mechanisms exactly as documented — and can still have two or three unguarded agents in between, each capable of calling tools, forwarding content, or making a decision that never passes through either check. The gap is invisible in code review unless the reviewer is specifically counting guardrail attachments against the number of agents in the chain, not against the number of guardrail functions defined.

Controls a security team applies

None of the following requires waiting on an SDK change — all four close the gap at the workflow-design layer, using the mechanisms the SDK already exposes, and they follow the same principles laid out in the AI agent security guide.

• Attach guardrails per handoff boundary, not just at the entry point. If a downstream agent in a handoff chain can receive untrusted content, give that agent its own input guardrail rather than assuming the entry-point agent's guardrail covers it. See building secure multi-agent workflows for handoff-boundary design patterns that apply regardless of which SDK implements the handoff.
• Attach an output guardrail to every agent whose output could reach a user or an external system, not only the workflow's final agent — an intermediate agent's draft is still an output if anything downstream forwards it unmodified.
• Use blocking mode for any agent whose first action is irreversible or externally visible. The latency cost of blocking mode is the correct trade whenever the parallel default's race condition means a tripwire fires after damage is already done.
• Decide guardrail placement per agent, not once for the whole workflow. The parallel default is a reasonable choice for an agent whose early actions are read-only or reversible — the added latency of blocking mode buys nothing there. For an agent whose first tool call can send, pay, or delete, the same parallel default is the wrong choice by default, and should be switched to blocking explicitly rather than left at whatever the SDK does out of the box. Auditing guardrail placement mode alongside guardrail presence catches teams who added the right guardrail function but left it running in the mode appropriate to a different agent's risk profile.
• Treat handoffs themselves as a delegation-authorization decision, not just a data-flow one. Threat-modeling A2A delegation abuse and scoped tokens for sub-agent delegation cover the authorization question a content guardrail alone does not answer: whether the downstream agent should have received the delegated task at all, independent of whether its input passed a content check.
• Log every guardrail evaluation, tripwire or not, the same way any policy decision needs a record to be demonstrable after the fact — see guardrails versus policies for the distinction between a content check and an enforceable policy record.

FAQ

Do OpenAI Agents SDK guardrails cover every agent in a multi-agent workflow automatically? No. Input guardrails run only for the first agent in a handoff chain, and output guardrails run only for the agent producing the final output — a guardrail attached to one agent definition does not extend to agents it hands off to (OpenAI Agents SDK docs).

What is a tripwire in the Agents SDK guardrail model? A flag (tripwire_triggered) a guardrail function can set on its GuardrailFunctionOutput. When set, the SDK raises an exception and halts the run — the mechanism both input and output guardrails use to stop execution (OpenAI Agents SDK docs). The same flag mechanism is used for both guardrail types, so the question worth asking of any guardrail is not just whether it can trip, but which agents in the chain it actually watches.

Do tool guardrails close the handoff coverage gap? No — tool guardrails wrap individual custom function tools, running before and after each call to that specific tool. They do not cover hosted tools or handoffs, so they are a different, narrower control than input/output guardrails, not a substitute for per-agent coverage in a handoff chain.