The shift toward autonomous AI agents running arbitrary, unreviewed code in production environments has ultimately forced the security community to confront the harsh reality that our traditional container abstractions are wholly inadequate for untrusted code execution. What began as a debate over container security boundaries (like standard egress firewall rules or admission control policies) have since culminated in a decisive industry consensus around microVMs and hardware-assisted isolation. I was reading Matt Moore’s brilliantly-detailed account of how Chainguard are sandboxing their very own Athena zero-day patching agent, which really proves that there is an ongoing industry shift.
For the more than decade of cloud native computing that we've had the pleasure of enjoying, seemingly the entire industry agreed that Linux cgroups and namespaces were all that was needed for container separation in Kubernetes. A sort of fake isolation layer, celebrating the lightweight efficiency of Docker containers. However, security-focused engineers quickly learned the core lesson that containers share a single Linux kernel, meaning any kernel exploit results in a total host escape. To address this "containers don't contain" problem, the first generation of microVMs emerged, led by projects like AWS Firecracker and Kata Containers. These lightweight VMs essentially stripped away legacy PCI devices and bloated BIOS layers, leveraging Linux KVM to boot secure, single-purpose virtual environments in milliseconds rather than minutes. This was a HUGE improvement.
Chainguard’s workflow builds directly on this pragmatic, battle-tested KVM lineage. As Moore explained in his blog, Chainguard approaches isolation not as a proprietary runtime or a customised hypervisor, but rather as a flexible, standardised microVM contract. In development, Chainguard appears to utilise a single local QEMU/KVM process. Whereas, in production, it offloads workloads to an elastic, multi-tenant Kubernetes backend. Rather than attempting to replace Linux or rewrite the hypervisor layer, Chainguard blog discusses accepting standard KVM virtualisation before wrapping it in strict defensive controls like an external gVisor-based networking stack that enforces a sort of "destroy on first violation" policies. The Chainguard process also achieves synthetic identity generation to eliminate ambient creds, as well as minimal, ephemeral root filesystems built from scratch for every execution. For sensitive workloads like Athena (which handles working exploits for undisclosed zero-days) Chainguard chooses to rely on tightly restricted egress, continuous adversarial regression testing, and an immediate tear-down posture upon any policy violation.
Edera also takes a somewhat different path to securing these unpredictable AI agents by targeting the hypervisor layer itself. Edera built their Rust-based Krata orchestration engine around a stripped-down, Type-1 Xen hypervisor to eradicate memory-safety bugs (because it was rewritten in Rust). Edera’s argument is rooted in minimising the TCB. Their KVM lives inside the massive, complex Linux kernel, meaning any vulnerability in that host kernel potentially threatens the hypervisor boundary. By leveraging a Type-1 microkernel approach with Xen, Edera are isolating each AI workload into their own Zones with a dedicated guest kernel, removing the shared host kernel from the security perimeter entirely. Even as Edera has expanded its platform to support KVM backends for organisations restricted to standard Linux kernel virtualisation, the core philosophy remains focused on deep, architectural platform isolation at the hypervisor level.
These evolving, and again, distinct philosophical engineering philosophies are illustrating how the insecure AI workloads need to be run in a new, secure-by-default sandbox. Chainguard are rightfully treating the hypervisor as a interchangeable utility commodity, putting their large engineering effort into upper-layer guardrails such as network proxies, credential stripping, minimal package trees, as well as strict policy enforcement engines. Chainguard process cares less about whether KVM has a larger attack surface than Xen, and more about ensuring that even if an attacker compromises the guest kernel, they land in a completely inert container with no credentials, no local storage, and a network layer that immediately terminates the instance at the first unauthorised DNS query. Whereas, Edera, by contrast, are focusing on the substrate itself, re-architecting hypervisor memory safety, domain boundaries, and driver isolation to ensure the underlying platform is inherently immune to hypervisor escapes.
Ultimately, both approaches appear to be providing powerful validation for the absolute necessity of microVMs in modern software security - especially in light of the recent OpenAI, Anthropic, Meta sandbox escape incidents. The arrival of AI agents, which generate, iterate, and execute non-deterministic code without human review have elevated the so-called RCE-as-a-Service threat model from a super niche problem specific to pipeline providers to growing baseline requirement for secure software development. The cloud-native ecosystem has collectively acknowledged that shared-kernel containers are insufficient for untrusted execution. Strong hardware boundaries, dedicated kernels, and ephemeral microVMs are quickly becoming the mandatory foundation for building and running autonomous software safely.