Sandboxing AI Agents: MicroVMs, Allowlists and Least Privilege

What you need to know

By mid-2026, many teams deploying agents have absorbed the first lesson of agent security: untrusted text can steer a model, so you filter inputs, spotlight untrusted content and validate outputs. That is prompt-injection defence, and if you have not built that layer yet, start with our guides to defence-in-depth against prompt injection and the guardrails playbook. This article is about the second lesson, which fewer teams have internalised: injection defence guards what goes into the agent, while sandboxing guards what the agent can do when it is wrong, confused or actively manipulated anyway. No input filter is perfect, and an agent that can execute code, run shell commands or call tools will eventually do something you did not intend — the only question is how much that mistake is allowed to touch.

• Sandboxing and injection defence are complementary layers, not alternatives. One reduces the probability of a bad action; the other caps its blast radius.
• Isolation is a ladder, not a switch: plain process, hardened container, gVisor, microVM, remote sandbox service — each rung trades ops effort for a stronger boundary.
• Three controls are non-negotiable according to NVIDIA's AI Red Team: network egress allowlists, workspace-only write access, and protection of the agent's own configuration files.
• Least privilege needs a twin — least agency: limit not just what an agent can access, but what it is allowed to decide without a human.
• Logs must live outside the sandbox. An agent that can edit its own audit trail has no audit trail.

The threat model: what a compromised agent can actually do

Why did this become urgent enough for OWASP to give it a top-10 list of its own? In December 2025 the OWASP GenAI Security Project published the OWASP Top 10 for Agentic Applications 2026, a peer-reviewed catalogue of the risks specific to agents rather than plain LLM apps. Three entries sit squarely on the execution side: Tool Misuse & Exploitation (ASI02), Agent Identity & Privilege Abuse (ASI03) and Unexpected Code Execution (ASI05). The companion OWASP AI Agent Security cheat sheet is blunter still: its list of don'ts explicitly includes allowing agents to execute arbitrary code without sandboxing.

What does that look like in practice for a team running a coding agent or a tool-calling assistant with host access? Four failure classes cover most of it. First, credential exfiltration: an agent with shell access can read ~/.aws/credentials, .env files, SSH keys and browser tokens, and an agent with open network access can send them anywhere. Second, unintended file writes and deletes: a misread instruction or a poisoned document can turn "clean up the build directory" into recursive deletion outside the project, or quiet corruption of files the agent was never meant to touch. Third, runaway network calls: exfiltration is the dramatic version, but the mundane one — an agent looping on a paid API — is what OWASP's cheat sheet calls denial of wallet, and it shows up as a five-figure bill rather than a breach notification. Fourth, and least appreciated, configuration tampering: agent ecosystems now execute configuration — hooks, MCP server definitions, IDE extensions, instruction files like CLAUDE.md or .cursorrules — so an agent that can write to its own config can grant itself new capabilities on the next run. That is a persistence mechanism, in classic security terms.

Notice that none of this requires an attacker. The same controls that contain a manipulated agent also contain an ordinary, unmanipulated one having a bad day — hallucinating a path, misparsing an instruction, retrying itself into a loop. For a Bengaluru fintech or a London insurer, the difference between those two cases matters far less than the blast radius they share: if the agent's environment held customer records, an exfiltration or an errant bulk write is a reportable incident under India's DPDP Act or UK GDPR either way.

The isolation ladder: from bare process to microVM

Execution isolation is not one decision but a ladder, and each rung buys a stronger boundary at the cost of latency or operational effort. At the bottom sits the plain host process — the agent runs as your user, sees your filesystem, your credentials and your network. This is fine for a developer supervising every action locally; it is indefensible for anything autonomous. One rung up, a standard container (Docker or Podman) gives namespace and filesystem separation with near-instant startup, but every container shares the host kernel, so one kernel vulnerability is a shared escape route. gVisor, Google's user-space kernel, narrows that risk by intercepting system calls before they reach the host kernel, shrinking the attack surface dramatically while keeping container-like startup — it is the isolation layer behind Modal's sandboxes. The gold standard for untrusted code is the microVM: Firecracker, the AWS-built VMM that powers Lambda, boots a hardware-isolated VM with its own guest kernel in as little as about 125 milliseconds with under 5 MiB of memory overhead; Kata Containers wraps the same class of isolation in standard Kubernetes workflows; and Docker's Docker Sandboxes, launched as an experimental feature in March 2026, brought microVM isolation for coding agents such as Claude Code and Codex to developer laptops, using a proprietary VMM so it also runs on macOS and Windows. Northflank's comparison of Kata, Firecracker and gVisor is a good deeper read on the trade-offs between these runtimes.

The top rung is not stronger isolation but outsourced isolation: remote sandbox services run the agent's code on someone else's hardened infrastructure. E2B offers ephemeral Firecracker-backed sandboxes aimed squarely at agent code execution; Modal Sandboxes provide gVisor-isolated execution with serverless scaling and GPU access; Daytona positions persistent sandboxes for long-running agents in regulated enterprises. For a small team, these remove the ops burden entirely — but note where the compute lives. An Indian firm processing personal data under the DPDP Act, or a UK firm under UK GDPR, needs to check region and data-residency options before piping customer data into any third-party sandbox.

Network egress: default-deny, then allowlist

If you adopt only one control from this article, make it this one. In January 2026, NVIDIA's AI Red Team published practical guidance for sandboxing agentic workflows that names three controls as mandatory for any agent that executes code: network egress restrictions, write restrictions outside the workspace, and protection of configuration files. The reasoning behind the first is simple — blocking network access to arbitrary destinations cuts off the main route for data exfiltration and stops an agent (or whoever is steering it) from establishing a remote shell. Almost every serious outcome in the threat model above needs the network on the way out. Cut arbitrary egress and a credential read inside the sandbox usually becomes a contained incident rather than a breach.

The implementation pattern is default-deny plus an explicit allowlist, enforced outside the agent's reach: an egress proxy, firewall rules or your platform's network policy — never a rule the agent process itself could rewrite. NVIDIA's guidance recommends HTTP-proxy, IP or port-based allowlists together with DNS restricted to trusted resolvers, because an open resolver is itself an exfiltration channel via DNS tunnelling. Declare the model APIs, package registries and internal services the agent legitimately needs, and deny — and log — everything else. A minimal Squid-style egress proxy for an agent subnet looks like this:

# squid-egress.conf -- default-deny egress for the agent subnet
acl agents src 10.42.7.0/24

# Only these destinations are reachable from agent sandboxes
acl allowed_apis dstdomain .anthropic.com
acl allowed_apis dstdomain .openai.com
acl allowed_apis dstdomain .pypi.org .pythonhosted.org
acl allowed_apis dstdomain .npmjs.org
acl allowed_apis dstdomain internal-tools.example.co.uk

http_access allow agents allowed_apis
http_access deny all    # everything else is blocked -- and logged

The same idea now ships in the tooling itself: Docker's Sandbox Kits let you declare allowed network domains in a YAML spec applied when the sandbox is created, so the allowlist travels with the sandbox definition rather than living in tribal knowledge. Wherever you enforce it, treat the deny log as a first-class security signal — a burst of blocked requests to unfamiliar domains is the clearest early indicator you will ever get that an agent is being steered. Here is how the three mandatory controls fit together:

Least privilege meets least agency

Isolation bounds the environment; privilege bounds what the agent can reach from inside it. The OWASP cheat sheet's framing is the right starting point: grant agents the minimum tools required for their specific task, scope each tool's permissions (read-only versus write, and to which specific resources), and keep separate tool sets for different trust levels — an internal analytics agent and a user-facing support agent should not share a toolbox. The same discipline applies to credentials. Give each agent its own identity, with short-lived tokens minted per task and scoped to that task's resources: the agent summarising a sales report needs read access to one bucket for twenty minutes, not your organisation's cloud admin key for ever. A sandbox with production credentials sitting in its environment variables is just a well-decorated room for the attacker — the isolation is intact and the damage happens anyway, through the front door of a legitimately authenticated API.

But access is only half the question. The half that is new with agents is agency: not "what may this agent access?" but "what may this agent decide on its own?" A credential can technically permit deleting a production database and yet your policy can still require a human to approve it. OWASP's guidance formalises this as risk-tiered human-in-the-loop approval: classify actions by consequence, auto-approve the low-risk tier, and require explicit human sign-off — with the actor, tool, target resource, normalised parameters and expiry recorded — for anything irreversible. Deletes, payments, production deployments, and messages sent to customers or external systems all belong in that tier, whatever the token allows. Tool design carries a lot of this weight: narrow, well-typed tools with validated parameters are far easier to permission than a generic shell, an argument we make at length in our guide to designing tools for AI agents.

A practical checklist for the privilege layer:

• One identity per agent — never a shared service account across agents
• Short-lived, task-scoped tokens minted at task start, expired at task end
• No long-lived personal access tokens or production cloud keys inside any sandbox
• Per-tool permission scoping: read-only by default, write access named resource by resource
• Irreversible actions gated behind recorded human approval, regardless of credential scope
• Separate tool sets per trust level — internal agents and user-facing agents never share tools

Filesystem and configuration: the writes that matter most

NVIDIA's second and third mandatory controls both concern writes, and the distinction between them is worth keeping sharp. Workspace write restriction is the broad rule: the agent gets read-write access to its task directory and nothing else, because blocking writes outside the workspace shuts down a whole family of persistence mechanisms, sandbox escapes and remote-code-execution techniques — shell profiles, autostart directories, cron entries, dotfiles that execute on the next login. In container terms that means a read-only root filesystem, one writable workspace mount, and a small tmpfs for scratch space.

Configuration file protection is the narrow rule with the sharpest edge: the agent's own configuration must be unwritable by the agent, even inside the workspace, and even if a user clicks approve. NVIDIA's guidance is unusually absolute here, and for good reason — files like CLAUDE.md, .cursorrules, copilot-instructions.md, hook definitions, MCP server configurations and IDE extension settings are executed or obeyed on the next run, often outside any sandbox context. An agent that can edit them can grant itself new tools, new instructions or new network access tomorrow, quietly. The only acceptable modification mechanism is a direct, manual edit by a human. A hardened Compose definition pulls the whole filesystem story together:

# docker-compose.yml -- hardened runner for an agent workspace
services:
  agent-runner:
    image: agent-runner:2026-07
    read_only: true                   # immutable root filesystem
    cap_drop: [ALL]
    security_opt:
      - no-new-privileges:true
    tmpfs:
      - /tmp:size=256m                # scratch space, wiped per run
    volumes:
      - ./workspace:/workspace:rw     # the ONLY writable mount
      - ./agent-config:/etc/agent:ro  # hooks + MCP config: read-only
    networks:
      - egress-proxy-only             # no direct route to the internet

Two refinements earn their keep in production. Make workspaces ephemeral — provision a fresh one per task from a known-good template and discard it afterwards, so nothing the agent wrote persists into the next task's context. And keep secrets out of the mounted paths entirely: configuration the agent must read should never share a directory with credentials it must not.

Monitoring and audit: logs the agent cannot touch

Prevention fails silently unless something is watching, and with agents the watcher has one extra requirement: the audit trail must live where the agent cannot reach it. Ship every code execution, tool call, outbound request and approval decision to an append-only store outside the sandbox boundary — an agent that can edit its own history has no history. OWASP's cheat sheet spells out what a useful record contains: structured decision metadata for high-risk actions including the action classification, authorisation outcome, approval identifier, execution result and the policy version in force. That last field matters more than it looks — when you tighten a policy after an incident, you want to know which historical actions ran under the old one.

On top of the record, alert on the behavioural signals that precede or accompany misuse: denied egress attempts (your proxy's deny log, per the section above), abnormal tool-invocation frequency, repeated attempts to bypass or re-request approvals, elevated privilege usage, spikes in paid API spend, and unusual resource consumption — a sandboxed agent suddenly saturating CPU is occasionally a bug and occasionally somebody's cryptominer. Keep the traces of failed and blocked attempts, not just successful actions; the blocked attempts are the early-warning layer, and reviewing them weekly is how you catch a slow-moving compromise while it is still slow-moving. If your agents call models through a central gateway, that gateway is the natural choke point for rate limits and per-agent API accounting — our guide to building a resilient LLM gateway covers that layer in depth.

There is a regulatory dividend here too. If an agent incident touches personal data, both India's DPDP Act and UK GDPR put you on a clock with your regulator — the CERT-In six-hour reporting window in India is stricter still for cyber incidents. An immutable log of exactly what the agent executed, read and sent is the difference between reporting a bounded incident with evidence and reporting that you cannot rule anything out.

Where to start on Monday

The ladder gives you the adoption order. Start with a hardened container and a default-deny egress proxy — the pair costs a day of work and removes the two cheapest attack paths, arbitrary writes and arbitrary exfiltration. Add per-agent, task-scoped credentials and approval gates on irreversible actions next; they are policy work more than infrastructure work. Graduate to microVMs — Firecracker or Kata on your own hosts, Docker Sandboxes on developer machines, or a remote service such as E2B, Modal or Daytona if you would rather not run the plumbing — the moment an agent executes code influenced by anyone outside your team: web content, customer input, third-party documents. And decide now, in writing, that a sandbox escape attempt or a burst of denied egress is a security incident with an owner and a post-mortem, not a curiosity in a dashboard. Teams in Bengaluru, Mumbai, London and Manchester are converging on the same architecture because the threat model is identical everywhere: the agent will eventually be wrong, and the sandbox decides what being wrong costs.

If you have built this in production — microVM fleets for agent workloads, egress policies that survived a red-team, approval flows that developers did not route around — that is exactly the kind of concrete, load-bearing work worth putting where the people hiring can see it.