Agent Sandboxes: Durable State for Long-Running Work
OpenAI’s updated Agents SDK makes sandbox execution and durable state easier to compose, but production safety still depends on manifests, credential separation, approvals, and recovery evid
Source: OpenAI — The next evolution of the Agents SDK
TL;DR
OpenAI’s updated Agents SDK treats the sandbox as part of the agent runtime rather than as an afterthought. It adds native sandbox execution, a Manifest abstraction for workspace boundaries, and state externalization that supports snapshotting and rehydration. Those primitives can make long-running work more durable. They do not make an agent safe by themselves. Netics’ recommendation is to treat the harness, the compute environment, the credentials, and the approval path as separate control surfaces. The useful change is the execution boundary; a Manifest is a contract, not a security policy; snapshotting changes the failure model; and what teams should verify before production is every access and recovery boundary.
The useful change is the execution boundary
OpenAI describes a model-native harness for agents that inspect files, run commands, edit code, and continue across long tasks. The updated SDK brings together configurable memory, sandbox-aware orchestration, MCP, skills, AGENTS.md, shell execution, and patch-based file editing. The important point is not the number of primitives. It is that the agent loop receives an explicit execution environment with defined inputs and outputs.
That is a better starting point than giving a model an opaque process with inherited files and standing credentials. A controlled workspace makes it possible to state what the agent can read, what it can write, and what it must return for review.
A Manifest is a contract, not a security policy
The SDK’s Manifest abstraction describes workspace mounts and output directories. OpenAI says the abstraction can connect data from services such as Amazon S3, Google Cloud Storage, Azure Blob Storage, and Cloudflare R2. That portability is operationally useful: the same task shape can be moved between local and hosted environments without rewriting every file boundary.
But a manifest answers only part of the security question. It can define a data room while leaving network access, secret injection, command permissions, and human approvals unresolved. Netics recommends treating each manifest as a versioned contract with an owner, a purpose, an expiration path, and a test that proves the agent cannot read outside the declared scope.
Separate harness authority from model-generated compute
OpenAI explicitly frames prompt injection and exfiltration as assumptions agent systems should make. Separating the harness from compute helps keep credentials away from environments where model-generated code executes. This is the correct direction, but the separation must be enforced in the deployment architecture, not merely described in instructions.
The harness should decide which tools exist, which credentials are available, and which actions require approval. The compute environment should receive the minimum capability needed for one task. Production writes, external messages, network changes, and access to sensitive data deserve explicit gates. A model request to perform one of those actions is not proof that the action is authorized.
Snapshotting changes the failure model
Externalized state, snapshotting, and rehydration allow a run to continue in a fresh sandbox when the original container expires or fails. That matters for long-running analysis, code changes, and multi-step workflows. The agent does not need to treat container loss as total task loss.
Durability also creates new obligations. A snapshot can preserve stale permissions, sensitive inputs, or an unsafe intermediate state. Netics recommends recording who created the snapshot, which manifest was active, what approvals were granted, and what must be revalidated after rehydration. Recovery is not complete until the restored run passes the same identity, scope, and output checks as the original run.
What teams should verify before production
Before adopting a sandboxed agent workflow, verify four boundaries: the workspace boundary, the credential boundary, the network boundary, and the human decision boundary. Test a successful run and a deliberately blocked run. Expire the sandbox and confirm that rehydration does not silently widen access. Inspect logs for the original request, tool calls, approvals, output files, and rejected actions.
OpenAI says these capabilities are generally available through the API, with Python first and TypeScript support planned. Availability is not an operational proof. The implementation is ready only when the recovery and denial paths are tested against the organization’s own data and permissions.
FAQ
Does native sandbox execution make an agent safe?
No. It provides a controlled execution layer. Safety still depends on manifests, least-privilege credentials, isolation, approvals, logging, and recovery tests.
Why separate the harness from compute?
The separation keeps orchestration authority and sensitive credentials away from model-generated code and makes it easier to replace or recover the compute environment.
What should be revalidated after rehydration?
Revalidate identity, manifest scope, credentials, network permissions, pending approvals, and output destinations before allowing the restored run to continue.
Conclusion Netics
Book a free 30-minute audit if your agent runtime needs a clearer execution and recovery boundary.
A sandbox is valuable when it is explicit, minimal, and observable. Durable state improves continuity, but it must not turn previous permissions into today’s authority.
Source: OpenAI, The next evolution of the Agents SDK — https://openai.com/index/the-next-evolution-of-the-agents-sdk/
Explore Netics for practical infrastructure and AI operations guidance.