OpenAI Now Runs Your Agent Harness. Read the Defaults.

The harness is the part of an agent nobody demos. It is the loop that calls the model, runs the tools, decides what to keep when the context fills, restarts the work that crashed at 3am, and holds a session together across hours. Every team building agents has written one, usually twice, and usually badly the first time.

On 10 September OpenAI put its own harness behind an API. The Agents API is in public beta for all developers, it runs the same Codex harness that powers Codex and ChatGPT for Work, and OpenAI operates it [1]. You send a task, a model, some tools and a choice of environment; OpenAI runs the loop, compacts the context, coordinates subagents and keeps the session alive for days.

That is a genuinely large piece of undifferentiated work to hand off. It is also a transfer of responsibility that is easy to misread, because the docs are much more specific about what you still own than the announcement is. The single most important sentence in this release is not in the blog post. It is the first line of the sandbox security page: "Agent-generated code can access the files, credentials, and network available to its environment." [3]

What you actually get

The shape is a managed harness plus an optional computer [2]:

• Agent: model, instructions, tools, MCP servers.
• Environment: openai_hosted, self_hosted, or none. Without an environment there is no sandbox, no Bash or apply-patch tools and no workspace files; the harness still runs the model and calls remote MCP tools [2].
• Session: a durable instance that keeps working and can be steered mid-turn.
• Events and items: a live stream of what the agent is doing, or webhooks if you prefer to be told.

Three harness features do the heavy lifting. Automatic compaction summarizes earlier context as a session approaches its limit, so workflows can span many context windows without you writing compaction logic [1]. Tool search loads tool definitions on demand instead of stuffing every schema into the prompt, and programmatic tool calling lets the agent run calls in parallel and filter results in code, bringing back only what matters [1]. Multi-agent delegates independent pieces to subagents with their own context, coordinated by the main agent, enabled with one flag and a max_concurrent_subagents number; the harness supplies the create, message, wait and interrupt tools itself [6].

For compute you pick OpenAI's hosted sandbox, your own infrastructure, or a partner: Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop and Vercel [1]. The hosted sandbox is a Linux workspace at /workspace with Python and Node, configurable packages, setup commands, input files and environment variables, and anything written to /workspace/outputs is published as an artifact [5].

On cost, the announcement says there are no additional fees for the Agents API and you pay for the tokens and tools your agents use [1]. The overview page is more precise and worth quoting to your finance people: model usage at the model's API rates, OpenAI tools at their standard rates, and OpenAI-hosted sandboxes at "standard container rates" [2]. No API surcharge is not the same as no infrastructure bill.

The defaults that decide your security posture

Read these four together, because they are the actual contract.

Outbound network is on unless you turn it off. The hosted sandbox's network.access has three values: enabled, disabled and restricted. The docs state that enabled is the default unless you inherit a template policy [5]. Restricted mode takes 1 to 100 exact host names, with no wildcards, no protocols, no paths and no ports, and subdomains and redirect destinations each need their own entry [5].

So an agent that only needs to call two internal services can reach the entire internet unless you say otherwise, and locking it down means enumerating hosts by hand. Given what we have covered about agents that turned a package registry into their own compute and storage, egress is not a hypothetical control.

Secrets in environment variables are readable by the agent. The hosted-sandbox page allows an env map, then says plainly: agent-generated code can read those values, and for secrets you should use vault credentials instead [5]. The security page goes further, and this is the line to paste into your design review: "Injecting a stored secret into the environment still exposes it to agent-generated code." [3]

Vaults exist because of that. A vault holds credentials outside the agent's instructions and configuration, attached to a session by vault_ids [4]. Two shapes: for MCP connections made from OpenAI's side, a static bearer token or OAuth credential that OpenAI presents to the server; for API calls made from inside the sandbox, an environment_variable credential where the sandbox only ever sees a placeholder and a network proxy swaps in the real secret for approved hosts [4]. Retrieving a vault or credential never returns the secret values [4].

That placeholder-and-proxy design is the most interesting piece of engineering in the release, and it is the right answer to a problem every agent team hits: you cannot let the thing that writes and runs arbitrary code hold your GitHub token, but it still needs to call GitHub.

Two keys, deliberately unequal. Your application key carries api.agents.read and api.agents.write for sessions plus api.responses.write for inference, and vault scopes if you manage vaults. The executor inside the environment gets a different key, CODEX_API_KEY, which can only connect environments and cannot authorize any other API action [3]. The docs assume agent code will read the executor key, and are explicit that your application key must stay outside the environment [3].

That is a threat model written by people who have watched this fail. It is also an admission worth saying out loud: the sandbox is not a place you put trusted material.

What this does not buy you

Handing OpenAI the harness removes a category of engineering, not a category of risk.

It does not make the sandbox a security boundary. We made this point about Microsoft's execution containers, using Microsoft's own README, and the same reading discipline applies here: OpenAI's security page tells you to isolate workloads in separate environments per user, create a dedicated project per workload, and broker third-party access through a proxy [3]. Those are your jobs, described in their documentation.

It does not make the agent's carry-forward state auditable. Automatic compaction is a headline feature [1], and it is the same mechanism we looked at last week when OpenAI published two reports about what its models wrote into their own compaction summaries during training, including notes telling the next context to conceal a fabricated figure. Convenient, and opaque by design.

It does not remove orchestration bugs, it relocates them. Subagents with independent context are a real speedup for independent work, and the docs are careful to say so: keep short tasks and dependent steps in the main agent, and agents editing the same files must coordinate [6]. A one-line flag that spawns three concurrent workers with no shared memory is exactly the setup that produced the conformity and collision problems we covered in 18 of 30 agents picking the same branch name.

And it is a beta. OpenAI says it will iterate quickly on feedback while working toward general availability [1]. The SDK surface sits under client.beta.agents, which is a sensible place to expect churn.

The honest evaluation checklist

If you are weighing this against the harness you already run, the questions that matter are not about features:

1. Where does your agent's code run, and what can it reach from there? Set network.access explicitly in every session, and prefer restricted with a host list you can defend in review.
2. Which secrets currently live in your agent's environment? Every one of them is readable by generated code today, whoever runs the harness. Move them to vault credentials with the proxy, or to function tools where your application holds the credential and returns only the result [3][4].
3. Can you reconstruct a session after the fact? You get an event stream, saved history, dashboard logs, per-turn traces, and token usage split between root agent and subagents, exportable as OTLP JSON. Check that against what your incident review actually needs.
4. What does a sandbox hour cost at your volume? Container rates, not zero [2].
5. What happens when you want out? The harness is open source and its logic is public [1], which lowers the lock-in argument considerably, but your session state, vault design and environment templates are OpenAI-shaped.

Buying the loop, keeping the blast radius

The Agents API is a good trade for most teams. Context compaction, session durability, subagent coordination and tool search are hard to build, thankless to maintain, and improve with each model release when someone else owns them [1].

What the trade does not include is the part that hurts when it goes wrong. OpenAI now runs the loop. You still decide what the loop can reach, what it can read, and what it can spend. Their documentation says so in plain language, in three separate places, before you write a line of code.

Read the defaults before the quickstart. The quickstart is designed to work. The defaults are what you will ship.

References

[1] OpenAI: Introducing the Agents API. Blog

[2] OpenAI: Agents API overview. Documentation

[3] OpenAI: Agents API sandbox security. Documentation

[4] OpenAI: Agents API vaults. Documentation

[5] OpenAI: OpenAI-hosted sandboxes. Documentation

[6] OpenAI: Agents API multi-agent. Documentation