Enterprise teams often talk about AI governance as if the hard part starts after a model produces an answer.
That framing is now outdated.
Current AI platform docs increasingly treat tools as normal infrastructure. Models can search the web, retrieve files, call remote MCP servers, run bash commands, and interact with desktop environments. Once that happens, the important question is no longer just What did the model say? It becomes Where was the model allowed to run, what systems could it touch, and what proof exists that the boundary stayed intact?
That is why enterprise AI needs a sandbox contract.
A sandbox contract is the written operating definition of where a tool-using model may execute, what it can read, what it can write, which networks it can reach, what credentials it can use, which domains it can touch, when a human must approve, and what evidence is kept afterward.
Without that contract, teams do not really have governed AI. They have a moving execution surface with unclear limits.
Why this matters now
The public platform direction is clear. Tool use is no longer a niche add-on.
OpenAI’s current tools guide says model responses and agents can be extended with built-in tools, function calling, Programmatic Tool Calling, tool search, and remote MCP servers. The same guide says these let the model search the web, retrieve from files, load deferred tool definitions at runtime, call custom functions, compose tool calls in JavaScript, and access third-party services.
That is a material shift in system shape. The model is no longer just producing language. It is becoming a policy-controlled caller across an execution surface.
Anthropic’s current Claude Code security guidance points in the same direction from the local execution side. It says Claude Code uses strict read-only permissions by default, requires approval before running Bash commands that can modify a system, and supports a sandboxed bash tool with filesystem and network isolation. The same page says Claude Code can only write to the folder where it was started and its subfolders unless broader permission is granted.
That is not cosmetic UX. It is an explicit boundary model.
Anthropic’s current computer use documentation makes the browser and desktop side just as concrete. It recommends using a dedicated virtual machine or container with minimal privileges, avoiding sensitive data, limiting internet access to an allowlist of domains, and asking a human to confirm decisions with meaningful real-world consequences or affirmative consent.
The MCP security guidance adds the connector layer. Its current security best-practices doc calls token passthrough an anti-pattern, warns about local MCP server compromise, recommends least-privilege scope design, and explicitly suggests process-level sandboxing plus containerized or restricted environments for proxy services.
Taken together, these are not isolated product notes. They describe a new enterprise reality: the trust boundary for AI now includes tool runtime, local execution, connector behavior, and browser interaction.
What a sandbox contract is
A sandbox contract is not just a container image and not just a one-line policy that says “run this safely.”
It is a route-level contract that binds execution privileges to the workflow being attempted.
If a model is only allowed to summarize approved files, its sandbox should reflect that. If it can call retrieval tools but not mutate production systems, its network, credentials, and write paths should reflect that. If it can interact with websites, the sandbox should define which domains are in scope, what consent-required actions are blocked, and when the run must stop for human review.
In other words, the sandbox contract turns vague trust language into explicit operating state.
The docs already describe the ingredients of a sandbox contract
1. Tool-enabled AI expands the execution surface
OpenAI’s tools guide now describes a model that can search, retrieve, load deferred tools, call functions, compose actions programmatically, and reach remote MCP servers or third-party services. That means “the model” is not the whole unit of risk anymore. The effective product is the model plus the allowed tool lane.
If two teams use the same model but different tool permissions, they are not deploying the same system.
2. Read-only by default is a product decision, not a convenience
Anthropic’s security guidance is useful because it makes a concrete distinction between read-only defaults and elevated actions. It also distinguishes boundary-limited writes from broader filesystem access.
That is the right mental model for enterprise AI more broadly. Tools should not start from “full local shell plus network plus credentials.” They should start from the smallest lane that matches the actual task.
3. Browser and desktop automation need separate controls
Computer use is not just another function call. The model is operating in a world of cookies, login screens, prompt-injection text, and misleading interfaces.
Anthropic’s guidance to use a dedicated VM or container, avoid sensitive data, allowlist domains, and require human confirmation for meaningful consequences is effectively a sandbox contract in outline form. It recognizes that once the model sees a live interface, the control problem expands beyond prompt quality into environment design.
4. Connectors and proxy layers need least-privilege design
The MCP security guidance matters because it shifts attention from the model to the servers and tokens around it.
Its warning on token passthrough is especially important. If a connector accepts upstream tokens blindly and forwards them downstream, the organization loses some of the control and audit leverage the proxy layer was supposed to provide. The same document also warns about local MCP server compromise and scope inflation.
That means a sandbox contract cannot stop at the model host. It must cover connector identity, scope minimization, and whether each attached tool runs in an isolated or restricted environment.
What breaks when no sandbox contract exists
1. Demo-safe tools become production-safe by accident
A team tests an agent in a broad developer environment, then carries the same permissions into a real workflow because nothing formal separates experimentation from release.
2. The same model behaves like different products with no record
One route is read-only with narrow file access. Another can edit code, browse the web, or call remote systems. If those are not documented as distinct lanes, audit and incident review become guesswork.
3. Prompt-injection risk lands on high-privilege surfaces
Untrusted page content, retrieved text, or connector output can shape behavior more dangerously when the model also has browser control, shell access, or broad tool scopes. The issue is not just model susceptibility. It is the privilege available if susceptibility occurs.
4. Credential sprawl becomes invisible
Without a route-level contract, tool invocations can quietly inherit credentials, cookies, API tokens, or local session state that were never meant to be part of the workflow.
5. Reviewers cannot prove what the model was actually allowed to do
If the organization cannot reconstruct the exact execution lane after the fact, then “human oversight” often means reviewing outcomes without seeing the operative boundary that produced them.
What a sandbox contract should include
1. Execution venue
State whether the route runs in a local workstation process, dedicated container, VM, managed browser harness, isolated runner, or another approved environment.
2. Filesystem scope
Define exact read and write boundaries. Name working directories, blocked paths, temp storage policy, and whether uploads or downloads are permitted.
3. Network egress policy
Record whether the route has no outbound network, private-only network, approved internal services, or public-internet access limited to an allowlist.
4. Credential and token scope
Specify which identities are available to the route, how they are issued, whether they are temporary, which scopes they carry, and whether any connector layer validates audience and purpose before passing requests onward.
5. Tool inventory and trust level
List each allowed tool, its environment, whether it is sandbox-only or production-approved, and what class of side effects it can create.
6. Browser and consent rules
If the route includes browser or desktop interaction, define allowed domains, blocked actions, cookie and login handling, screenshot retention, and which screens must trigger a stop-for-review event.
7. Human approval gates
Document which actions can run autonomously and which require explicit approval before execution, before escalation, or before final release.
8. Evidence and teardown
Keep a durable record of the active sandbox mode, tool inventory, scope set, approvals, outputs, and cleanup result. If the environment is supposed to be ephemeral, record proof that it was actually torn down.
Questions operators should ask before enabling tool use
- What exact environment will this route execute inside?
- What can it read, write, and persist locally?
- What networks, domains, or remote servers can it reach?
- What credentials or cookies are available during the run?
- Which actions are allowed automatically, and which require a human signoff?
- How does the route handle untrusted page content, prompt injection, or connector output?
- What evidence will we keep to prove the route stayed inside the approved boundary?
If those answers are fuzzy, the system may be impressive, but it is not ready for consequential work.
The commercial takeaway
Enterprise AI buyers are increasingly evaluating agents, desktop automation, browser tooling, remote MCP connectors, and code-capable assistants. The common mistake is to compare them as if the differentiator is model intelligence alone.
Current primary-source docs say otherwise. The real differentiator is often the execution contract around the model.
Tool-enabled AI can be useful, but it changes the trust boundary. OpenAI’s tool stack expands what the model can reach. Anthropic’s security and computer-use docs show why read-only defaults, isolation, minimal privileges, domain allowlists, and explicit approval gates matter. MCP’s security guidance shows why proxy and connector design can quietly widen or narrow the blast radius.
The teams that deploy well will stop asking, “Can this model use tools?” and start asking, “What exact sandbox contract does this route satisfy?”
That question is what separates a persuasive demo from a workflow that can survive architecture review, security review, and operational reality.
Related reads
- Remote MCP Is Not a Trust Boundary: Why Enterprise AI Needs Tool Trust Tiers
- AI Agents Need Credential Leases: Why Temporary Access Beats Stored Secrets
- Prompt Injection Is Now an Operations Problem: Why Enterprise AI Needs a Quarantine Layer
- AI Workflow Services