AI coding agents have changed the security question around generated code. A developer can ask an agent to modify a repository, install dependencies, run tests, start a service, inspect the filesystem, and call external APIs without manually executing each command. That makes the execution environment part of the security architecture, not just a developer convenience.
Containers were the obvious starting point because they are cheap, familiar, and already embedded in most cloud platforms. MicroVMs provide a stronger boundary by giving each workload its own guest kernel. Capability-based security attacks the problem from another direction, limiting what an agent can actually do even after it has access to a runtime. Observability adds another layer by showing what the agent really did rather than relying on its own logs.
Recent work from Edera, research around AgentSight, and Vercel's public sandbox challenge all point to the same conclusion: AI-generated code needs multiple independent security boundaries because each layer can fail in a different way.
A container is an isolation mechanism, not a trust boundary
Containers remain useful for AI workloads, particularly when the main requirement is process isolation and efficient resource usage. A container can provide a disposable filesystem, resource limits, namespaces, and restricted access to the host. For many ordinary workloads, that's enough.
AI-generated code changes the threat model.
An agent may install a package it has never seen before, execute arbitrary shell commands, compile native code, inspect environment variables, create child processes, or respond to instructions embedded in a repository or web page. If that code gains a container escape through a kernel vulnerability or a misconfigured runtime, the container's security model depends on the same host kernel that the attacker is trying to compromise.
That shared-kernel architecture is the important limitation. A container separates processes from each other through kernel-enforced mechanisms, but the workloads still depend on the host kernel. A kernel vulnerability can therefore turn a container-level compromise into a host-level problem.
Edera's documentation makes this distinction directly in its comparison of container and VM-based isolation: traditional containers share the host kernel, while its agent runtime gives workloads separate kernels through microVMs.
That doesn't make containers useless. It means the security question needs to be explicit: what happens if the code running inside the container is already hostile?
For AI-generated code, that should be the starting assumption.
MicroVMs move the boundary down into virtualization
MicroVMs address the shared-kernel problem by introducing a virtualization boundary between the workload and the host. Firecracker, for example, gives each sandbox a guest kernel while keeping the device model deliberately small.
Vercel's Sandbox architecture is a useful real-world example. Each sandbox runs inside its own Firecracker microVM with a dedicated guest kernel, while the user code runs inside a container within that VM. Vercel explicitly treats the microVM rather than the container as the security boundary.
That is a meaningful architectural improvement. An attacker who controls the code inside the container must now find a path through the guest kernel, virtualization layer, or another externally exposed boundary before reaching the host.
But virtualization doesn't make the problem disappear. It changes where the problem lives.
Vercel demonstrated that point unusually clearly in its 2026 sandbox security challenge. The company received 1,285 reports over two weeks and paid $242,000 in bounties. One researcher found a Linux kernel zero-day in the networking stack that could allow specially crafted packets originating from a microVM to leak host memory, crash the host, and execute code on the host.
The important lesson isn't that microVMs failed. Vercel's own architectural review concluded that its virtualization boundary was sound, and the company subsequently strengthened protections around the host and guest kernels. The lesson is that the kernel and virtualization stack become part of the trusted computing base.
Vercel's response included keeping host kernels current, disabling nested virtualization, using Firecracker's jailer, reducing kernel attack surface, and removing trust in values returned by software running inside the microVM.
That is what defense in depth looks like in practice. The sandbox is strong, but the architecture assumes the sandbox boundary will eventually be attacked.
The $1 million challenge was really a test of the boundary
Vercel's decision to offer up to $1 million to researchers trying to escape its Sandbox is more significant than the headline suggests.
The company wasn't simply asking researchers whether they could break a container. The challenge covered both the compute boundary and the network boundary. Vercel's architecture places network enforcement on the host, outside the microVM, because code inside the sandbox must not be able to disable its own network restrictions.
That distinction matters for agent infrastructure.
Suppose an AI agent cannot escape its microVM but can make unrestricted outbound HTTP requests. The attacker doesn't necessarily need a VM escape. A prompt injection could convince the agent to package sensitive information and send it to an external service using a legitimate network path.
Vercel described this explicitly when launching the challenge: isolation depends on both the Firecracker microVM and the host-side network controls.
A secure execution environment therefore needs to answer two separate questions:
Can the workload escape the machine-level boundary? Can the workload use legitimate capabilities to reach something it shouldn't?
MicroVMs answer the first question better than containers. They don't automatically answer the second.
Capability tokens solve a different problem
This is where Edera's work on bounded authority becomes useful.
Traditional credential-based access gives an application a secret that represents a potentially broad set of permissions. An agent might receive a GitHub token, cloud credential, database credential, or API key and then rely on application logic to use that credential correctly.
That creates a difficult assumption: the agent must be trusted not to misuse the authority it has been given.
Edera's object-capability approach reverses that model. Instead of giving the agent a broad credential and asking it to behave, the runtime gives it a narrowly scoped capability representing a particular authority. The capability might permit reading a repository, creating a pull request, restarting a specific deployment, or calling a particular API.
That creates a different security boundary from a sandbox.
A microVM answers: What can this workload physically reach?
A capability answers: What is this workload explicitly authorized to do?
Those questions should not be collapsed into one control.
An agent could be perfectly contained inside a microVM and still have excessive permissions inside that environment. If the agent has a valid credential that can read every repository in an organization, a successful prompt injection doesn't need a sandbox escape. The agent can simply use the credential it already possesses.
Edera describes its architecture as a combination of identity, isolation, capability, and management. Its capability broker can verify workload identity, validate the requested capability and its bounds, then perform the privileged operation without exposing the underlying credential to the workload.
That is a much stronger model for autonomous software than distributing long-lived credentials into agent environments.
The security model becomes clearer when the layers are separated
A useful architecture for AI-generated code looks something like this:
Agent → Action Policy → Capability Broker → Sandbox → Host Controls → Infrastructure
Each layer has a different responsibility.
- The agent decides what it wants to do. It should not be the final authority on whether that action is permitted.
- The action policy determines whether the requested operation is within the agent's task.
- The capability broker provides narrowly scoped authority without handing the agent broad credentials.
- The sandbox contains arbitrary code execution and limits filesystem, process, and network reach.
- The host controls enforce boundaries that the guest cannot modify, including network policy and virtualization protections.
- The infrastructure layer contains the remaining cloud, identity, storage, and operational controls.
This architecture is deliberately redundant. If one layer fails, the attacker still has another boundary to cross.
That redundancy matters because AI agents create unusual failure modes. An agent can be compromised through prompt injection without any software vulnerability. Generated code can contain a malicious dependency. A dependency can exploit a kernel bug. A legitimate credential can be abused without any sandbox escape. A network control can be misconfigured. A hypervisor can contain a zero-day.
Different failures require different controls.
Observability belongs outside the agent too
There is another problem with autonomous code execution: the agent's own explanation is not a reliable security log.
An agent may report that it ran a test suite, while the actual runtime shows a different sequence of process launches, filesystem operations, network connections, and child processes. Security teams therefore need visibility at the operating-system boundary rather than relying exclusively on application-level telemetry.
AgentSight is an example of this approach. Its research uses eBPF and system-level instrumentation to correlate an agent's higher-level intent with the effects visible at the operating-system level. The project tracks process activity, files, network activity, resource use, model calls, and tool decisions, allowing investigators to connect what an agent said it was doing with what actually happened.
That distinction becomes especially useful during incident response.
If an agent suddenly starts reading files outside its task directory, spawning an unexpected process, or making connections to an unfamiliar destination, the security system should be able to detect those effects even if the agent itself never reports them.
eBPF doesn't replace isolation. It doesn't prevent a malicious process from executing. It gives the security team an independent observation point.
That independence is the important part.
A sandbox can contain code while still allowing a bad action
AgentShield's documentation makes a related distinction between sandboxing and runtime action control. A sandbox can stop arbitrary code from reaching the host, but it doesn't necessarily stop an agent from abusing a tool it was legitimately given.
Imagine a coding agent running inside a microVM with no host access. It has a GitHub integration that can create pull requests and a database integration that can write records.
The microVM can successfully contain the agent.
It doesn't matter if the agent is allowed to call the database with production write permissions. If a prompt injection convinces the agent to modify records through that approved interface, no VM escape has occurred.
The attack happened entirely within the permitted capability set.
That is why tool authorization, data permissions, egress controls, and human approval belong outside the model's reasoning loop. AgentShield positions this as an action-boundary layer that intercepts tool calls, evaluates them against policy, and records the resulting decisions.
The broader architectural principle is more important than any individual product: Contain execution. Restrict authority. Observe effects. Enforce policy outside the model.
What should enterprises actually run?
There isn't one universal answer because the isolation level should follow the workload.
A low-risk internal agent that only transforms local text may not need a dedicated microVM for every invocation. A coding agent that installs arbitrary packages and executes generated binaries should be treated very differently. An agent operating against production infrastructure needs another level of control because the primary risk isn't only code execution; it's the authority attached to the tools.
For code-executing agents, the baseline should be a disposable execution environment with no host mounts, no ambient credentials, and restricted network access. A container may be sufficient where the threat model permits a shared kernel. MicroVM isolation becomes much more attractive when generated code is genuinely untrusted or when workloads are multi-tenant.
Credentials should then be replaced wherever possible with short-lived, narrowly scoped capabilities. An agent that needs to read one repository should receive authority to read that repository, not an organization-wide token. An agent that needs to restart one service should not receive cluster administrator access.
Network access deserves the same treatment. Open internet access is convenient during development, but it creates a large exfiltration surface. Egress should be explicit, and sensitive operations should pass through controlled services rather than unrestricted sockets where practical.
Finally, the system needs independent telemetry. The security team should be able to reconstruct process creation, file access, network connections, tool calls, capability grants, and policy decisions without asking the model what happened.
The mistake is choosing one “sandbox”
Security architecture diagrams often contain a box labelled Sandbox as though that box represents a single security property.
For AI-generated code, it doesn't.
A container gives process isolation while sharing the host kernel. A microVM creates a stronger execution boundary but still depends on the kernel and virtualization stack. A capability system restricts authority but doesn't contain arbitrary code execution. Network policy controls destinations but doesn't determine whether the code itself is malicious. Observability shows behavior but doesn't prevent it.
Each control has a failure mode.
Vercel's sandbox research makes the virtualization problem concrete: even a carefully designed microVM architecture can inherit risk from the underlying kernel. Edera's capability model shows why isolation alone doesn't answer the authorization problem. AgentSight demonstrates the value of observing agent behavior from outside the application. Runtime action-control systems address another gap by deciding whether a legitimate tool invocation should actually proceed.
That is the architecture enterprises should be designing around.
What we see at 0xMetaLabs
AI-generated code is pushing sandboxing toward the same design principle that shaped mature cloud security: assume individual controls will fail, and make sure the next boundary still holds.
The question for an enterprise isn't simply whether to use containers or microVMs. It is where each security decision belongs. Execution isolation should sit below the agent. Authorization should sit outside the agent's reasoning. Credentials should be replaced with narrowly scoped authority where possible. Network policy should be enforced at a boundary the workload cannot modify. Telemetry should come from outside the agent itself.
That produces a more useful architecture than treating the sandbox as a product feature.
An AI agent should be free to generate code, experiment, install dependencies, run tests, and make mistakes inside a controlled execution environment. What it should not be free to decide is whether that environment's security boundaries apply to it.
The strongest agent runtime is therefore not the one with the biggest sandbox. It is the one where execution, authority, network access, and observation are separated into independent controls.
That separation becomes increasingly important as generated code moves from developer laptops into CI pipelines, cloud runtimes, and production systems.
The code may be generated by a model. The security boundary should not be.
