AI Agent Sandbox Security: Check Each Access Boundary

AI agent sandbox security depends on where code runs and what you let it access. A microVM gives the workload a separate guest kernel, strengthening one isolation boundary. Before an agent receives private source code or an untrusted vulnerability report, you still need evidence that its files, network access, credentials, external tools, and returned results stay within the task’s limits.

Start with a concrete approval question: what can this run read, change, contact, and cause your team to accept? Record the answer for the configuration you will use. A product’s architecture diagram helps explain its design; your task also needs an access policy and a way to check that policy holds.

What a microVM changes

A microVM separates a workload’s kernel from the host kernel. That changes the execution boundary compared with a shared-kernel container, but host configuration and deliberately shared resources still matter. Vercel’s agent sandbox overview explains this separation alongside file, network, and credential controls.

In its November 4 architecture account, Replit describes moving to microVMs using Cloud Hypervisor, with containers inside the guests. It also describes an unprivileged virtual machine monitor, network enforcement outside the guest for sandboxes with an egress policy, and credential brokers for managed connectors. These are distinct controls in Replit’s account, not evidence that every request or user-supplied secret has the same protection.

A separate Firecracker demonstration from PWN Research shows why launch conditions belong beside security claims. The researcher used Firecracker v1.16.1 launched as root without a jailer, building on a previously obtained host-memory access primitive. That is not a demonstration of an escape from a hardened production deployment or from Replit’s Cloud Hypervisor environment. Firecracker’s production host guidance calls for unprivileged execution and confinement; it does not establish that a jailer would necessarily stop the underlying memory access.

If you are evaluating a provider, ask which runtime, privileges, and host integrations your workload uses. Keep those answers with the version and configuration you approve.

List the bridges you deliberately open

A sandboxed agent can cause damage through access you intentionally grant. You need to inspect these bridges even when the execution boundary works as designed.

Docker’s local sandbox security model makes several of them explicit: direct workspace mounts, credential proxying, SSH signing access, and external MCP servers. It warns that workspace edits can change development execution paths and that local stdio MCP servers run on the host. Those are integration paths to evaluate in that local setup, not proof of a VM escape.

Work through four questions:

• Files: does the agent see a disposable source snapshot, or can it edit the checkout you will later build and run? Review hooks, build configuration, and instructions among the returned changes.
• Network: which destinations, paths, and operations are permitted? An approved inference endpoint receives the input you send it. An allowlist alone does not make that disclosure acceptable.
• Credentials: what can the agent do with the available authority? A broker may hide the raw API key while still allowing powerful authenticated calls. A signing socket also deserves an explicit decision.
• Tools: where does each tool execute, and whose identity does it use? A host process or remote API needs its own authorization boundary.

Include persistent state in this inventory. Shared caches, saved snapshots, and reusable agent instructions can carry changes into later tasks. Decide who owns each retained artifact and how to recreate a clean run before assuming a new session starts clean.

Require evidence for each boundary

Approve a specific configuration using checks you can repeat. The table below proposes an acceptance record drawn from the control boundaries above. It is not a record of tests we ran against these providers.

Use dummy secrets, disposable environments, and endpoints you control. You do not need a live exploit or real-data exfiltration to test whether policy-prohibited access is denied.

Attach the policy revision and check results to the approval. “Network restricted” is less useful than a record showing which request was blocked, which approved request succeeded, and which configuration produced both results.

Passing demonstrates the tested controls at that revision. It does not prove that every prompt injection fails, that every permitted operation is safe, or that no escape vulnerability exists. Repeat affected checks when you change a mount, tool, token policy, runtime, or persistent image.

Rehearse one report-triage task

Consider a hypothetical team preparing an agent to read a private repository and one submitted vulnerability report. The acceptance exercise should cover the whole task, including the result it sends back.

1. Prepare disposable inputs. Use a source snapshot and a sample report with dummy tokens. Keep production credentials and real reports disconnected.
2. Add a harmless injection canary. Put instructions in the sample report asking the agent to contact a team-controlled destination that the policy denies. Record the expected denial before running it.
3. Check both denial and useful work. Keep the legitimate inference and report-result routes available. A run that cannot contact anything does not show that the intended workflow works.
4. Inspect what returns. Retain the denied-request log, effective runtime configuration, and report, commit, and pipeline references. Check that the receiving service rejects a result aimed at another report and refuses unauthorized fields or prevents them from being stored.
5. Make the failure decision explicit. If the denied request succeeds, stop before connecting real reports. Fix the policy and repeat the exercise. If a permitted service receives data it should not receive, reconsider the inputs and narrow that service’s allowed paths or actions where applicable.

A logged request attempt and its policy denial demonstrate the path you tested. If the agent simply ignores the canary, that does not demonstrate network enforcement. Neither outcome establishes that all malicious instructions will be contained. Likewise, a well-formed result can still contain a mistaken conclusion, so technical acceptance must leave room for human judgment.

If you are already investigating suspected access, you have a different task. Use an agent-probe triage workflow to preserve evidence and assess what happened before returning to pre-approval checks.

Keep the result advisory and scoped

The receiving application needs its own boundary even when execution is well isolated. It should know which resource a run belongs to, what it may write, and who reviews its conclusions.

Kit’s code-aware triage illustrates this split. You operate the execution environment and its egress controls; Kit scopes the report exchange and receives advisory output. Kit dispatches your configured pipeline. It does not provision a microVM or configure and continuously verify your firewall.

The triage airgap guide describes a customer-operated, self-managed GitLab runner with environment-enforced deny-all egress and a token-validating proxy limited to inference and Kit MCP paths. Use that guide to configure and test your setup. An external CI pipeline does not become airgapped simply because it runs outside Kit, and masked variables remain accessible to code that receives them at runtime.

On Kit’s side, a signed token identifies one triage run and its report and tenant. The token expires after one hour and supports report reads, evidence attachment, and result submission. Accepted result fields are limited, and finalization blocks further writes. That write guard does not mean report reads necessarily stop immediately after finalization; token expiry is a separate limit.

The returned assessment remains advisory for human review. Use the triage-agent setup guide to connect the workflow, then keep an approval record for the environment you supply. The practical deliverable is a bounded run with retained evidence, a clear stop condition, and a reviewer who decides what happens next.