Production Agent Runtimes: Sandboxes, State, and Approval Gates

Giving a model tools changes the engineering problem. A chat response can be wrong; a tool-using agent can be wrong and edit a repository, send a message, rotate a credential, operate a browser, or deploy a broken build.

Production agent systems therefore need more than a good prompt. They need an enforceable runtime around the model: an agent harness, an isolated execution environment, durable state, narrow credentials, approval gates, and independent verification.

The ecosystem is moving in that direction. OpenAI's April 2026 Agents SDK announcement describes a model-native harness, native sandbox execution, state externalization, snapshotting, and rehydration. Its current Sandbox Agents documentation separates the agent definition, workspace manifest, live sandbox session, and saved state. GitHub made agent skills and MCP context generally available for Copilot code review in July 2026, with MCP calls in that review surface limited to read-only. Google's Gemini Computer Use documentation tells developers to execute suggested actions in a secure sandbox and handle approval-required or blocked safety decisions in the client loop.

The products differ, but the architecture lesson is consistent: keep policy and control outside the model, and keep model-directed execution inside a bounded environment.

The Five Layers of a Production Agent Runtime

A useful design starts by separating five responsibilities.

These layers can live in one application, but they should remain conceptually separate. The separation makes threat modeling easier and lets you replace a model, sandbox provider, or workflow engine without rewriting the policy model.

1. Turn the Request Into a Task Contract

Before the first model call, normalize the request into a small contract. At minimum, record:

• the exact outcome
• allowed files, repositories, accounts, and external systems
• actions that are forbidden
• required checks
• the maximum time, cost, turns, or tool calls
• approval conditions
• the artifact expected at completion
• the stopping conditions for success, failure, and uncertainty

A provider-neutral contract might look like this:

task_id: fix-482
goal: Fix the null-session crash described in issue 482
workspace:
  repository: example/web-app
  ref: feature/fix-482
allowed_paths:
  - src/auth/**
  - tests/auth/**
network:
  allow:
    - api.github.com
forbidden:
  - production deployment
  - secret rotation
approvals:
  - git_push
  - external_comment
verification:
  - npm run lint
  - npm test -- auth
deliverable: reviewed_patch

This is not a system prompt. It is data the host validates and enforces. If the prompt says to deploy but the contract forbids deployment, the tool layer should make deployment impossible.

2. Build the Smallest Useful Workspace

An agent should not inherit the host machine by default. Create one isolated workspace per task and materialize only what the task needs.

For a coding agent, that usually means:

1. Clone or copy the required repository at a pinned ref.
2. Add the task spec and repo instructions.
3. Install dependencies from the project's lockfile.
4. Mount only required caches or data.
5. Run as a non-privileged identity.
6. Apply CPU, memory, process, disk, and time limits.
7. Deny network access by default, then allowlist required destinations.
8. Destroy the live environment after artifacts and state are persisted.

Containers are a useful boundary, but a container alone is not a complete policy. Review the runtime configuration: mounted host paths, container privileges, socket access, kernel capabilities, network routes, and injected environment variables determine the real blast radius.

Computer-use agents deserve the same discipline. Google's current guidance recommends a sandboxed VM or container and warns that the preview capability can produce errors or security vulnerabilities. Use dedicated test accounts, separate browser profiles, limited domains, and reversible workflows. Do not point an experimental browser agent at an authenticated personal profile and hope the prompt keeps it safe.

3. Classify Tools Before the Model Sees Them

Create a registry that records what each tool can actually do. Useful dimensions include:

• Read-only or mutating — can it change state?
• Reversible or destructive — can the effect be undone?
• Idempotent or retry-sensitive — can the same request safely run twice?
• Closed-world or open-world — does it operate on a bounded local resource or arbitrary external systems?
• Credential scope — which identity and permissions does it use?
• Approval rule — when must execution pause?
• Evidence output — what receipt, diff, ID, or log proves what happened?

MCP includes tool annotations for behavior such as read-only, destructive, idempotent, and open-world operations. Treat those annotations as risk vocabulary, not proof. The MCP tools specification explicitly says clients must consider annotations untrusted unless they come from trusted servers.

The host should enforce the registry's policy at dispatch time. A model-generated tool call is a proposal. The dispatcher still validates the tool name, arguments, task scope, current approval state, and rate limits before execution.

4. Keep Credentials Out of Model-Directed Compute

Do not copy a broad environment file into the sandbox. Do not place long-lived tokens in prompts, workspace files, command history, or tool results. Instead:

• issue short-lived credentials for one task and one service
• request the minimum scopes required for the current action
• inject credentials only into the tool process that needs them
• redact secrets from logs, traces, errors, and artifacts
• revoke or expire credentials when the task ends
• use separate tokens for separate downstream services

For remote MCP servers, follow the protocol's authorization model rather than forwarding whatever bearer token the client already has. The MCP authorization specification requires resource indicators and audience validation when authorization is used, and explicitly prohibits token passthrough. That prevents a confused-deputy path where one service accepts a token intended for another.

The 2026-07-28 MCP specification release candidate also emphasizes a stateless core and authorization hardening. Stateless transport does not mean stateless workflows: application state, approvals, and long-running task records still need a durable home.

5. Persist State Outside Disposable Compute

Long-running agents pause, fail, and retry. Treat that as normal.

Persist these records outside the sandbox:

• task contract and version
• model and harness configuration
• completed steps and pending steps
• tool calls with idempotency keys
• approvals and who granted them
• external side-effect receipts
• workspace snapshot or artifact references
• validation results
• terminal status and failure reason

Separate three kinds of state:

1. Conversation state — messages and model-visible context.
2. Workflow state — step, approvals, retry count, and side effects.
3. Workspace state — files and artifacts produced by execution.

They have different retention, privacy, and recovery needs. A conversation transcript cannot reliably replace a workflow state machine, and a filesystem snapshot cannot tell you whether an email was already sent.

Every mutating external call should carry an idempotency key or be guarded by a durable side-effect record. On resume, check that record before repeating the call. This matters most at the exact moment a process can fail: after an external service accepts the action but before the agent records success.

6. Put Approval Gates Before Consequential Actions

Human-in-the-loop control works only when the pause happens before the impact. A useful approval request includes:

• the exact action
• the target account, repository, environment, or recipient
• the proposed payload or diff
• why the action is needed
• whether it is reversible
• the evidence already collected
• what will happen after approval

Good approval candidates include:

• external messages and comments
• pushes, merges, and releases
• production changes
• permission or credential changes
• purchases and financial operations
• access to sensitive data
• deletion or destructive mutation
• any action whose target was inferred rather than explicitly supplied

Avoid approval fatigue. Reading a local source file usually should not require a click. Sending its contents to an external service might. Design gates around boundary crossings and impact, not around every model turn.

7. Verify With an Independent Gate

The agent that made a change can run checks, but its success statement is not evidence. The host should collect machine-readable results and decide whether the artifact can advance.

For a code change, a publication gate can require:

• intended files only in the diff
• unique IDs, slugs, or migration names
• lint, type checks, tests, and build passing
• dependency and secret scans where relevant
• a human-readable change summary
• commit identity and remote verification
• review before merge or deployment

GitHub's documentation for Copilot code review makes the same practical point: agent skills and MCP can improve repository-aware review, but Copilot is not guaranteed to find every problem and its feedback still needs validation and human review.

Keep publication separate from execution. A sandbox may produce a patch; a trusted control-plane process applies policy, verifies the patch, and decides whether it may be pushed. This limits the damage from a compromised dependency, prompt injection, tool server, or model error inside the workspace.

Failure Modes to Test Deliberately

Do not wait for production to discover these paths:

• The sandbox dies after changing files but before saving state.
• The process dies after an external write but before recording its receipt.
• A retrieved document contains instructions to expose secrets.
• A tool claims to be read-only but mutates data.
• A task resumes against a newer repository revision.
• Approval is granted, then the payload changes before execution.
• A token intended for one service is presented to another.
• The agent reaches its time or tool-call budget halfway through a plan.
• Validation passes in the sandbox but fails in the trusted build environment.
• Two workers resume the same task concurrently.

Each test should have a defined safe outcome: reject, pause, retry once, resume from a known checkpoint, or escalate to a person. “Ask the model to be careful” is not a recovery strategy.

Production Readiness Checklist

Before enabling writes, confirm:

• Every task has a validated contract and stable ID.
• Each run uses a dedicated, least-privileged workspace.
• Network access is denied by default or explicitly constrained.
• Secrets are short-lived, narrowly scoped, and absent from model-visible state.
• Tool risk is classified and enforced by the host.
• Tool annotations are treated as untrusted hints.
• Mutating calls are idempotent or protected against replay.
• Workflow state and side-effect receipts survive process loss.
• Approval binds to an exact action and payload.
• Validation runs independently of the agent's narrative.
• Only trusted publication code can push, deploy, send, or merge.
• Traces and artifacts are useful without leaking sensitive data.
• Operators can stop a run and revoke its credentials.

The Durable Principle

The safest agent architecture is not the one with the longest system prompt. It is the one where the model can be mistaken without automatically becoming dangerous.

Give the model enough context to propose good work. Give the sandbox only the resources needed to perform that work. Keep credentials, approvals, durable state, and publication authority in a trusted control plane. Then verify the resulting artifact as if it came from any fast, capable contributor: with evidence, review, and a clear release boundary.