OpenAI's Agents API: The Harness Moved to the Vendor, the Governance Did Not
- OpenAI opened the Agents API in public beta on 10 September 2026. It exposes the same harness that runs Codex: session orchestration, context compaction, subagent coordination, lazy tool loading and crash recovery, managed by OpenAI rather than by you.
- The API is built on four primitives: Agent (model, instructions, tools, MCP servers), Environment (an optional sandbox), Session (a durable agent instance) and events/items. Each one is a governance object, and none of them are in your asset inventory today.
- Sandboxing is a configuration value. The documented execution options are an OpenAI-hosted sandbox, a self-hosted sandbox via
codex exec-server, or no sandbox at all. A single field decides whether generated code runs in isolation. - Tool search loads tool definitions only when needed. The tool surface at any given moment is a subset of the tool surface you configured, resolved at runtime, which means a static review of the agent definition does not tell you what the agent could reach during a run.
- Sessions are designed to run for days. Long-lived autonomous execution with automatic compaction is now the default shape, not the exotic case. The person who started the session is usually not watching when it acts.
- Data processing is US-only and Zero Data Retention is unsupported in the beta, which rules the API out of several regulated production paths until that changes.
- The endpoint question does not go away. Codex CLI is the same harness running on developer laptops, with the developer's credentials and no managed sandbox between it and the filesystem.
OpenAI opened the Agents API in public beta on 10 September 2026. The pitch is straightforward: the harness that runs Codex, the part that manages context, coordinates subagents and keeps a long task alive, is now available behind one API call. There is no separate harness fee. You pay for tokens, tools and container time.
That is a genuinely useful piece of infrastructure, and it is also a quiet change to where agent execution happens in your organisation. The loop that used to run in a service you deployed, logged and firewalled now runs in OpenAI's infrastructure. This post is about what that moves, what it does not move, and what to inventory before the first prototype becomes production. The behavioural side of that shift is measurable too: the GPT-6.1 Sol system card shows how often a capable agent routes around a blocked action.
The four primitives, and what each one decides
The API is organised around four concepts. An Agent holds the model, the instructions, the tools and the MCP servers. An Environment is an optional sandbox that gives the agent file access and the ability to run commands. A Session is a durable instance of that agent, carrying state across turns without cold starts. Events and items are the inputs and outputs that flow through it.
Read those as governance objects rather than API surface. The Agent definition is a capability grant. The Environment field decides whether generated code runs in isolation. The Session is the unit that persists, and the one that will still be running after the engineer who started it has gone home. None of the four appear in a conventional asset inventory, which is the same gap described in the agentic AI attack surface, layer by layer.
Sandboxing is a configuration value, and one of its values is none
The documented execution options are worth stating plainly, because the difference between them is the difference between a contained blast radius and an uncontained one.
| Execution mode | Where code runs | What you control | What to verify |
|---|---|---|---|
| OpenAI-hosted sandbox | OpenAI infrastructure, the same sandboxing behind Codex and ChatGPT | Files, packages, skills and plugins loaded into the sandbox | Which packages and plugins are preloaded, and who approved them |
| Self-hosted sandbox | Your environment, via codex exec-server registered over an outbound WebSocket | Network egress, filesystem scope, credentials present in the container | That the container is actually isolated and not simply a build agent with a restricted key |
| No sandbox | Wherever your calling service runs | Everything, because nothing is contained by default | Whether this was a deliberate choice or the default nobody changed |
| Partner sandbox | Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop or Vercel | Whatever that provider exposes, plus a new vendor in the path | Third-party review, data residency, and who holds the provider credentials |
The failure mode here is not malice. It is that an agent definition with no environment field looks almost exactly like one with a hardened container, and the reviewer has no reason to notice. Codex has always made its isolation model explicit through sandbox modes and approval policies, covered in OpenAI Codex's sandbox and approval model. The Agents API keeps the capability and turns the decision into a field.
An agent definition without an environment is not an agent without a sandbox. It is an agent whose sandbox is your production service.
Tool search makes the tool surface dynamic
Tool search loads tool definitions only when they are needed, which is a sensible answer to token cost when an agent has access to dozens of MCP servers. It also means the set of tools available at any moment during a run is resolved at runtime rather than fixed at definition time.
For a security reviewer this is the important consequence: reading the Agent definition tells you the tool universe, not the tool surface. If one of those MCP servers changes its tool descriptions, the agent picks up the change on the next load with no redeploy and no diff in your repository. That is the exact mechanism behind MCP tool poisoning via hidden instructions, and a managed harness does nothing to interrupt it. If you do not already have one, an MCP server registry is the prerequisite control.
Sessions that outlive the person who started them
OpenAI's stated goal is infrastructure that keeps agents running reliably for days, with automatic compaction as a session approaches its context limit and crash recovery when something fails. Subagents split complex work into independent pieces, each with its own context, coordinated by a main agent.
This is the point where agent governance stops resembling application security and starts resembling workforce governance. A multi-day session with subagents is a small autonomous team with a credential, and the human who authorised it approved an intent, not a sequence of actions. Our survey of 132 enterprise leaders found this is the first thing that breaks in agentic runtime governance: organisations authorise an agent once and then have no mechanism to observe what it did over the following seventy-two hours.
Compaction deserves a specific mention. When earlier context is compacted away, the audit trail that a human would reconstruct from the transcript is compacted with it. If your answer to "what did this agent do on Tuesday" is "read the session", verify that Tuesday is still in the session.
What this does not change: the endpoint
It is tempting to read a managed harness as agent execution moving off the endpoint and into the cloud. It is not. The Codex CLI is the same harness, running on developer laptops, with the developer's credentials, their SSH agent, their cloud session tokens and their local MCP configuration. The Agents API adds a server-side execution path; it does not remove the local one. The differences between those surfaces are set out in OpenAI Codex across CLI, cloud and IDE.
So the inventory question splits in two. On the server side: which of our services instantiate agents, with which tools, which MCP servers and which sandbox mode. On the endpoint side: which machines run a Codex harness locally, what it is wired into, and what it can reach. Answering only one of those leaves a blind spot large enough to matter.
What to inventory this quarter
- Every service that calls the Agents API, with a named owner. Do this while the list is short, because prototypes become production quietly.
- The environment field on every agent definition. Flag any agent running with no sandbox as a deliberate exception that needs a written reason.
- Every MCP server referenced by an agent, pinned to a version, in a registry with an owner. Floating references are the supply-chain problem restated.
- Session duration and subagent fan-out limits. Decide what a reasonable maximum is before an agent discovers it for you.
- Data residency exposure. US-only processing with no Zero Data Retention is a hard boundary for some workloads, not a risk to note and move past.
- Endpoints running the Codex CLI, including which MCP servers are in local configs and which credentials sit in the environment those processes inherit.
The pattern underneath
Every serious agent platform is converging on the same design: a reliable managed harness, a configurable sandbox, MCP as the tool interface, and long-running sessions with subagents. Anthropic's enterprise MCP connector governance, Meta's Sentinel permission layer for Muse, and now OpenAI's Agents API are three versions of the same architecture. Each vendor governs its own agents well. None of them can tell you how many agents your organisation is running, which ones hold credentials that matter, or which employee wired a production database into a prototype on a Thursday afternoon.
That inventory is the part that has to come from your side of the boundary. You cannot govern what you cannot see, and a managed harness is, by design, the part you can see least.
Frequently asked questions
What is the OpenAI Agents API and how is it different from the Agents SDK?
The Agents API, in public beta since 10 September 2026, runs the Codex harness as a managed service. The distinction that matters for security is where the loop executes. With an SDK, the agent loop runs in your process, on your infrastructure, under your logging and your egress controls. With the Agents API, OpenAI runs the loop: it manages session state, compacts context as the session approaches its limit, coordinates subagents, loads tool definitions on demand and recovers from crashes. You get a more reliable agent and a smaller amount of directly observable execution. The tradeoff is not good or bad on its own, but it is a real change to where your evidence lives.
Is code from the Agents API sandboxed by default?
Sandboxing is a configuration choice with three documented options: an OpenAI-hosted sandbox built on the infrastructure behind Codex and ChatGPT, a self-hosted sandbox where you run codex exec-server in your own environment and register it over an outbound WebSocket connection, or no sandbox. Treat the environment field as a policy control, not a detail. In a code review, an agent definition that omits an environment looks almost identical to one that specifies a hardened container, and the difference is whether model-generated commands execute in isolation or in whatever process context your service happens to hold.
How do MCP servers work in the Agents API, and what should we govern?
MCP servers are a first-class part of the Agent definition, alongside custom functions and built-in tools such as web search. That makes every governance problem from the MCP ecosystem inherited rather than avoided: tool poisoning through hidden instructions in tool descriptions, credential scope on the server side, and servers whose behaviour changes without a version bump. Tool search compounds it by loading definitions lazily, so the set of tools resolved during a run is decided at runtime. Govern this the same way you govern any other dependency: a registry of approved MCP servers, a named owner per server, and pinned versions rather than floating references.
What does 'US-only, no Zero Data Retention' mean for us in practice?
In the public beta, processing happens in the United States and Zero Data Retention is unsupported. For an EU-headquartered organisation, a healthcare workload, or anything under a contractual ZDR commitment, that is a hard stop for production use rather than a risk to accept and document. The practical failure mode is not a deliberate policy breach. It is a team shipping a prototype on the beta, the prototype quietly becoming production, and the data residency question surfacing during an audit six months later. Inventory which of your services call the Agents API now, while the answer is still small.
Does a managed harness reduce our runtime security obligations?
It reduces your reliability engineering, not your security obligations. OpenAI now handles the parts that used to break: compaction, reconnection, subagent coordination. What it does not handle is whether the agent should have had access to that repository, whether the MCP server it called is one you approved, whether the credential it used was scoped correctly, and whether a multi-day session is still doing what it was started to do. Those are your decisions, and a more reliable harness makes them more consequential because the agent now completes the work instead of failing halfway.
How does Anomity help with agents built on the Agents API?
Anomity covers the planes an API-side console cannot. On the endpoint, the sensor inventories the Codex CLI and every other AI tool across the fleet, including the MCP servers wired into local configs, the credential patterns exposed in environment files, and the process lineage when an agent spawns something. In the browser, it surfaces which AI web services people are signed into and with which accounts, corporate or personal. And cloud discovery surfaces the OAuth grants that AI applications hold against Google Workspace and GitHub. That is the inventory you need before you can say which agents in your organisation are governed and which are not.
