How do we sandbox an AI agent's code execution?

Sandboxing an agent's code execution means running any code it writes or executes inside an isolated environment with no default access to your production network, credentials, or file system beyond what the specific task explicitly requires. The standard approach uses lightweight container or microVM isolation, such as gVisor, Firecracker-based sandboxes, or a dedicated container per execution with a strict resource limit on CPU, memory and execution time, so a runaway or malicious script cannot exhaust host resources or persist beyond the task. Network access from the sandbox should default to fully blocked, with narrow, explicit allowlists added only for the specific external services a task genuinely needs, since unrestricted outbound access is the most common way a compromised or misbehaving agent exfiltrates data or reaches unintended systems. Filesystem access should be similarly scoped to a temporary, ephemeral workspace that is destroyed after each task rather than a persistent volume, and any credentials the sandboxed code needs should be short-lived, scoped tokens rather than long-lived secrets. Logging every command executed and every network call attempted, including blocked ones, gives you visibility for both debugging and security review. Nanobase AI builds these sandboxed execution environments as a standard component whenever an agent needs to run generated code.

Choosing an isolation technology

Not every isolation level fits every workload, and picking the heaviest option by default wastes latency and infrastructure budget on tasks that do not need it. The right choice depends on how much you trust the code being executed and how fast the sandbox needs to spin up, not on which technology is newest.

Layering controls beyond the isolation boundary

The isolation technology is only one layer, and treating it as the whole solution is a common mistake. Resource limits on CPU, memory and wall-clock execution time stop a runaway or intentionally abusive script from exhausting shared infrastructure, and these limits should be tight enough to fail a legitimate task loudly rather than generous enough to never trigger. Outbound network access should default to fully blocked and be opened only for the specific domains a given task genuinely needs, since unrestricted egress is the most common path a compromised or manipulated agent uses to exfiltrate data, a risk that compounds for agents with web access, covered in more depth in preventing prompt injection on web-browsing agents. Filesystem access should be an ephemeral, per-task workspace destroyed immediately after the task ends, never a persistent volume shared across tasks or sessions.

Credential handling inside the sandbox

Any credential a sandboxed task needs, such as an API key for a specific downstream service, should be short-lived and scoped to that single task rather than a long-lived secret pulled from a shared vault. A practical pattern issues a token scoped to one task ID with a lifetime measured in minutes, injected into the sandbox environment at execution time and invalidated immediately when the task completes or times out. This limits the blast radius if a sandbox is compromised mid-execution to whatever that single task's narrow scope allowed, rather than exposing a credential that could be reused after the fact. Short-lived, task-scoped credentials limit the blast radius of a compromised sandbox to a single task's narrow permissions.

A practical checklist before enabling code execution

1. Confirm the isolation technology matches the actual trust level of the code being run, not the default your framework ships with.
2. Set CPU, memory and wall-clock limits low enough to fail loudly on abnormal behavior rather than merely on extreme abuse.
3. Default network egress to fully blocked, then add explicit, narrow allowlists per task type as a deliberate decision, not a convenience default.
4. Use an ephemeral, per-task filesystem and destroy it immediately after the task, including on failure paths.
5. Issue short-lived, task-scoped credentials rather than long-lived secrets, and confirm they expire even if the sandbox itself fails to clean up.
6. Log every command executed and every network call attempted, including blocked attempts, to a store the agent's own code cannot alter. Working through this checklist before the first production task runs is far cheaper than responding to an incident after the fact.

What logging needs to capture to be useful later

A sandbox log that only records successful actions misses the security-relevant signal, since blocked or attempted actions are often the clearest evidence of a prompt injection or a misbehaving task. Capture the full command or code executed, every network call attempted whether allowed or blocked, resource usage at termination, and the triggering task ID linking back to the user or workflow that initiated it. This log should live outside the sandbox and outside the agent's own reach, since a log an agent could plausibly alter provides no real audit value during an incident review. A log that only records success gives no signal during exactly the incident review it exists for.

Frequently asked questions

Is a standard Docker container ever enough for agent code execution?

For low-risk, well-scoped tasks with limited untrusted input, yes, but it shares the host kernel and offers weaker isolation than gVisor or Firecracker. Reserve plain containers for cases where the code's origin and behavior are already reasonably trusted.

How fast does a secure sandbox need to be to stay practical?

Modern microVM and gVisor-based sandboxes typically start in well under a second at scale, which is fast enough for most interactive agent workflows; the added latency is rarely the limiting factor compared to the model's own response time.

Should the sandbox have any persistent storage at all?

Generally no for the execution workspace itself. If a task genuinely needs to persist an output, write it to a separate, access-controlled storage service after the sandbox completes, rather than giving the sandbox itself a persistent volume.

What is the single most common sandboxing mistake?

Leaving network egress open by default and only restricting it after an incident. Default-deny egress with explicit allowlists closes the most common exfiltration path even when other defenses fail.

How Nanobase AI helps

Nanobase AI builds sandboxed code execution as a standard component of every agent that runs generated code, matching isolation strength, network policy and credential scoping to the actual risk of each task rather than a one-size-fits-all default. Read more about the team's AI security and infrastructure services, or see the FAQ for common questions clients raise before their first agent touches production data.

Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.