OpenAI Agent Builder Security: Agents SDK Guardrails After the AgentKit Shutdown

Yes, and anyone telling you the Agents SDK is a bare wrapper with no safety story has not read the guardrails documentation. It has more enforcement surface than most frameworks in this category. The useful question is not whether the controls exist but who has to write them, how far each one reaches, and what survives when the engineer who wrote it moves on.

Every row except the last column of the tracing story ends in the same four words: your developer, per agent. That is a perfectly reasonable design for a framework. It becomes a governance problem at a specific and predictable moment, which is the second agent.

With one agent, in-process controls are excellent. The person who wrote the tool wrote the guardrail, the review caught both, and reading the file tells you the policy. With nine agents across four repositories and three teams, the policy is the union of nine files nobody reads together, and there is no artifact that states it. Ask what your estate is allowed to do and the honest answer becomes a code search.

The pattern generalizes past OpenAI. We have now written the same finding about Bedrock AgentCore, Microsoft Foundry, Gemini Enterprise, Snowflake Cortex and Microsoft Agent 365. Every serious platform governs which data an agent may reach. None of them decides whether the action it just proposed should happen, because that is a business question and the platform does not know your business.

Most of the migration writing online treats this as one decision with two answers. It is closer to three, and the security consequences diverge sharply. Pick on the honest shape of the workflow rather than on which option sounds most professional.

If the workflow is deterministic, branchy, and the sort of thing a person could draw as a flowchart, the SDK is the faithful destination and the ChatGPT route will frustrate you. OpenAI says as much: workflows with strong determinism at their core may not migrate faithfully to a workspace agent. If the workflow is really a prompt with tools attached, and the value was the model rather than the graph, workspace agents is less work and a genuinely good outcome, and you should not buy anything from anyone to make that decision safer.

The third row deserves its own warning. Moving from one vendor's canvas to another vendor's canvas solves the deadline and reproduces the lesson. The reason this migration hurts is that the policy lived somewhere that could be switched off by a company that was not you. Choosing a different company to hold it is a schedule fix, not an architecture fix.

There is also a fourth possibility worth naming, because a surprising number of Agent Builder workflows are not agent problems at all. If what you built was a support triage flow that reads a ticket, classifies it and routes it, the destination may not be an agent framework at all but purpose-built support operations software, where routing and escalation are the product rather than something you assembled. Rebuilding an escalation ladder in TypeScript because a canvas is closing is a poor reason to own an escalation ladder in TypeScript.

The export gives you back a running agent quickly and an incomplete control set slowly. Work in this order and the gap never opens, rather than being discovered during a review in February.

1. Write down what each workflow was allowed to do, before you switch the canvas off. Open every workflow and list the tools, the connectors, the destinations they can write to, and any approval step on the graph. This takes an hour per workflow and it is the only moment the information is free. After November 30 it is archaeology. Save it as a plain table in the repository, not as a screenshot in a chat thread.

2. Re-review permissions rather than porting them. OpenAI's guidance names permissions specifically as something to review as you test. Most canvases accumulate a connector added to unblock a demo and never removed. The migration is the cheapest permission audit you will ever run, because the cost of removing something is a failing test rather than an incident.

3. Put the approval gates back before you put the agent in front of users. needs_approval is straightforward to add and easy to defer. The failure mode is shipping the migrated agent with the gate marked as a follow-up ticket, because the agent works fine without it right up until it does not. If approvals need to survive a process restart, reach a person on a phone, or expire on their own, that part is not in the SDK and you either build it or route the action through something that already has it. Approval gates for AI agents covers the shape that holds up in an audit.

4. Treat every tool result as untrusted input, not just the user's message. Input guardrails cover the first agent in the chain. The content that actually carries injection payloads in 2026 is the retrieved document, the web page, the ticket body and the tool response, and those arrive in the middle of the chain where input guardrails are not running. Prompt injection protection has to sit where untrusted content enters, which is rarely where the user does.

5. Decide what your evidence is, and confirm someone accepts it. This is the step teams skip and then repeat under time pressure. Ask whoever owns your next audit whether run traces answer their question. If the question is "who approved this action", traces do not answer it, and finding that out in October is much cheaper than finding it out the week the auditor arrives.

A migration deadline is an unusually good moment to do all five, because the code is open, the tests are being rewritten anyway, and nobody has to argue for a project. Three months after the migration, every one of these becomes a proposal competing against feature work.

We sell one thing and it is narrow. Most of the work in this migration is not ours, and pretending otherwise would waste a call. Here is the honest split.

Five of those eight rows tell you to buy nothing from us. That is not modesty, it is the actual shape of the problem, and a vendor who claims all eight is describing a roadmap rather than a product.

If you want the framework-level view rather than the migration view, OpenAI agent security covers the Agents SDK in production on its own terms. If your agents call third-party connectors, MCP server security deals with the trust decision you make every time a tool manifest enters the model context.

This is the single most expensive misunderstanding we see after a platform migration, and it is easy to hold because both artifacts are called logs and both look thorough on a screen.

A trace is written by the system that did the work, for the person debugging it. It answers what happened, in what order, with what latency. It is designed to be sampled, rotated and eventually deleted, because storing every trace forever is a cost with no debugging benefit. Nothing about it is built to be adversarial.

An audit record is written by the system that made the decision, for somebody who was not there and may not trust you. It answers a different question: what was this agent permitted to do at that moment, which rule decided, who held the authority, and can anyone prove the record has not been edited since. It has to survive the deletion of the service that produced it, because the question usually arrives after that service has been rewritten.

Teams that migrate off a managed builder usually inherit good tracing and no audit record, because the builder was quietly providing the second one through its configuration surface. The canvas was the policy document. When it closes, the policy document closes with it, and rebuilding that as a by-product of shipping code is not something the code asks you to do.