Table of contents<\/h2>- What Are Guardrails?<\/a><\/li>
- Example: A Python-Only Guardrail<\/a><\/li>
- Integrating Guardrails Into the Main Agent<\/a><\/li>
- Testing the Guardrail<\/a><\/li>
- Why Guardrails Matter<\/a><\/li>
- Guardrails as Part of a Larger Agent Design<\/a><\/li>
- Conclusion<\/a><\/li><\/ul><\/div>\n\n\n\n
In my previous article on the OpenAI Agent SDK<\/a>, I showed how to build an AI agent using the SDK, We looked at an example where an agent could generate secure passwords, fetch the current time, and hand off coding questions to a specialist Python tutor sub-agent.<\/p>\n\n\n\nThat introduction laid the foundation for building powerful, multi-purpose agents. But in production environments, there\u2019s an equally important question: how do you keep agents focused and safe?<\/strong><\/p>\n\n\n\nThis is where guardrails<\/strong> come in.<\/p>\n\n\n\nWhat Are Guardrails?<\/h2>\n\n\n\n
Guardrails are constraints that define what an agent should or should not do. They act as protective boundaries around the agent\u2019s behavior, ensuring that it only processes valid or relevant input. Without them, an agent might attempt to answer queries outside its intended scope, leading to incorrect, misleading, or even risky outputs.<\/p>\n\n\n\n
For example, imagine you\u2019ve deployed a Python tutoring agent for a learning platform. You wouldn\u2019t want students asking it about fitness routines, political debates, or general trivia\u2014the agent should only handle Python coding questions<\/strong>.<\/p>\n\n\n\nThe OpenAI Agent SDK provides a mechanism for exactly this: input guardrails<\/strong>. These allow you to classify incoming prompts and decide whether they should be processed\u2014or blocked.<\/p>\n\n\n\n![\"Building](\"data:image\/svg+xml;base64,PHN2ZyB3aWR0aD0iMSIgaGVpZ2h0PSIxIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjwvc3ZnPg==\")
<\/figure>\n\n\n\nExample: A Python-Only Guardrail<\/h2>\n\n\n\n
Let\u2019s look at the implementation of a simple guardrail that ensures the user\u2019s query relates to Python code. If the question is unrelated, the guardrail trips a \u201ctripwire\u201d and the request is blocked.<\/p>\n\n\n\n
Here\u2019s the heart of the code:<\/p>\n\n\n\n
class PythonOutput(BaseModel):\n is_python: bool\n reasoning: str\n\nguardrail_agent = Agent(\n name=\"Guardrail check\",\n instructions=\"Check if the user is asking about python code.\",\n output_type=PythonOutput,\n)\n\nasync def python_guardrail(ctx, agent, input_data):\n result = await Runner.run(guardrail_agent, input_data, context=ctx.context)\n final_output = result.final_output_as(PythonOutput)\n return GuardrailFunctionOutput(\n output_info=final_output,\n tripwire_triggered=not final_output.is_python,\n )\n<\/code><\/pre>\n\n\n\nA dedicated guardrail_agent<\/code> is used to classify whether a question is Python-related. Its output is structured as a PythonOutput<\/code> model, returning both a Boolean (is_python<\/code>) and a reasoning string for transparency.<\/p>\n\n\n\nIf is_python<\/code> is False<\/code>, the guardrail function returns a GuardrailFunctionOutput<\/code> with tripwire_triggered=True<\/code>, effectively blocking the request.<\/p>\n\n\n\nIntegrating Guardrails Into the Main Agent<\/h2>\n\n\n\n
Once defined, the guardrail is attached to the main agent via InputGuardrail<\/code>. Here\u2019s how it looks:<\/p>\n\n\n\ntriage_agent = Agent(\n name=\"My Agent\",\n instructions=(\n \"You are a helpful agent. You can generate passwords, \"\n \"provide the current time, and hand off to a Python tutor agent \"\n \"for code-related queries.\"\n ),\n tools=[generate_password, get_time],\n handoffs=[python_tutor_agent],\n input_guardrails=[\n InputGuardrail(guardrail_function=python_guardrail),\n ],\n)\n<\/code><\/pre>\n\n\n\nThis ensures that all input<\/strong> passed to the agent is checked before execution.<\/p>\n\n\n\nIf the input doesn\u2019t pass the Python-only check, the SDK raises an InputGuardrailTripwireTriggered<\/code> exception. Developers can catch this exception and decide how to handle it\u2014for example, logging it, sending a polite error message to the user, or redirecting them to another resource.<\/p>\n\n\n\nTesting the Guardrail<\/h2>\n\n\n\n
Here\u2019s a quick test:<\/p>\n\n\n\n
try:\n result = await Runner.run(triage_agent, \"What is an air dyne bike?\")\n print(result.final_output)\nexcept InputGuardrailTripwireTriggered as e:\n print(\"Guardrail blocked this input:\", e)\n\ntry:\n result = await Runner.run(triage_agent, \"Explain what a class is in Python.\")\n print(result.final_output)\nexcept InputGuardrailTripwireTriggered as e:\n print(\"Guardrail blocked this input:\", e)\n<\/code><\/pre>\n\n\n\n\n- The first input, about a fitness bike, is blocked by the guardrail.<\/li>\n\n\n\n
- The second input, asking about Python classes, passes through and is handled by the Python tutor sub-agent.<\/li>\n<\/ul>\n\n\n\n
This demonstrates how guardrails enforce scope<\/strong> while still allowing flexibility within their boundaries.<\/p>\n\n\n\nWhy Guardrails Matter<\/h2>\n\n\n\n
Adding guardrails provides several benefits:<\/p>\n\n\n\n
\n- Focus and Relevance<\/strong>
Agents won\u2019t drift into answering unrelated questions, improving user trust and experience.<\/li>\n\n\n\n- Safety and Compliance<\/strong>
In enterprise settings, guardrails help prevent outputs that violate business rules or compliance requirements.<\/li>\n\n\n\n- Transparency and Debugging<\/strong>
Because the guardrail\u2019s decision is based on structured output, developers can log both the classification (is_python<\/code>) and the reasoning for auditing.<\/li>\n\n\n\n- Extensibility<\/strong>
The same pattern can be extended. For example, you could create guardrails for:\n\n- Restricting to specific domains (e.g., finance only).<\/li>\n\n\n\n
- Blocking sensitive topics.<\/li>\n\n\n\n
- Filtering based on user roles or permissions.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n
Guardrails as Part of a Larger Agent Design<\/h2>\n\n\n\n
In my earlier post<\/a> about the OpenAI Agent SDK, we explored how agents can combine tools and handoffs to create flexible multi-agent workflows. Guardrails add another layer: control and governance<\/strong>.<\/p>\n\n\n\nThink of it this way:<\/p>\n\n\n\n
\n- Tools<\/strong> give your agent capabilities.<\/li>\n\n\n\n
- Handoffs<\/strong> let it collaborate with specialists.<\/li>\n\n\n\n
- Guardrails<\/strong> keep it safe and on track.<\/li>\n<\/ul>\n\n\n\n
Together, they form a powerful framework for building production-ready AI agents.<\/p>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
Guardrails in the OpenAI Agent SDK are not just technical niceties\u2014they\u2019re essential for building safe, reliable, and business-ready AI systems.<\/p>\n\n\n\n
By implementing even a simple Python-only guardrail, as we did in this example, you can enforce strict domain boundaries and prevent misuse. As your agent ecosystem grows, combining tools, handoffs, and guardrails will give you the right balance between power and safety.<\/p>\n\n\n\n
If you\u2019re experimenting with the Agent SDK, I encourage you to start small\u2014add a guardrail to your existing agent from the previous tutorial<\/a>. From there, think about what \u201crules of engagement\u201d your agents need in your specific environment. Guardrails give you the mechanism to implement them cleanly and transparently.<\/p>\n\n\n\n
In my previous article on the OpenAI Agent SDK<\/a>, I showed how to build an AI agent using the SDK, We looked at an example where an agent could generate secure passwords, fetch the current time, and hand off coding questions to a specialist Python tutor sub-agent.<\/p>\n\n\n\n That introduction laid the foundation for building powerful, multi-purpose agents. But in production environments, there\u2019s an equally important question: how do you keep agents focused and safe?<\/strong><\/p>\n\n\n\n This is where guardrails<\/strong> come in.<\/p>\n\n\n\n Guardrails are constraints that define what an agent should or should not do. They act as protective boundaries around the agent\u2019s behavior, ensuring that it only processes valid or relevant input. Without them, an agent might attempt to answer queries outside its intended scope, leading to incorrect, misleading, or even risky outputs.<\/p>\n\n\n\n For example, imagine you\u2019ve deployed a Python tutoring agent for a learning platform. You wouldn\u2019t want students asking it about fitness routines, political debates, or general trivia\u2014the agent should only handle Python coding questions<\/strong>.<\/p>\n\n\n\n The OpenAI Agent SDK provides a mechanism for exactly this: input guardrails<\/strong>. These allow you to classify incoming prompts and decide whether they should be processed\u2014or blocked.<\/p>\n\n\n\n Let\u2019s look at the implementation of a simple guardrail that ensures the user\u2019s query relates to Python code. If the question is unrelated, the guardrail trips a \u201ctripwire\u201d and the request is blocked.<\/p>\n\n\n\n Here\u2019s the heart of the code:<\/p>\n\n\n\n A dedicated If Once defined, the guardrail is attached to the main agent via This ensures that all input<\/strong> passed to the agent is checked before execution.<\/p>\n\n\n\n If the input doesn\u2019t pass the Python-only check, the SDK raises an Here\u2019s a quick test:<\/p>\n\n\n\n This demonstrates how guardrails enforce scope<\/strong> while still allowing flexibility within their boundaries.<\/p>\n\n\n\n Adding guardrails provides several benefits:<\/p>\n\n\n\n In my earlier post<\/a> about the OpenAI Agent SDK, we explored how agents can combine tools and handoffs to create flexible multi-agent workflows. Guardrails add another layer: control and governance<\/strong>.<\/p>\n\n\n\n Think of it this way:<\/p>\n\n\n\n Together, they form a powerful framework for building production-ready AI agents.<\/p>\n\n\n\n Guardrails in the OpenAI Agent SDK are not just technical niceties\u2014they\u2019re essential for building safe, reliable, and business-ready AI systems.<\/p>\n\n\n\n By implementing even a simple Python-only guardrail, as we did in this example, you can enforce strict domain boundaries and prevent misuse. As your agent ecosystem grows, combining tools, handoffs, and guardrails will give you the right balance between power and safety.<\/p>\n\n\n\n If you\u2019re experimenting with the Agent SDK, I encourage you to start small\u2014add a guardrail to your existing agent from the previous tutorial<\/a>. From there, think about what \u201crules of engagement\u201d your agents need in your specific environment. Guardrails give you the mechanism to implement them cleanly and transparently.<\/p>\n\n\n\nWhat Are Guardrails?<\/h2>\n\n\n\n
![\"Building](\"\/wp-content\/uploads\/2025\/08\/Guardrails-1024x683.png\")
<\/figure>\n\n\n\nExample: A Python-Only Guardrail<\/h2>\n\n\n\n
class PythonOutput(BaseModel):\n is_python: bool\n reasoning: str\n\nguardrail_agent = Agent(\n name=\"Guardrail check\",\n instructions=\"Check if the user is asking about python code.\",\n output_type=PythonOutput,\n)\n\nasync def python_guardrail(ctx, agent, input_data):\n result = await Runner.run(guardrail_agent, input_data, context=ctx.context)\n final_output = result.final_output_as(PythonOutput)\n return GuardrailFunctionOutput(\n output_info=final_output,\n tripwire_triggered=not final_output.is_python,\n )\n<\/code><\/pre>\n\n\n\nguardrail_agent<\/code> is used to classify whether a question is Python-related. Its output is structured as a PythonOutput<\/code> model, returning both a Boolean (is_python<\/code>) and a reasoning string for transparency.<\/p>\n\n\n\nis_python<\/code> is False<\/code>, the guardrail function returns a GuardrailFunctionOutput<\/code> with tripwire_triggered=True<\/code>, effectively blocking the request.<\/p>\n\n\n\nIntegrating Guardrails Into the Main Agent<\/h2>\n\n\n\n
InputGuardrail<\/code>. Here\u2019s how it looks:<\/p>\n\n\n\ntriage_agent = Agent(\n name=\"My Agent\",\n instructions=(\n \"You are a helpful agent. You can generate passwords, \"\n \"provide the current time, and hand off to a Python tutor agent \"\n \"for code-related queries.\"\n ),\n tools=[generate_password, get_time],\n handoffs=[python_tutor_agent],\n input_guardrails=[\n InputGuardrail(guardrail_function=python_guardrail),\n ],\n)\n<\/code><\/pre>\n\n\n\nInputGuardrailTripwireTriggered<\/code> exception. Developers can catch this exception and decide how to handle it\u2014for example, logging it, sending a polite error message to the user, or redirecting them to another resource.<\/p>\n\n\n\nTesting the Guardrail<\/h2>\n\n\n\n
try:\n result = await Runner.run(triage_agent, \"What is an air dyne bike?\")\n print(result.final_output)\nexcept InputGuardrailTripwireTriggered as e:\n print(\"Guardrail blocked this input:\", e)\n\ntry:\n result = await Runner.run(triage_agent, \"Explain what a class is in Python.\")\n print(result.final_output)\nexcept InputGuardrailTripwireTriggered as e:\n print(\"Guardrail blocked this input:\", e)\n<\/code><\/pre>\n\n\n\n\n
Why Guardrails Matter<\/h2>\n\n\n\n
\n
Agents won\u2019t drift into answering unrelated questions, improving user trust and experience.<\/li>\n\n\n\n
In enterprise settings, guardrails help prevent outputs that violate business rules or compliance requirements.<\/li>\n\n\n\n
Because the guardrail\u2019s decision is based on structured output, developers can log both the classification (is_python<\/code>) and the reasoning for auditing.<\/li>\n\n\n\n
The same pattern can be extended. For example, you could create guardrails for:\n\n
Guardrails as Part of a Larger Agent Design<\/h2>\n\n\n\n
\n
Conclusion<\/h2>\n\n\n\n