Isolating agent-generated code takes three decisions, in order. Choose the kernel boundary first, then limit outbound traffic and keep credentials outside the environment where the code runs. Archil combines microVM isolation with network-boundary controls, but the right approach depends on code trust and workload needs. Containers, gVisor, and microVMs solve different problems. None makes unrestricted networking or readable secrets safe by association.
Why agent-generated code creates a threat model that standard isolation advice was not designed for
Agent-generated code is arbitrary, unreviewed, and produced at runtime from prompts, context, and objectives. The platform cannot audit it before execution. Unlike software written in-house that passed a CI pipeline, what this code will do is still unknown when deployment begins.
Prompt injection can turn that uncertainty into malicious action. An agent that has been tricked may abuse its filesystem and API access, then use outbound calls to send data beyond where it was meant to go. If it also escapes its runtime, the breach can spread across shared infrastructure. That chain exposes three distinct surfaces, namely execution escapes, unauthorized network calls, and credentials readable by code. Each needs its own control.
What the kernel boundary actually determines, and why it is the first decision
The kernel boundary determines what compromised code can reach. Containers send system calls straight to the host kernel they share. A userspace kernel intercepts those calls before they reach the host, while a microVM gives the workload a dedicated guest kernel behind hardware virtualization. These security boundaries differ in how they protect code as well as how fast they start.
That placement shapes the controls built around it. Egress enforcement lives outside the sandbox, and credential injection depends on keeping secrets beyond the agent’s reach. If an escape compromises the host that enforces policy, both protections become less trustworthy. The boundary therefore comes first, because it determines how independently the other controls can stand.
Hardware sharing remains a separate concern. Dynamic Frequency-Based Fingerprinting Attacks against Modern Sandbox Environments demonstrates identification attacks using CPU frequency sensors across containers, userspace-kernel sandboxes, microVMs, and TEE-based sandboxes. A stronger execution boundary does not remove physical co-tenancy.
Containers: where the shared kernel becomes the problem, not the runtime
Standard containers use Linux namespaces and cgroups to separate processes, with seccomp profiles and capability dropping available for hardening. This works for trusted, internally written code. The structural limit is that namespaces change what processes can see while the host kernel still handles their calls. An exploitable host-kernel bug can therefore turn one compromised container into host access.
Code that installs packages, writes Python scripts, and manipulates file descriptors is actively exercising the kernel interface. When untrusted inputs tell code to do those things on shared infrastructure, ordinary containers are the wrong boundary.
Containers still fit single-tenant developer machines that run the owner’s prompts and trusted CI environments where there is no multi-tenant adversary. They also suit high-churn workloads where prebuilt images and warm caches make sub-second starts the dominant requirement. Adding gVisor changes the comparison because it moves the syscall boundary, rather than merely tightening the same container configuration.
gVisor: how intercepting syscalls in userspace changes the blast radius without requiring a VM
gVisor inserts a userspace kernel through runsc between workload code and the host. System calls hit that layer first, and only a small, controlled set of operations reaches the host. A bug in an emulated syscall therefore affects the sandbox. The exposed host interface becomes much narrower.
Its practical advantage is independence from hardware virtualization. gVisor does not require KVM, so it can run in some cloud VMs and CI runners where nested virtualization is unavailable. Compute-heavy, syscall-light workloads run close to native performance. I/O-heavy workloads pay for the userspace round trips, with overhead of 10-30%.
Compatibility is the other price of this boundary. Some less-common syscalls and /proc features are unsupported or behave differently, so teams should test their agent dependencies before committing. For GPU-dependent agents, gVisor and full VMs are available paths, while Firecracker lacks GPU passthrough.
Firecracker microVMs: what a dedicated guest kernel actually provides, and what it does not
Firecracker boots each workload with its own guest kernel on KVM. The workload talks to that guest kernel. Reaching the host requires escaping the guest kernel and then the hypervisor, creating two distinct barriers. For genuinely untrusted multi-tenant code, that hardware boundary is the appropriate default.
The design stays practical by leaving hardware out. Its stripped-down device model excludes BIOS, PCI, and USB, with roughly 5 MiB of memory overhead per VM and boot time around 125 ms to application code. Each VM has its own Firecracker process, further sandboxed with seccomp, namespaces, and cgroups. Archil runs every sandbox on these microVMs with separate Linux kernels, on a Firecracker runtime that has run production workloads since 2025.
Minimal does not mean immune to vulnerabilities. CVE-2026-1386 describes a jailer symlink host-file overwrite affecting versions up to and including v1.13.1 and v1.14.0. The VMM and jailer need continuous patching, just as guest kernels do. Firecracker also lacks GPU passthrough, so hardware isolation does not automatically mean workload compatibility.
The microVM boundary addresses the kernel-escape threat surface. It leaves outbound-network and credential exposure open. After choosing the mechanism, those are the next controls to resolve.
How to match isolation mechanism to actual threat level, not to a default
The decision starts with how much the code deserves trust. Standard containers are appropriate for trusted internal code that passed CI/CD. Generated scripts solving well-defined tasks warrant gVisor or microVMs, because a shared kernel unnecessarily expands the consequences of hostile or faulty execution. Code that users supply, the installation of third-party packages, and code shaped by prompt injection need hardware virtualization.
Operational constraints still belong in that decision. gVisor fits routine compute-heavy, syscall-light execution, especially where KVM is unavailable and dependency testing shows acceptable compatibility. MicroVMs fit builds, third-party installs, and untrusted external inputs. GPU requirements may instead require gVisor or a full VM.
Stronger isolation takes more work to run and can make some code harder to support. Managed infrastructure absorbs much of the fleet-management burden, but it does not remove the need to inspect the architecture. Teams should ask providers which hypervisor they use, what their default egress policy is, and where they keep secrets. “Secure sandbox” is a label that leaves those architectural questions unanswered.
Egress policy: why the outbound network surface is the second kernel-boundary decision
Outbound traffic should be restricted to an explicit allowlist by default. A manipulated agent can otherwise call attacker-controlled endpoints, exfiltrate data through DNS or HTTP, or probe internal infrastructure without escaping anything. Monitoring sees the call after it happens. A prevention policy must sit in its path.
That enforcement should live outside the sandbox. Container network namespaces and iptables can restrict traffic, but their enforcement depends on the same host kernel a container escape compromises. With microVMs, the rules at the network boundary are enforced outside the guest kernel. An attacker who compromises the guest therefore still has to break through the egress policy.
On Archil’s Free plan, that boundary permits only a managed allowlist of package registries, Git hosts, container registries, OS package mirrors, and model APIs, and that allowlist is fixed for users. On Developer plans and above, users can set custom domain and CIDR firewall rules, including default-deny; a sandbox created without a policy has unrestricted egress.
Policy can also follow the stages of a task. For example, a pull phase can allow a data source, processing can deny egress, and delivery can allow only the upload destination. updateNetwork replaces a running sandbox’s complete policy and applies immediately to new connections, while existing connections stay open. getNetwork returns the current policy. These controls do not address CPU-frequency fingerprinting, which needs separate hardware-level countermeasures such as noise injection.
Credential handling: why injecting secrets at the network boundary is safer than handing them to the agent
An API key inside the sandbox is readable by code running there. Environment variables and mounted secret files both create that exposure, including to packages the agent installs. Code deliberately given access to a secret in a microVM can read it. It is using the front door.
Credential brokering changes where authentication happens. An egress proxy adds the API key as an allowed request leaves the sandbox, keeping the credential out of the agent’s memory and filesystem. For encrypted traffic, the proxy terminates TLS, adds the authorization header, and re-encrypts the request before forwarding it. Teams must account for that interception when they plan certificate trust.
Credential brokering in Archil is available on Developer plans and above. Its proxy terminates TLS only for hosts matching an allow rule with a header-adding transform. The resulting trust decision is explicit. Because the proxy can read plaintext request bodies, teams with strict data-handling requirements must evaluate the platform operator as a trusted party or consider BYOC deployment in their own infrastructure.
Persistent environments, branching, and what changes when the sandbox survives restarts
Rebuilding every session forces agents to reinstall dependencies and reconstruct state. With persistence, a durable root disk gets rid of that repeated work and the attack surface it creates. It also lengthens the security obligation. The isolation boundary must protect saved state across sessions as well as contain each execution window.
With Archil’s persistent sandboxes, each microVM has its own Linux kernel and persistent root disk. The sandbox stays available across calls so long-running processes can continue while the agent works. Stopping it stops compute billing without losing files or installed dependencies. The preserved workspace’s contents may still be untrustworthy.
Checkpoints and branches make parallel attempts practical without rebuilding everything. A checkpoint is a named, immutable snapshot of filesystem state, and a branch is an independent writable copy from it. A checkpoint takes about 15 ms and a branch about 35 ms, whatever the disk size. That figure describes filesystem-only operations, with CPU and memory state excluded. With copy-on-write, branches share the base data, and each branch adds only its own new data.
A team can therefore branch before running code, try each approach on its own, check the results, and keep the best outcome. Rollback becomes a filesystem operation. Checkpoints and branches became generally available in all AWS regions in June 2026. For disks synchronized to a backing bucket, however, checkpointing and branching require users on Developer or Team to move to Enterprise. These workflow capabilities still depend on isolation.
Applying all three layers together: what a defensible agent sandbox architecture looks like
For genuinely untrusted code, the execution layer should use hardware virtualization. Egress should start from default-deny or an explicit managed allowlist, with per-agent customization for production workflows.
Archil is a concrete option for that combination. Its microVMs provide dedicated Linux kernels and persistent root disks, with a managed egress allowlist on Free and custom firewall rules, including default-deny, on Developer and above. Developer and higher plans also add credential brokering through egress-proxy TLS interception. For data access, teams can mount their own S3, GCS, R2, or Azure Blob bucket as a POSIX filesystem without migration, and disks are also reachable through an S3-compatible API.
The evaluation should test claims. Which hypervisor is used, and how is its VMM patched against recent CVEs? Can egress be overridden per agent, and where do secrets live? How long has the underlying infrastructure handled production load? Those answers expose whether the execution, network, and credential controls form a coherent architecture or whether a strong first boundary is being asked to do three jobs.