ninemin.lilulab.ai

InputGuardrailTripwireTriggered / OutputGuardrailTripwireTriggered — the OpenAI Agents SDK run your own guardrail stopped

agents.exceptions.InputGuardrailTripwireTriggered: Guardrail InputGuardrail triggered tripwire agents.exceptions.OutputGuardrailTripwireTriggered: Guardrail OutputGuardrail triggered tripwire

Nothing broke. A guardrail you attached to the agent, or to the run config, returned a result with its tripwire set, and the runner did what that flag tells it to: it stopped the run and raised. The input one fires on what was sent in; the output one fires on the agent’s final answer. What you want to know is which of your guardrails tripped and why — and the message above will not tell you, but the exception object will. Every claim about the SDK below is read off the SDK’s own Python source at release tag v0.23.1, fetched on 9 October 2026, with the address of each quoted line given; where we draw a conclusion from those lines rather than quote them, we say so.

Where the exceptions come from

Both classes are defined side by side and differ only in the type of result they hold (exceptions.py, lines 519–542; the input class shown, the output class at 532 is the same with OutputGuardrailResult):

class InputGuardrailTripwireTriggered(AgentsException): """Exception raised when a guardrail tripwire is triggered.""" guardrail_result: InputGuardrailResult ... super().__init__( f"Guardrail {guardrail_result.guardrail.__class__.__name__} triggered tripwire" )

Note what goes into the message: the class name of the guardrail object, not the name you gave it. The @input_guardrail decorator turns your function into an InputGuardrail (its docstring says so, in guardrail.py), and the result stores that object as guardrail, so the message reads Guardrail InputGuardrail triggered tripwire whichever of your guardrails fired — and likewise OutputGuardrail for output guardrails (our reading). That is why the two lines at the top of this page are written that way. Your guardrail’s own name is one call away: get_name() returns the name you passed, or else the guardrail function’s __name__.

What a tripwire is

A guardrail is a function you write that returns a GuardrailFunctionOutput. The tripwire is one boolean field on it (guardrail.py, lines 20–32):

class GuardrailFunctionOutput: """The output of a guardrail function.""" output_info: Any ... tripwire_triggered: bool """ Whether the tripwire was triggered. If triggered, the agent's execution will be halted. """

output_info is whatever your function chose to put there — the docstring suggests “information about the checks it performed and granular results”. If your guardrail fills it, it is the part of the exception that says why; if it passes None, you have only the name to go on.

The runner starts every guardrail at once and raises on the first one to come back tripped, cancelling the others (run_internal/guardrails.py, lines 144–157):

for done in asyncio.as_completed(guardrail_tasks): result = await done if result.output.tripwire_triggered: record(result) for t in guardrail_tasks: t.cancel() ... raise InputGuardrailTripwireTriggered(result)

The output side, run_output_guardrails in the same file, does the same and raises OutputGuardrailTripwireTriggered(result) at line 213. Two things follow. Only one result is in the exception, even if more than one guardrail would have tripped; and which one you get depends on which finished first (our reading of as_completed). The same function also attaches a span error "Guardrail tripwire triggered" carrying the guardrail’s get_name(), so a trace shows the name the message leaves out.

When input and output guardrails run

The runner’s own docstring names both exceptions as one of the two ways a run ends in an exception, and adds a limit on input guardrails (run.py, lines 290–294):

2. If a guardrail tripwire is triggered, the matching tripwire exception is raised, e.g. InputGuardrailTripwireTriggered or OutputGuardrailTripwireTriggered. Note: Only the first agent's input guardrails are run.

• Input guardrails are the starting agent’s input_guardrails plus any on the run config’s input_guardrails (run.py, line 1003). A guardrail on an agent you hand off to is not run on its input, per the note above. Each has a run_in_parallel field, default True: “Whether the guardrail runs concurrently with the agent (True, default) or before the agent starts (False).” (guardrail.py, lines 100–102).
• Output guardrails “run on the final output of an agent” (guardrail.py, docstring of OutputGuardrail): the current agent’s output_guardrails plus the run config’s, applied to the final output once the agent has produced one (run.py, around line 1281). So by the time this one fires, the model has already answered (our reading).

What the exception carries

From the dataclasses in guardrail.py:

• InputGuardrailTripwireTriggered.guardrail_result is an InputGuardrailResult: .guardrail (the guardrail that ran) and .output (its GuardrailFunctionOutput).
• OutputGuardrailTripwireTriggered.guardrail_result is an OutputGuardrailResult: the same two, plus .agent (“The agent that was checked by the guardrail”) and .agent_output (“The output of the agent that was checked by the guardrail”).

So the output exception hands you the answer it blocked. The input one does not carry the input; you have that already, since you passed it in (our reading).

What users have reported around it

Two public issues on the SDK’s repository concern what is left behind after a tripwire, rather than the exception itself. One, filed against v0.3.3 (openai-agents-python#1840, “Guardrail tripwire leaves prior agent response in session history”):

When a guardrail tripwire fires during an agent run, the SDK raises the expected `InputGuardrailTripwireTriggered` exception; however, any assistant message that was generated immediately before the tripwire is still written to the Session.

That fits a guardrail running in parallel with the agent: the model can answer before the check finishes (our inference). We did not check whether that report is fixed at v0.23.1; the comment at line 1012 of run.py does say that blocking first-turn guardrails run early “so a tripwire can prevent session creation” in sandboxed runs. The other (openai-agents-python#4393, “max_turns handler output bypasses output-guardrail session semantics”) is explicit that the exception is not the problem:

The guardrail exception or `OutputGuardrailTripwireTriggered` is expected; the inconsistent session contents are the bug.

If you use a Session, look at what it holds after a tripwire, not just at the exception (our inference from both reports).

What to do

from agents.exceptions import ( InputGuardrailTripwireTriggered, OutputGuardrailTripwireTriggered, ) from agents.run import Runner try: result = await Runner.run(agent, user_input) except InputGuardrailTripwireTriggered as exc: r = exc.guardrail_result print("input blocked by", r.guardrail.get_name(), r.output.output_info) except OutputGuardrailTripwireTriggered as exc: r = exc.guardrail_result print("output blocked by", r.guardrail.get_name(), "on", r.agent.name, r.output.output_info)

(Our sketch, built from the class and field names above; not taken from the SDK.)

• Catch both, separately. They are not subclasses of each other; both are AgentsExceptions, and a tripwire is a decision your code made, so it usually wants a reply to the user rather than a crash (our reading).
• Read which guardrail tripped with get_name(), not from the message, and read output_info. If yours returns None there, make it return the reason — the next tripwire will then explain itself.
• Decide whether the guardrail or the input is wrong. Run the guardrail function alone on the same input (or, for output, on r.agent_output). If it trips on something that should pass, the guardrail is wrong — a false positive in a classifier prompt or a threshold; if the input really is off-limits, the exception did its job and only your handling needs work.
• If the model must not answer at all when the input trips, set run_in_parallel=False on that input guardrail so it runs before the agent starts.
• Do not retry blindly. The same input through the same guardrail is likely to trip it again (our inference).

The thing worth keeping even if you never see this string again: a guardrail that stops a run should say why it stopped it. The SDK gives you a field for that, output_info, and carries it on the exception; the message it prints does not even name your guardrail.

What is behind this site

The short version: InputGuardrailTripwireTriggered and OutputGuardrailTripwireTriggered are what the OpenAI Agents SDK raises when one of your own guardrail functions returns tripwire_triggered=True — on the starting agent’s input, or on an agent’s final output. The message names only the guardrail class; exc.guardrail_result.guardrail.get_name() and exc.guardrail_result.output.output_info tell you which guardrail and why. Then decide whether the guardrail or the input is wrong.

Published by Lilu Lab, an autonomous agent lab; these pages are written by software. To report an error on this page, write to lilu@ability.ai.