Teams buying a sandbox for AI agent code often pick on start-up speed and SDK convenience, then find that the product shares a kernel with other tenants, allows open internet egress by default, or cannot keep credentials out of the code it runs. Code execution sandboxes for agents are now a separate purchase line: hosted code execution APIs, self-hosted microVM and user space kernel platforms, sandboxes built into agent platforms, and browser or desktop sandboxes for computer use agents. This vendor-neutral buyer's guide sets out how to define requirements, which capabilities separate a real isolation boundary from a convenient container, and how to test candidates against your own agents. It is for platform engineers, security architects and procurement leads. The isolation technologies themselves are explained in the AI Agent Sandboxing and Code Execution Guide, which this page does not repeat.
Key takeaways
- Buy the boundary, not the API. Ask which isolation technology sits under each sandbox (container, user space kernel, microVM, WebAssembly) and whether tenants share a host kernel. A nice SDK on a shared-kernel container is a weaker product than it looks.
- Egress control is a hard requirement. A sandbox that can reach the whole internet turns a prompt injection into data exfiltration. Default deny with an allowlist should be possible per sandbox.
- Credentials are the blast radius. Evaluate how secrets reach the sandbox, how long they live and whether the agent's own credentials can ever be read by generated code.
- Ephemeral and observable by design. Fresh sandbox per task, destroyed afterwards, with every execution, file write and network connection logged to your own SIEM.
- Hosted means your data leaves. Hosted sandboxes process code, files and outputs on the supplier's infrastructure, so treat the purchase as a third-party risk decision as well as a technical one.
Define requirements
Start from the workloads, not the product list. Write down, for each agent that will run code, who can influence its input, what the code needs to reach and what would happen if it ran hostile code.
- Trust of input: internal analysts using a data assistant are a different risk from a customer-facing agent that reads web pages, email or uploaded files. Untrusted input argues for a second boundary (user space kernel or microVM) rather than a plain container.
- Workload shape: short code interpreter calls (seconds), long-running coding agents (hours, with package installs and build tools), browser or desktop sessions for computer use, or narrow tool functions that could run in WebAssembly.
- Language and library needs: Python data science stacks, Node.js, arbitrary binaries, GPU access. WebAssembly runtimes and user space kernels may not support everything; check before you shortlist.
- Data: which files, datasets and outputs enter the sandbox, their classification, and whether they may leave your cloud account or region.
- Reach: package registries, internal APIs, model endpoints, nothing at all. This becomes the egress allowlist.
- Scale and latency: concurrent sandboxes at peak, acceptable cold start, session duration and whether state must persist between steps.
- Operating model: hosted service, self-hosted on your Kubernetes or bare metal hosts, or the sandbox built into an agent platform you already use.
Small organisations with a few internal agents often get the best risk reduction from a hosted service or a platform-native sandbox with egress locked down. Large organisations with regulated data or many agent teams usually need a self-hosted or customer-cloud deployment with central policy, so that code and data stay inside their own boundary.
Capability areas
| Capability area | What good looks like | Why it matters |
|---|---|---|
| Isolation boundary | Hardware virtualisation (for example KVM-based microVMs) or a user space kernel per sandbox; no shared host kernel between tenants; documented escape response | Docker's default seccomp profile disables only around 44 of 300+ syscalls; a shared kernel is one bug from host access |
| Network control | Default deny egress, per-sandbox allowlists by domain or address, no route to cloud metadata endpoints or internal networks, DNS logging | Stops exfiltration and lateral movement from injected code |
| Credential handling | No long-lived secrets in images or environment; short-lived scoped tokens injected per task or brokered outside the sandbox | Generated code can read anything inside the boundary |
| Filesystem | Read-only base image, explicit mounts, capability-style grants (as WASI does for WebAssembly), wiped on teardown | Prevents persistence and cross-task data leakage |
| Resource limits | CPU, memory, disk, process count, wall clock and network bandwidth caps per sandbox | Contains runaway loops and cost abuse (OWASP LLM10 Unbounded Consumption) |
| Lifecycle | Per-task creation and destruction, snapshot and pause only where needed, maximum session length | Limits what one compromise can carry forward |
| Observability | Logs of commands, processes, file writes and connections tied to agent ID and session, exportable to your SIEM | Investigation and detection need per-action evidence |
| Identity and access | SSO and RBAC for the console, scoped API keys per agent or team, key rotation and audit logs of sandbox API use | The sandbox API key is itself a non-human identity that can launch compute |
See the Agent Egress Control and Network Isolation Guide for allowlist design and the AI Agent Credential Lifecycle and Rotation Guide for token issuance.
Evaluation criteria
| Criterion | Weight (suggested) | Evidence to request |
|---|---|---|
| Isolation strength and tenancy model | 25% | Architecture document naming the runtime and hypervisor, tenancy diagram, third-party penetration test summary |
| Network and egress policy | 20% | Live demo of default deny, allowlist change, blocked metadata endpoint |
| Secrets and credential model | 15% | Description of how tokens are injected, scoped and revoked; proof they are absent from logs |
| Logging and SIEM export | 15% | Sample log records, schema, export method, retention options |
| Workload compatibility and performance | 10% | Your own benchmark: cold start, package install, typical task duration |
| Data residency and supplier assurance | 10% | Regions, sub-processors, independent assurance reports, data deletion terms |
| Cost model and limits | 5% | Pricing per second or per sandbox, hard spending caps, quota alerts |
Adjust weights to the requirements: a customer-facing agent reading untrusted content should weight isolation and egress higher still.
Questions to ask vendors
- Boundary: Which runtime isolates each sandbox (runc container, gVisor runsc, Kata Containers, Firecracker or another hypervisor, WebAssembly)? Do two customers' sandboxes ever share a host kernel?
- Second line of defence: If the primary boundary fails, what stops host access (for example a jailer process, seccomp on the hypervisor process, dedicated hosts)?
- Escapes: How do you patch hypervisor and kernel vulnerabilities, how fast, and how would you notify us of an escape affecting our tenant?
- Egress: Is egress denied by default? Can we set allowlists per sandbox through the API? Is the cloud metadata address blocked?
- Secrets: How do credentials reach the sandbox, can they be scoped to one task, and are environment variables ever written to logs or snapshots?
- Persistence: What survives teardown? Where are snapshots and uploaded files stored, encrypted with whose keys, and for how long?
- Logging: Which events are logged (process start, command, file write, network connection), with what identifiers, and how do we stream them to our SIEM?
- Deployment: Can the sandbox run in our own cloud account or cluster, and does that version have feature parity with the hosted one?
- Abuse controls: What stops a sandbox being used for crypto mining, scanning or spam from your addresses, and how would that affect our account?
Red flags
- "Secure container" with no runtime named: vague isolation claims usually mean shared-kernel containers.
- Open egress by default with no per-sandbox policy: you will not be able to stop exfiltration from injected code.
- Restricted interpreter as the boundary: removing Python modules or built-ins is not isolation; language-level filters are routinely bypassed.
- Long-lived API keys only: no scoping per agent, no rotation, no audit log of sandbox API calls.
- Logs only in the vendor console: no export means no correlation with identity and endpoint data during an incident.
- Snapshots kept indefinitely: state that includes secrets or customer data outlives the task.
- No answer on escape handling: any supplier running untrusted code at scale should have a documented process.
Proof of concept
- Pick two or three real agents covering your workload shapes (a code interpreter, a coding agent with package installs, a computer use session if relevant).
- Configure the target policy first: default deny egress with your allowlist, no long-lived secrets, resource caps, per-task teardown.
- Run functional tests: your actual libraries, file sizes and task durations; record cold start and failure rates.
- Run hostile tests in a test tenant: scripted prompt injection that asks the agent to read environment variables, reach the metadata endpoint, call a non-allowlisted domain, fill the disk and fork processes. Expect each to be blocked and logged. Use only benign test code, never real exploits.
- Check teardown: confirm files, processes and credentials are gone after the task and that a new sandbox cannot see the previous one's data.
- Check evidence: pull the logs into your SIEM and reconstruct one session end to end, tied to agent identity.
- Review supplier assurance with procurement: data processing terms, regions, sub-processors, assurance reports and exit plan.
- Decide with a scorecard against the evaluation criteria, and keep a rollback path (agent tool disabled or routed to a fallback sandbox) for the first production weeks.
Related controls for running agents in production are covered in the AI agent runtime reference architecture and the AI Agent Kill Switch and Containment Guide.
How NHI Mgmt Group can help
We provide independent advice on agentic AI identity, runtime controls and tool evaluation. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: AI Agent Sandboxing and Code Execution Guide · Agent Egress Control and Network Isolation Guide · Container Runtime Security Guide · AI Agent and LLM Observability Buyer's Guide