OpenAI adds sandbox execution to Agents SDK for controlled, safer AI agent runs

OpenAI is trying to close one of the most painful gaps in enterprise AI agents: how to give a model access to files, code and a working environment without creating an uncontrolled risk for the company. The latest Agents SDK update adds native sandbox execution, an isolated execution layer where an agent can read and write files, run commands and work with dependencies without direct access to sensitive infrastructure.

For teams that have moved past demos and are trying to run agent workflows in production, this is not a cosmetic update. It targets three problems at once: governance, reliability and the cost of long runs.

Until now, developers faced an awkward choice. Model-agnostic frameworks offered freedom and avoided vendor lock-in, but often failed to unlock the full capabilities of frontier models. SDKs from the model providers themselves sat closer to the model, but did not always give enough transparency over the control harness. Managed agent APIs simplified deployment, but strictly limited where the agent runs and how it accesses corporate data.

OpenAI is trying to remove that trade-off with a model-native harness, a control layer better aligned with how models actually behave in long, multistep tasks. The updated SDK includes configurable memory, sandbox-aware orchestration, Codex-style filesystem tools, and support for MCP, AGENTS.md, shell and apply patch.

There is already a practical case at Oscar Health. The company tested the new infrastructure on a clinical workflow that requires parsing long medical records, extracting correct metadata and, more importantly, correctly identifying the boundaries of individual treatment episodes inside complex documents. According to the Oscar team, earlier approaches were not reliable enough for production. The new Agents SDK made the scenario viable: the system parses a patient's history faster, and staff get a clearer picture of a specific visit.

For integration with corporate environments, OpenAI also added a Manifest abstraction. It describes the agent's workspace: which local files can be mounted, where to write results and which storage systems to pull data from. AWS S3, Azure Blob Storage, Google Cloud Storage and Cloudflare R2 are supported.

Security is the update's main focus. OpenAI assumes that any agent that reads external content or executes generated code will sooner or later run into prompt injection and data exfiltration attempts. So the company separates the control harness from the compute layer. Credentials and the main control loop stay outside the environment where model-generated code runs. This lowers the chance that a malicious instruction inside a document or request can reach keys, internal APIs or neighboring systems.

Long-run reliability is addressed separately: if a container fails at step 19 of 20, the run does not have to start from scratch. The SDK stores state in an external layer, can take snapshots and rehydrate, then resume the task from the last checkpoint in a new container. This architecture both reduces cloud costs and simplifies scaling: runs can be spread across several sandboxes, subagents can be isolated and workloads parallelized.

For the market, this is a significant shift: OpenAI is promoting not just another agent SDK but a fuller infrastructure standard for running agentic systems in the enterprise. If the approach catches on, the company will strengthen its position not only at the model level but also at the operational layer, where decisions about security, auditing and deployment cost are made.

The new capabilities are already available through the API at standard pricing, first for Python, with TypeScript support announced for later. The logical next steps appear to be code mode, subagents and tighter integration with companies' internal tools, in other words everything needed to turn an agent from an experiment into a managed workflow.