An AI coding agent sandbox has to contain code that runs before anyone reviews it. A product page that says "isolated" or "secure" does not tell you whether the agent shares a kernel with another tenant, can send your repository anywhere on the internet, or holds a reusable source-control token in an environment variable.
This checklist turns those claims into seven questions you can verify in documentation, configuration and a test session. Use it to review a managed service, a self-hosted project or a sandbox your team built.
Review all seven checks together. Strong isolation does not compensate for unrestricted egress, and a strict network policy cannot protect credentials that the agent can read.
The seven checks
| Check | What you want to see | Weak answer |
|---|---|---|
| Isolation boundary | A named mechanism and a clear statement about whether the workload has its own kernel | "Containerized", "isolated" or "secure" without an architecture |
| Network egress | Outbound traffic blocked by default, with narrow destinations added for the task | Open internet access, or filtering available only after extra configuration |
| Secrets handling | Short-lived or brokered credentials kept outside the agent process where possible | Long-lived bearer tokens injected into environment variables |
| Control-plane access | The sandbox cannot administer itself or other sandboxes | A management API reachable with credentials available inside the session |
| Persistence and reset | An explicit list of what survives, what is destroyed and when deletion occurs | "Ephemeral" without stating what happens to volumes, snapshots and logs |
| Tenant boundary | The isolation unit and shared components are documented | "Dedicated" without saying whether that means a process, VM, host or account |
| Data location | Separate locations for execution, storage, logs, control plane and model traffic | One regional label applied to the complete system |
1. Name the isolation boundary
Ask the provider what separates agent code from the host and from another customer's session. The answer should name the mechanism.
A standard Linux container uses namespaces and cgroups while sharing the host kernel. gVisor adds a user-space kernel that intercepts many system calls before they reach the host. A virtual machine or microVM gives the workload its own guest kernel behind a hardware virtualisation boundary. These designs have different attack surfaces. They should not share one undifferentiated "sandbox" label.
Record at least:
- the isolation unit: process, container, gVisor sandbox, VM or microVM;
- whether each session has its own guest kernel;
- the virtual machine monitor, container runtime or user-space kernel in use;
- what the session shares with other tenants;
- whether host directories, sockets or devices are mounted into the sandbox.
Then test the claim. Inside a Linux session, inspect the kernel version, mounts, process tree, devices and available sockets. A test cannot prove that a boundary is secure, but it can expose a setup that does not match the documentation.
Our Docker sandboxing and microVM comparison explains the kernel boundary in detail. A microVM gives the untrusted process a guest kernel. Network policy still determines what that process can reach.
2. Test the default network policy
Create a new sandbox with the smallest valid configuration. Do not add a network policy first. From inside the session, try to reach:
- the package registry the task needs;
- an unrelated public website;
- an IP address directly, without DNS;
- a private address and the cloud metadata address;
- a lookalike domain outside the allowlist, such as
notexample.comwhenexample.comis allowed; - a redirect from an allowed site to a blocked site.
Write down what succeeds before you change any settings. A service may support an allowlist while still giving every new sandbox unrestricted outbound access.
A useful policy names destinations, protocols and ports. It also states where enforcement happens. A rule implemented inside the guest can be changed by a sufficiently privileged process in that guest. A host-side gateway or datapath sits outside the workload it controls.
Check DNS separately. Blocking an HTTP request does not show that DNS tunnelling, raw IP connections, alternate ports or IPv6 follow the same policy. Ask how the product handles each path rather than assuming one successful test covers them all.
3. Find where the real credentials live
Coding agents commonly need a model key, repository access and package-registry credentials. Search the session environment, configuration files, process arguments, mounted files and credential helpers. If a reusable bearer token is present, code in the sandbox can usually read it.
Prefer credentials that are:
- scoped to one repository or operation;
- short-lived;
- unavailable to the agent process until a specific request needs them;
- substituted by a proxy or broker only for the intended destination;
- revoked when the session ends.
Credential brokering reduces exposure, but it needs its own review. Ask where the proxy decrypts the request, whether the agent can reach the unencrypted connection, which requests the broker will authorise, and whether an approved destination can receive unrelated data.
An allowlisted model endpoint does not make a readable model key safe. The agent can still send that key, source code or other readable data to any permitted endpoint that accepts arbitrary content.
4. Separate the sandbox from its control plane
The control plane creates sessions, changes policy, attaches storage and issues credentials. A compromised sandbox should not be able to call those operations with an identity available inside the sandbox.
Check whether the session can resolve and reach management endpoints. If it can, identify the authentication material. Using an account and API you are authorised to test, check whether the token can perform any read-only management operation. The provider should document which control-plane calls are reachable from the workload network and why.
Pay particular attention to tokens used by an in-sandbox agent or sidecar to report status. A token intended to update one job should not list projects, create new sandboxes, change network policy or read another tenant's logs.
5. Define what survives the session
"Ephemeral" often describes the compute process while attached storage, snapshots, caches and logs remain. Ask for a list of artifacts and retention periods.
Verify:
- whether the root filesystem is destroyed or recycled;
- whether workspace volumes persist across sessions;
- whether snapshots contain memory or credentials;
- how package and build caches are separated between tenants;
- how long command logs, network logs and artifacts remain;
- what a deletion request removes, and on what schedule.
Persistence is useful for long-running coding work. It becomes a security problem when a later session inherits files, credentials or poisoned tooling without an explicit trust decision.
6. Identify the tenant boundary
Ask what "dedicated" means. A dedicated process, container, microVM, host and cluster provide different boundaries and different costs.
Map the components shared across customers: host kernel, virtual machine monitor, image cache, network gateway, storage service, log pipeline and control plane. For each shared component, record the identity or policy that prevents one tenant from reading or changing another tenant's data.
If a dedicated-host option exists, confirm whether the host is dedicated physically for the contract term or merely scheduled for one customer at a time. Also ask what happens during maintenance, failover and capacity shortages.
7. Split the data-location claim into systems
"EU-hosted" can refer to one database while model prompts, logs or support data leave the region. Review these paths separately:
| System | Location to verify |
|---|---|
| Agent execution | Where the VM or container host runs |
| Workspace and snapshots | Where repository data and persistent volumes are stored |
| Logs and telemetry | Where command, network and product analytics data are processed |
| Control plane | Where session metadata, policy and account data live |
| Model traffic | Which model provider and region receive prompts and tool output |
| Support and subprocessors | Where staff and vendors can access operational data |
Data residency does not establish legal or operational sovereignty by itself. The operator, model provider and administrative access still matter. Our sovereign AI guide separates those layers.
A 30-minute evaluation
You can run a useful first pass without penetration testing:
- Create a sandbox with default settings and save its configuration.
- Record the kernel, mounts, devices, processes and reachable local sockets.
- Test an unrelated public domain, a raw public IP and a private address.
- Search for credentials in the environment, files and process arguments.
- Identify every endpoint the sandbox can reach and classify its owner.
- Stop the session, start another and check which files or identifiers remain.
- Compare the results with the provider's documentation and ask about every mismatch.
Run these tests only in an account and environment you are authorised to assess. Use harmless endpoints and test credentials. The goal is to verify the advertised posture, not to probe shared infrastructure or another tenant.
How to record the result
Keep evidence next to each answer:
| Field | Example evidence |
|---|---|
| Claim | "Outbound access is blocked unless a destination is configured" |
| Source | Permanent documentation or source-code URL |
| Verified on | Date and product version |
| Default or optional | Default for every new session, or customer configuration |
| Test | Command and observed result in a test account |
| Unknown | The exact point the provider does not document |
Record missing documentation as "unknown" and ask the provider for evidence. Do not treat it as a favourable answer.
How ainclave answers the checklist
ainclave runs each agent session in its own Firecracker microVM with its own guest kernel. Egress starts closed and the session reaches only destinations derived from its configuration at creation time. The host datapath enforces that destination set outside the guest. Filesystem policy is declared and fixed at creation; it is enforced with Landlock where the guest kernel provides it.
Proxy-bound model, source-control and remote MCP credentials appear inside the guest as references. A proxy substitutes the real bearer token on the outbound request. We do not claim that this creates a process boundary inside the guest: the proxy terminates TLS there, and whether the agent could reach plaintext in that process is untested.
Shared-capacity sessions do not provide physical single-tenancy. The dedicated tier does. The product is currently in a design partner phase, and several controls remain limited or on the roadmap. Read how the boundary is enforced for the current architecture and stated limitations, then use the checklist above to challenge it.