The agent runtime is quietly acquiring responsibilities that look increasingly like those of an operating system.
Recent changes in OpenAI's Agents SDK make this visible. The runtime now includes model-call timeouts, run-scoped sandbox working directories, the ability to disable networking in Docker sandboxes, configurable sandbox resources, exact enforcement of call-approval decisions, improved cleanup after provider failures, and more accurate accounting around context compaction.
Individually, these may look like ordinary SDK improvements. Taken together, they describe what happens when agents stop being demos and begin operating inside real systems.
A long-running agent needs protection from several classes of failure: unbounded execution when a model or tool hangs; state contamination when one execution leaks filesystem state into another; ambient authority when generated code can reach resources it was never supposed to access; and ambiguous authorization when an approval decision is interpreted differently by the runtime than by the human or policy layer.
Timeouts, isolated working directories, network controls and exact approval semantics directly address those problems.
This suggests a useful distinction.
The agent harness manages the cognitive loop:
context → reasoning → model selection → tools → state → verification
But the agent also needs an execution envelope:
filesystem → network → credentials → resources → time → approvals → process isolation
The first helps the agent accomplish the task. The second constrains how far a mistake can propagate.
The cognitive loop can remain probabilistic. The execution boundary should be as deterministic as possible.
Once we think in terms of an execution envelope, access to external capabilities becomes part of the same problem. A boundary is meaningful only if it governs not just what an agent starts with, but also what it can acquire while operating.
This becomes particularly important for software supply-chain security.
Coding agents increasingly do more than generate code. They can select dependencies, install packages, connect to MCP servers, add agent skills and execute third-party code using developer credentials—sometimes without a human inspecting each decision beforehand.
Existing software supply-chain security was largely designed around a different assumption: humans make the trust decision first, and security tooling evaluates the artifact afterward.
The emerging flow is different:
agent identifies a need → discovers a dependency, tool, skill or package → installs or invokes it → continues execution
The dependency decision itself has become part of the agent trajectory.
Software composition analysis remains necessary, but it is no longer sufficient. Security increasingly needs to participate at the moment a new capability enters the agent's execution environment.
Consider something as simple as disabling sandbox networking. That sounds like a low-level runtime option until the agent itself is capable of discovering, downloading and executing code. At that point, network access is no longer an environmental default. It is a capability.
And capabilities should be governed.
This points toward an emerging form of admission control for agent-acquired capabilities:
agent requests capability X → identify artifact and provenance → evaluate trust, risk and policy → permit or reject → constrain execution
Early agent frameworks were built primarily around one question: What can the agent do?
Production agent runtimes increasingly need to answer the opposite question as well:
Where does that capability stop?
Not simply: “Here are your tools.”
But: “You may execute generated code inside this directory, with these resources, for this amount of time, without network access, and this class of action requires explicit approval.”
That is much closer to an execution contract.
The distinction matters:
The execution envelope is the technical boundary within which the agent operates.
The execution contract specifies the rules that define that boundary for a particular agent or task.
For consequential agents, both should become part of the system specification rather than being treated as low-level implementation details.
Reliable agentic systems are not only about increasing the probability of a correct decision. They are also about engineering the consequences of an incorrect one.
The harness organizes intelligence. The execution envelope contains its consequences. The execution contract makes those boundaries explicit.
For teams building production agents, that suggests a practical design question that deserves to sit alongside model selection, context engineering and evals:
Before asking what the agent should be capable of doing, define the environment in which that capability can safely exist.