Deploying AI Agents Safely with Hardware Isolation
TL;DR: AI agents execute arbitrary code, which makes them fundamentally different from traditional applications. Containers share a kernel with the host and can be escaped. Hardware-level isolation on ZWRM gives each agent its own kernel, filesystem, and network, making it safe to let agents run freely in production.
AI agents are different from traditional applications. They don't just respond to requests — they take actions. They write code, call APIs, modify databases, and interact with external systems. That makes them incredibly powerful. But from a security perspective, it also makes them a fundamentally different problem.
If you're running AI agents in production (or are planning to do so) the question isn't whether to sandbox them. It's how.
The Agent Sandbox Problem
When an LLM-powered agent decides to execute code, that code needs to run somewhere. That could be your laptop, a Docker container, a cloud VM, your production server or an IoT device. But just because it could run everywhere doesn't mean it should.
Most developers and builders recognize the danger of running an AI agent directly on their local machine or production server. You're handing over system access to an autonomous process that generates code based on probabilistic models trained on internet data. That's not something you want running with full access to your filesystem, network, and credentials.
The instinctive answer is containers. Docker, gVisor, seccomp profiles ("let's put that agent in a box"). It's the right idea, but the box isn't as strong as you think.
Why Containers Aren't Enough
Containers provide process-level isolation. They use Linux namespaces and cgroups to limit what a process can see and do. But they all share one critical thing: the host kernel.
That shared kernel is the problem. Every container on a host makes system calls to the same kernel. A kernel exploit in one container compromises all of them, but even worse: the host as well. This isn't theoretical. Container escape vulnerabilities are discovered regularly (CVE-2024-21626, CVE-2019-5736, to name a few).
For a normal web application, this risk is manageable. The application runs known code that you wrote and reviewed. But an AI agent generates and executes unknown code at runtime. You literally don't know what it will do next. The attack surface is fundamentally larger.
Here's what can go wrong with container-only isolation:
| Scenario | Risk |
|---|---|
| Agent generates code that exploits a kernel vulnerability | Escapes the container, accesses the host and other workloads |
| Agent calls unexpected external APIs | Racks up costs, leaks sensitive data to third parties |
| Agent modifies shared filesystem or volumes | Corrupts data used by other applications |
| Agent spawns processes that consume all resources | Denial of service for everything else on the host |
Adding layers like seccomp profiles and AppArmor helps, but these are all kernel-level mechanisms. A single kernel exploit bypasses all of them simultaneously.
What Hardware Isolation Actually Means
Hardware isolation is a different approach entirely. Instead of isolating processes within a shared kernel, you give each workload its own kernel running in its own virtual machine.
This is what Firecracker does. Firecracker is an open-source virtual machine monitor built by Amazon to power AWS Lambda and Fargate. It starts lightweight VMs (called microVMs) in under 125 milliseconds with less than 5 MB of memory overhead. That's fast and light enough to use for individual workloads — including individual agent executions.
The key difference from containers:
| Containers | ZWRM MicroVMs | |
|---|---|---|
| Kernel | Shared with host | Own kernel per workload |
| Isolation boundary | Linux namespaces (software) | Hardware virtualization (KVM) |
| Escape impact | Access to host and all containers | Contained within the VM |
| Boot time | Sub-second | 1-5 seconds |
| Memory overhead | Minimal | ~20-30 MB per VM |
| Density | High | High (20-50 VMs per server) |
With a microVM, even if an agent generates code that exploits a vulnerability, it can only compromise its own VM. It has no path to the host kernel, no access to other VMs, and no shared resources to corrupt.
How ZWRM Isolates Agents
On ZWRM, every agent execution runs in its own Firecracker microVM. When you start an agent, the platform spins up a dedicated VM with:
- Its own kernel — the agent process never touches the host kernel
- Its own filesystem — no shared volumes, no accidental access to other workloads
- Its own network stack — fine-grained network policies control what the agent can reach
- Ephemeral by default — the VM is destroyed after execution, leaving no residual state
This isn't a feature you configure. It's the architecture. Every agent, every time.
This hardware isolation is the foundation, but ZWRM layers additional protections on top:
| Layer | What it does |
|---|---|
| Resource limits | CPU, memory, and network bandwidth caps per agent execution. No single agent can starve the host |
| Network policies | Allowlist which external APIs and endpoints an agent can reach. Everything else is blocked |
| Execution timeouts | Hard time limits per execution. No infinite loops, no runaway processes |
| Audit logging | Every action the agent takes is recorded and queryable. Full traceability |
These layers work together. Even if an agent finds a way around one control, the others still hold. And the microVM boundary underneath means the blast radius is always limited to that single execution.
What This Looks Like in Practice
Starting an isolated agent on ZWRM is one command:
zwrm agent claude my-project
No Docker configuration, no security profiles to write, no VM provisioning. The platform handles isolation, resource limits, networking, and cleanup automatically.
ZWRM agents are ephemeral at the VM level but persistent at the volume level. You create agents with their own context, environment, and secrets for each of your projects. When you work on a project, you spin up your dedicated agent and pick up right where you left off. When you're done, the VM is destroyed but your work persists on the attached volume.
This means you can run dozens of agents across different projects, each fully isolated from the others, each with their own dependencies and credentials, and none of them able to interfere with each other or with the host.
Why This Matters for Production
Most agent frameworks treat sandboxing as an afterthought. They run agent code in the same process, or at best in a Docker container. That works for demos and local development. It doesn't work when you're running agents in production against real data, for real customers, with real consequences.
The stakes are different in production:
- A data leak isn't a learning experience (it's a GDPR violation)
- A runaway process isn't an annoyance (it's downtime for your customers)
- A compromised host isn't a reimage (it's a security incident that affects every workload on that machine)
Agent infrastructure should be secure by default. You shouldn't have to think about isolation, configure security profiles, or hope that your container runtime catches every edge case. It should be there at the hardware level, every time an agent executes.
That's what Firecracker microVMs provide, and that's how ZWRM runs every agent.
Ready to run AI agents safely on your own infrastructure? Start a free 14-day trial at zwrm.eu.
