How to Securely Sandbox AI Agents with Production Write Access

Before you start

Sandboxing an AI agent with write access means containing what its code can reach, deciding which of its actions may run, and limiting the credentials it holds, all at once. Isolation alone is not enough, because the dangerous action for an agent with infrastructure write access is often a legitimate API call made for the wrong reason.

Start from the premise in the sandboxing manifesto: the agent is untrusted by default, whichever model runs it. Then inventory what each agent can write to today, and pick a substrate or a sandbox product for each workload. What AI agent sandboxing is compares the substrates in depth. The summary below lists the substrates first, then four sandbox products:

Substrate or product	Isolation boundary	Fit for agent-generated code	Self-hosted or managed	Open source
Container with namespaces and cgroups	Shared host kernel	No: a kernel exploit reaches the host	Self-hosted	Yes
Container with a tight seccomp profile	Reduced syscall surface on a shared kernel	No for untrusted code, yes for code you reviewed	Self-hosted	Yes
gVisor	User-space kernel intercepting syscalls	Minimum acceptable floor	Self-hosted	Yes
Kata Containers	Lightweight VM with its own guest kernel	Yes, suited to longer-lived workloads	Self-hosted	Yes
Firecracker microVM	Guest kernel with a minimal device model	Yes, suited to short-lived, high-churn tasks	Self-hosted	Yes
Unikernel runtime such as urunc	Single-purpose guest with almost no in-guest surface	Yes, container-class startup with VM-class isolation	Self-hosted	Yes
brig (ours)	A microVM with its own Linux kernel per agent session	Yes, for coding agents on a developer's Mac or Linux machine	Self-hosted, on your own machine	Yes, Apache 2.0
E2B	Firecracker microVM	Yes, for agent code in a managed cloud or on your own hosts	Managed cloud, with a self-hosted option	Yes
Modal Sandboxes	gVisor	Meets the gVisor floor, as part of a serverless compute platform	Managed	No
Daytona	Linux container by default, with dedicated VM sandboxes as an option	The VM class, yes. The default container class shares the host kernel	Managed cloud, or self-hosted	Yes, AGPL 3.0

NOFire AI, a production ops platform for engineers and AI agents, builds brig. Why we wrote our own microVMM covers that runtime choice, and why AI agents need a control system covers the gate the sandbox runs behind. The arm64 escape we found and reported shows what the isolation layer defends against. The E2B, Modal and Daytona rows follow each vendor's public description of its product. Confirm the current runtime and hosting terms with each vendor before you choose.

Read the current OWASP AI Agent Security Cheat Sheet and OWASP MCP Security Cheat Sheet before writing policy, and Anthropic's Claude Code security documentation if your developers use it, since its permission modes and sandboxed command execution are the first layer you already have.

The steps

Establish governance and operational boundaries

Operational boundaries define what an agent must never do, what it may do with approval, and what it may do alone, before any sandbox or policy is configured. Writing them first matters because every technical control below enforces one of these lines. Boundaries that exist only in a prompt are suggestions.

1. List prohibited actions. Examples: dropping or truncating production tables, deleting persistent volumes, modifying IAM, disabling logging, and reaching production from a development sandbox. Prohibited means refused by the system, not discouraged in instructions.

2. Set data-handling rules. Decide which data the agent may read, which it may send to a model provider, and which must never leave the sandbox. Secrets should be injected per task and never written to the agent's context.

3. Assign oversight tiers. Following the OWASP approach of scaling human oversight with impact, place each action class in a tier: runs alone, runs with a recorded policy verdict, or waits for a named human approver.

4. Map tiers to access controls. Each tier becomes a concrete grant: which tools, which namespaces, which environments, and for how long.

5. Apply least privilege to every credential. Least privilege means an identity holds only the access its current task needs. Give each agent its own identity, separate from any engineer's account. Issue a short-lived credential scoped to one task and its tier, and revoke it when the task ends. Keep read and write credentials separate, so an investigation that only reads cannot write.

Enforce runtime policy on Claude Code, Cursor and ops agents

Runtime policy enforcement checks each agent action against the operational boundaries at the moment of execution and refuses anything outside them before it runs. For Claude Code, Cursor or an ops agent, this means controls at function level, on the specific tool call and its arguments, not a blanket allow on a whole API.

6. Grant capabilities at function level. Permit scale deployment in one namespace rather than write access to the cluster. Narrow grants turn a prompt injection into a refused call instead of an incident.

7. Cover every protocol the agent uses. Shell commands, cloud APIs, Kubernetes and MCP tool calls all need the gate. An agent blocked from kubectl delete but allowed an MCP tool that does the same thing is not sandboxed.

8. Attach predicted blast radius to writes. Each write carries its computed reach, and the gate refuses anything above the tier's ceiling. AI agent governance covers the verdicts and the signed record that result. NOFire AI evaluates each agent action against policy and a live production map before execution.

Choose the sandbox and estimate what it costs

The cost of sandboxing an agent with write access comes from three drivers: substrate overhead, cold starts and idle time. Prices differ by vendor and change often, so compare options on these three drivers with your own workload. Self-hosting moves the cost from a vendor bill to your own nodes and to the engineers who run the runtime.

9. Choose the sandbox by workload shape. Short-lived agent tasks are dominated by startup cost, where microVM and unikernel runtimes win. Long-lived syscall-heavy processes suit VM-backed sandboxes. For coding agents on a developer's machine, brig, NOFire AI's open-source project, runs each agent session in its own microVM on macOS and Linux under Apache 2.0.

10. Count the overhead per sandbox. Each step away from the host kernel costs memory, startup time or syscall speed. gVisor slows syscall-heavy work, and Kata Containers keeps a guest kernel in memory for each pod. AI agent sandboxing lists the reported figures per substrate. Multiply the overhead by the number of sandboxes you run at peak.

11. Trade cold starts against warm capacity. A short-lived task pays the sandbox startup time on every run. A warm pool keeps sandboxes booted before they are needed, which cuts that delay. The pool holds memory and CPU while it waits, so size it to the rate at which tasks arrive. urunc with the Kubernetes agent-sandbox CRD measures cold-start and warm-pool latency side by side.

12. Cap idle time. A sandbox that outlives its task still holds capacity and its credential. Tear the sandbox down when the task ends, and set a maximum lifetime for sessions that stop responding. On a managed service, check whether the price counts idle session time as well as active compute.

Test agent decision-making workflows before live deployment

Test an agent's decision-making workflows against recorded production states and scripted sandbox sessions before you deploy it to live infrastructure. A time-versioned model of production lets you replay real incidents and changes, so the test reflects the estate the agent will act on rather than a synthetic toy.

13. Write down the expected behavior first. List what the agent must never do in a test run. Examples: call a destructive API without approval, act outside its grant, or reveal its system prompt. Each session then passes or fails against that list.

14. Replay against time-versioned production states. Give the agent past incidents and the production state as it stood then, capture every action it proposes, and execute none of them. Compare its proposals with what engineers actually did.

15. Script sandbox sessions for known failure modes. Agent SDKs increasingly run tool execution inside a sandbox, which makes repeatable test sessions straightforward. Script three of them: a poisoned dependency, a prompt injection in a log line, and an instruction to exceed a grant. Each one must end in containment or refusal.

16. Graduate write access in stages. Read-only context first, then proposals a person executes, then reversible writes behind the gate, then wider grants as the refusal history supports them. Irreversible actions stay behind a human.

Verify it worked

From inside the sandbox, attempt to read a host file and reach a network destination outside the grant. Both should fail at the boundary.

Ask the agent to perform a prohibited action through each protocol it can use: shell, cloud API, Kubernetes and MCP. Every attempt should produce a signed refusal.

Let a task's grant expire mid-session and confirm the agent can no longer act with it.

Where it breaks

Supply chain. A sandbox does not verify that the dependency, model or tool definition that loaded is the expected one. That is signature verification, upstream.

Legitimate calls with bad intent. Isolation cannot stop a permitted deploy API call from shipping a bad change. Only the policy gate and blast-radius ceiling address that.

Credentials inside the sandbox. A long-lived token placed in the sandbox survives the session's isolation. Inject per task and expire.

Test states that drift from production. Replays against a stale model pass agents that would fail today. The sandboxing whitepaper covers the isolation scorecard. Keep the replay data as current as the production model.