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 for each workload. What AI agent sandboxing is compares them in depth; the summary:

Substrate	Isolation boundary	Fit for agent-generated code
Container with namespaces and cgroups	Shared host kernel	No: a kernel exploit reaches the host
Container with a tight seccomp profile	Reduced syscall surface on a shared kernel	No for untrusted code, yes for code you reviewed
gVisor	User-space kernel intercepting syscalls	Minimum acceptable floor
Kata Containers	Lightweight VM with its own guest kernel	Yes, suited to longer-lived workloads
Firecracker microVM	Guest kernel with a minimal device model	Yes, suited to short-lived, high-churn tasks
Unikernel runtime such as urunc	Single-purpose guest with almost no in-guest surface	Yes, container-class startup with VM-class isolation

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.

Implement runtime policy enforcement

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.

5. 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.

6. 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.

7. 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.

Test workflows in controlled environments

Test an agent's decision-making by running it against recorded production states and scripted sandbox sessions before it gets live write access. 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.

8. 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.

9. Script sandbox sessions for known failure modes. Agent SDKs increasingly support running tool execution inside a sandbox, which makes repeatable test sessions straightforward: a poisoned dependency, a prompt injection in a log line, an instruction to exceed a grant. Each should end in containment or refusal.

10. 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.

11. 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.