Your Agent Needs a Sandbox, Not Just a Tool Loop

The important shift in agent infrastructure is not that models can call more tools. It is that the tool loop is moving into an explicit runtime boundary.

OpenAI now describes the Responses API as an agent loop connected to a hosted computer environment: shell execution, an isolated workspace, streaming output, bounded command results, reusable skills, and compaction for long sessions. Anthropic exposes Claude Code as an Agent SDK with built-in tools, permissions, hooks, subagents, MCP, and session management. GitHub is putting agentic browser tools, parallel sessions, cost visibility, managed settings, and MCP configuration directly into the developer environment.

That is the pattern to notice. The industry is converging on a simple idea: a production agent needs a sandbox. Not a vague "tool calling" abstraction. Not a pile of API wrappers. A sandbox with scoped files, network policy, credential boundaries, event logs, cost accounting, and reviewable permissions.

For senior engineering teams, this changes the architecture conversation. The question is no longer "which functions can the model call?" The question is "what computer is the model allowed to operate, how is that computer isolated, and how do we know what happened?"

Why this matters

Tool calling is only a request format. It says that a model wants to run search_issues, read_file, bash, open_browser, or create_pr. It does not answer the production questions:

• Where do intermediate files live?
• Which secrets can the task access?
• Can the agent reach the public internet, internal services, or only localhost?
• Is the browser allowed to click a destructive control?
• How are long outputs capped before they poison context?
• What happens when a task spans an hour and the context window fills?
• Can security review reconstruct the exact sequence of actions?
• Who pays for a runaway parallel session?

A sandboxed runtime makes those questions first-class. OpenAI's computer environment post is explicit about the practical problems: intermediate files, large tables, network access, timeouts, retries, and workflow execution. GitHub's Copilot cloud agent MCP documentation makes the governance side explicit: some MCP servers are configured by default, default GitHub access can use a specially scoped read-only token, and teams should review third-party MCP servers and restrict the tools field to necessary tooling. Anthropic's MCP connector adds another version of the same boundary: remote MCP servers, OAuth bearer tokens, allowlists, denylists, and per-tool configuration.

The lesson is not vendor-specific. The runtime boundary is becoming the unit of trust.

There are also important caveats. These surfaces are not interchangeable. OpenAI's hosted shell environment, Anthropic's Agent SDK, Anthropic's remote MCP connector, and GitHub's Copilot cloud agent each expose different execution models, authentication paths, and supported MCP primitives. A design that is safe in a local SDK process may not be safe in a managed cloud agent, and a tool that works through one MCP host may be unavailable or differently constrained in another. Production architecture has to document those differences instead of hiding them behind a generic tools list.

A reference architecture for production agent sandboxes

A useful production design separates six responsibilities:

flowchart LR
  U["User or Job"] --> O["Agent Orchestrator"]
  O --> P["Policy Engine"]
  P --> T["Tool Gateway"]
  T --> S["Sandbox Runtime"]
  S --> FS["Scoped Filesystem"]
  S --> N["Network Egress"]
  S --> B["Browser or GUI"]
  S --> C["Command Runner"]
  O --> L["Session Log"]
  T --> L
  S --> L
  L --> OBS["Traces, Cost, Audit"]
  P --> SEC["Secrets Broker"]

The orchestrator owns the loop. It sends user intent, task state, tool schemas, and prior observations to the model. It receives proposed actions and decides whether the runtime can execute them.

The policy engine is the guardrail that should not live inside the prompt alone. It maps task type, user, environment, repository, and approval mode to concrete permissions. A documentation task might read files and fetch public web pages. A release task might read secrets and write GitHub releases only after a human approval. A daily publishing job might create and publish WordPress posts but only after mandatory review checks.

The tool gateway normalizes tool calls. MCP servers, local functions, browser controls, shell commands, and SaaS APIs should all pass through a layer that can enforce allowlists, redact outputs, attach metadata, and emit audit events.

The sandbox runtime is the execution boundary. It should have a scoped filesystem, isolated processes, bounded network egress, and a predictable lifecycle. It may be a hosted container, a short-lived VM, a Kubernetes job, a locked-down desktop session, or a managed agent environment. The exact substrate matters less than the contract: every action happens inside a boundary that can be started, observed, limited, and destroyed.

The session log is the source of truth. It should capture model-visible messages, proposed tool calls, executed commands, outputs after truncation, file artifacts, exit codes, approvals, policy decisions, token usage, cost, and final state. Without this log, operators cannot debug failures, reconstruct incidents, or improve the system.

Observability turns that log into operational signal. GitHub's recent Copilot updates around total session cost and subagent usage visibility are a good clue: agent operations need the same accounting discipline as any other production workload.

Production tip: If an agent action can affect a customer, a repository, a credential, or a bill, it should produce a structured event. Screenshots, diffs, command excerpts, policy decisions, and approval records are not debugging extras. They are the operating record.

Runtime concern	Prototype shortcut	Production boundary
Files	Shared working directory	Scoped workspace with promoted artifacts
Network	Full outbound access	Per-task egress profile
Secrets	Environment variables	Leased credentials through a broker
Tools	Everything enabled	Positive allowlist by task type
Logs	Chat transcript only	Structured session log plus artifacts
Cost	Best effort monitoring	Budget, concurrency, and output caps

Implementation details that matter

1. Filesystem scope is part of the security model

Agents need files. They create scratch artifacts, read repositories, generate reports, run tests, and pass structured state between steps. Treat the filesystem as an API surface.

A practical layout looks like this:

/workspace
  /input          read-only task inputs
  /repo           checked-out code or mounted project
  /scratch        agent-owned temporary files
  /artifacts      deliverables promoted out of the sandbox
  /logs           structured execution events

Make /input immutable. Make /scratch disposable. Promote only reviewed outputs into /artifacts. If an agent modifies /repo, require a diff and a test result before changes leave the sandbox.

This keeps the model from relying on hidden global state and gives operators a clean place to inspect outputs.

2. Network egress should be explicit, not assumed

The network policy should match the task. A research agent might need public documentation and package registries. A code migration agent might need only the repository origin and CI. A browser validation agent might need localhost plus a staging URL. A finance or HR workflow might need no public internet at all.

Use profiles:

profiles:
  docs_research:
    egress:
      allow:
        - docs.python.org
        - openai.com
        - docs.anthropic.com
        - github.com
    secrets: []

  repo_fix:
    egress:
      allow:
        - github.com
        - registry.npmjs.org
    secrets:
      - github_read_token

  browser_validation:
    egress:
      allow:
        - localhost
        - staging.example.com
    browser:
      screenshots: true
      clicks: true
      downloads: false

The point is not the syntax. The point is that "agent can use the internet" is too broad for production.

3. Secrets should be leased, scoped, and logged by name

Do not drop a .env file with broad credentials into the workspace. Use a broker that leases task-scoped credentials and logs secret names, not values.

For example:

{
  "task": "publish_article",
  "secret_leases": [
    {
      "name": "wordpress_app_password",
      "scope": "wp-json/wp/v2/posts",
      "expires_in_seconds": 1800
    }
  ]
}

The agent does not need to know the raw secret. The tool gateway can sign the request or inject the credential at execution time. The session log records that a WordPress credential was used for a post update, without exposing the password to the model transcript.

4. Tool allowlists must be per task, not per platform

MCP makes tool integration portable, but it does not remove governance. GitHub's documentation notes that Copilot cloud agent and code review currently support MCP tools, not resources or prompts, and that remote OAuth-backed MCP servers are not currently supported on those surfaces. Anthropic's MCP connector supports remote HTTP MCP servers, OAuth bearer tokens, allowlists, denylists, and per-tool configuration, but also documents limitations and data retention caveats.

That means each runtime surface has different capabilities and risks. Do not assume "MCP enabled" means the same thing everywhere.

A production allowlist should be task-shaped:

task_type: dependency_update
allowed_tools:
  filesystem:
    - read_file
    - edit_file
  shell:
    - npm
    - pytest
    - git diff
  github:
    - create_pull_request
    - read_checks
blocked_tools:
  - delete_repository
  - rotate_secret
  - publish_package
requires_approval:
  - create_pull_request

Use positive permissions. Review third-party MCP server tools before exposing them. If a server contains write tools, enable only the small subset the task actually needs.

5. Output caps are a correctness feature

Long outputs are not just expensive. They are operationally dangerous. A huge terminal log can drown the relevant error, push out task context, and make the model reason over noise.

OpenAI's Responses API design includes bounded shell output that preserves the beginning and end while marking omitted content. That is the right default for agent runtimes. Store full logs in the sandbox, but return bounded excerpts to the model.

A good pattern:

• Return the first N lines and last N lines to the model.
• Store full output as an artifact.
• Attach a stable artifact path or log ID.
• Provide a separate read_log_slice tool for targeted inspection.

This keeps context useful without hiding evidence.

6. Compaction does not replace durable state

Large context windows and native compaction are valuable. They help long-running sessions continue coherently after the model context fills. But compaction is not an audit log, a database, or a source of truth.

Keep durable state outside the prompt:

• task brief
• execution plan
• file artifacts
• structured findings
• review decisions
• test results
• publish status
• cost and token usage

The model can summarize these into context. The runtime should still persist them as structured state.

7. Browser tools are production tools

GitHub's VS Code Copilot changelog calls out generally available agentic browser tools that can navigate pages, inspect content, capture screenshots, and validate web apps. That is useful, but it expands the blast radius. A browser can click buttons, submit forms, upload files, and interact with authenticated systems.

Treat browser actions like shell commands:

• isolate browser profiles
• disable password managers
• block downloads unless required
• require explicit permission for destructive clicks
• capture screenshots and DOM snapshots
• log URL transitions and submitted forms
• restrict origin access

If the browser can mutate production, it belongs behind the same approval and audit controls as any other write-capable tool.

Pitfalls and tradeoffs

Pitfall: one global agent runtime

A single all-powerful runtime is convenient during prototyping and dangerous in production. It tends to accumulate broad tokens, broad network access, too many tools, and implicit state. Split runtimes by task class. A documentation writer, code repair agent, browser tester, release assistant, and support triage agent should not share the same permissions.

Pitfall: trusting prompt instructions as policy

System prompts are useful for behavior. They are not enough for enforcement. A prompt can say "do not publish without review," but the publish API should still require the review state. A prompt can say "do not use external network," but the sandbox should still block egress.

Pitfall: unbounded autonomy without cost controls

Parallel sessions, subagents, browsers, long context windows, and background monitors can multiply cost quickly. Add budgets at the runtime level:

• maximum wall-clock time
• maximum tool calls
• maximum concurrent sessions
• maximum output bytes returned to context
• maximum spend per task
• escalation when budget is nearly exhausted

Cost visibility is not a billing nicety. It is an operational safety control.

Pitfall: treating MCP as a security boundary

MCP standardizes how models discover and call tools. It does not automatically make every tool safe. The boundary is still the host, policy engine, credentials, and runtime. Use MCP for interoperability, not as a substitute for review.

Rollout guidance

Start with a low-risk task where the sandbox boundary is easy to inspect: documentation maintenance, dependency inventory, test failure triage, or staging-only browser validation. Do not begin with production database writes.

For each task class, define:

1. Inputs: what files, tickets, URLs, or records the agent can see.
2. Tools: the exact read and write operations it can request.
3. Runtime: container, VM, hosted sandbox, or managed agent surface.
4. Network: allowed origins and blocked destinations.
5. Secrets: credential leases and scopes.
6. State: artifacts and logs that survive the task.
7. Review gate: what must be true before changes leave the sandbox.
8. Observability: traces, costs, screenshots, diffs, and final status.

Then run the same task repeatedly. Measure failure modes. Tighten permissions. Add missing log fields. Convert repeated manual interventions into policy or tooling. Only then expand the permission envelope.

A sandbox-first rollout is slower than connecting ten tools to a model and hoping for the best. It is also the difference between an impressive demo and an agent system that security, platform, and operations teams can live with.

Practical takeaway

The next generation of agent infrastructure will be judged less by how many tools it exposes and more by how safely it can run work. The platforms are already moving that way: hosted computer environments, SDK-level permissions, MCP toolsets, browser sandboxes, session cost visibility, and managed settings.

If you are building agents in production, make the sandbox the design center. Give the model useful tools, but put those tools inside an execution boundary that can be constrained, observed, replayed, and shut down.

That is where agent reliability starts.

References

1. OpenAI: From model to agent: Equipping the Responses API with a computer environment
2. Anthropic: Agent SDK overview
3. Anthropic: MCP connector
4. GitHub Docs: Model Context Protocol (MCP) and GitHub Copilot cloud agent
5. GitHub Changelog: GitHub Copilot in Visual Studio Code, June 2026 releases