OpenAI Agent Security: OpenAI Agents SDK Security, Guardrails, and AgentKit Controls

This inventory comes from OpenAI's own SDK reference rather than from a marketing comparison. If you are evaluating the Agents SDK, assume you get all of this and nothing beyond it.

OpenAI closes its safety guidance with a line worth quoting to anyone treating a vendor default as a finished control: even with these mitigations, agents will not be perfect and can still make mistakes or be tricked. The same guide notes that guardrails alone are not foolproof. That is the correct posture, and it is also the argument for a second layer.

Every item below assumes you did the work properly. These are not misconfigurations. They are consequences of where the SDK draws its boundaries.

• Multi-agent handoffs bypass input guardrails entirely. This is the big one. OpenAI documents that input guardrails run only for the first agent in the chain. A triage agent that validates input and then hands off to a specialist agent has protected the front door and left every interior door open. The content that reaches agent two came from agent one, and it is trusted by construction. If your workflow has handoffs, read multi-agent security next.
• Hosted tools are outside tool guardrails. WebSearchTool and CodeInterpreterTool are exactly the tools that pull untrusted content into the context and execute code, and OpenAI states tool guardrails do not cover them. The tools with the widest blast radius are the ones the wrapping mechanism skips.
• Guardrails are opt-in, per agent, written by the developer. There is no default. An agent shipped without a guardrail decorator is an agent with no input validation, and nothing in code review announces its absence. The diff that removes one looks like a diff that removes a function.
• The default execution mode trades safety for latency. Parallel is the default, so the agent can consume tokens and begin work before the guardrail cancels it. For a read-only agent that is a cost question. For an agent with a tool that writes, it is a correctness question.
• Approvals need somebody to answer them. The interruption and resumable state model is well built, but it resolves to a human decision. In a scheduled job or a headless service there is nobody, so teams either drop needsApproval or auto-approve, and the control becomes decorative. See human in the loop AI agents.
• The agent inherits an API key, not an identity. An OpenAI agent acts with whatever credential the process holds. Two agents from different teams sharing a key are indistinguishable afterward, which makes attribution guesswork. See AI agent identity.
• Tripwire exceptions are not an audit trail. Raising an exception tells your application that a run stopped. It is not an append-only, per-decision record of which tool call was requested, whether policy allowed it, and which agent asked. That distinction is the whole of agent audit trail.

None of this argues against the Agents SDK. It argues for a control point where the individual developer's guardrail code is not the last word. The general form of that argument is on AI runtime security.

AgentKit lowered the bar for building an agent, which is genuinely good and also means more agents exist than any security team was told about. The visual canvas in particular put workflow construction in the hands of people who do not read an SDK reference, and a misconfigured node is a security decision made by somebody who did not know they were making one.

OpenAI's own safety guidance for builders reduces to a short list, and it is worth following exactly:

1. Never put untrusted variables in developer messages. Pass untrusted input through user messages instead, so it carries less authority. OpenAI calls this out first, and it is the single highest-leverage line in the guide. A developer message is closer to an instruction; a user message is closer to data.
2. Define structured outputs between nodes. Enums, fixed schemas, and required field names remove the freeform text channel an attacker uses to smuggle instructions from one step to the next.
3. Keep tool approvals on for MCP operations. OpenAI recommends human review for MCP actions specifically, which is a fair reflection of how little anyone can vouch for a third-party server.
4. Sanitize inputs with guardrails. Redact personally identifiable information and screen for jailbreak attempts before the content reaches a privileged context.
5. Run trace graders and evals. Score real agent actions rather than only final answers, so a workflow that reached the right output through a wrong tool call is still caught.

The deprecation matters for security planning, not just roadmaps. OpenAI states it is deprecating Agent Builder, with shutdown scheduled for November 30, 2026, and points users toward ChatKit. Migrations are where controls get dropped: a guardrail that existed as a node on a canvas has to be rewritten as code, and the version that ships under deadline pressure is usually the one without it. If you are migrating, inventory which workflows had approval nodes and guardrail nodes before you start, and treat restoring them as part of the migration rather than a follow-up ticket.

MCP connections deserve their own attention here. Tool descriptions are prompt input, and Invariant Labs documented tool poisoning in April 2025 as malicious instructions embedded within MCP tool descriptions that are invisible to users but visible to AI models. The Cloud Security Alliance followed in July 2026 with a study of more than 45 real-world MCP servers reporting attack success rates above 60 percent, peaking at 72.8 percent. CVE-2025-54136, rated CVSS 8.8, captured the structural version: approving a tool definition once does not bind the server to that definition later. Pin tool definitions by SHA-256 hash, keep the allowed server list in version control, and treat every server response as untrusted. The full treatment is on MCP server security, and the architecture that enforces it centrally is on MCP gateway.

This is the sequence we recommend to teams running Agents SDK services beyond a single prototype. The first five are OpenAI's own guidance and cost nothing but an afternoon.

1. Put a guardrail on every agent, not the first one. Because input guardrails only run for the first agent in a chain, an agent reached by handoff needs its validation somewhere else: tool guardrails on its tools, or an inspection point outside the SDK. Assume any agent can become a downstream agent later.
2. Switch critical guardrails to blocking mode. Parallel is the default and lets work begin before cancellation. Any agent holding a tool that writes, pays, sends, or deletes should validate before it starts, and pay the latency.
3. Wrap hosted tools yourself. Tool guardrails skip WebSearchTool and CodeInterpreterTool. If you use them, treat everything they return as untrusted content and inspect it before it reaches the next step.
4. Use user messages for untrusted input, always. Never interpolate a ticket body, a retrieved document, or a form field into a developer message. This is free and it removes a whole class of injection.
5. Constrain the channels between steps. Structured outputs with enums and fixed schemas between nodes leave an attacker far less room than a free text handoff.
6. Give each agent its own identity. Not native to the SDK, where an agent acts with whatever API key the process holds. Without it, you cannot scope permissions per agent or attribute an action afterward. See AI agent identity.
7. Treat headless runs as a separate risk tier. Approvals assume a human. Scheduled jobs and background services need a narrower policy rather than the interactive one with approvals quietly disabled.
8. Isolate execution. If the agent runs code or shell commands, put it in a container with no network route except a proxy you control, and never hand it a raw credential. See AI agent sandboxing and the step-by-step version in how to sandbox an AI agent.
9. Run in observe mode first. Two weeks of watching what your agents actually call is worth more than a policy written from imagination, and it makes the switch to enforce uneventful. See tool permissions.
10. Keep one trail across every agent. One append-only record covering Agents SDK services, AgentKit workflows, and anything built on another framework, so a question about last Thursday has one place to be answered.

Steps one through five are code changes you should make today whether or not you ever buy anything. Steps six through ten need a control point outside the agent process, because each is a property no per-agent decorator can guarantee across teams.

Most teams run more than one framework, so the useful question is not which is safest in the abstract. It is which controls each one hands you, so you know what you are still on the hook for.

Claude wins the top half of that table on defaults, and it is worth choosing on those grounds. OpenAI has the better composable primitives, particularly tool guardrails and the approval state model, and beats LangChain comfortably. The bottom three rows are identical for all three, and they are the rows a security owner gets judged on. That is the gap we fill, and we fill it the same way regardless of framework, which is the point of being stack-neutral. Framework-specific notes are on Claude agent security and LangChain security.