For teams running AI agents in production on Kubernetes, what security boundary do you put between agents and between an agent and the host? Regular pods provide namespaces, RBAC, and network controls, but the agent's next action may come from a model, tool output, or untrusted web content. That makes the shared kernel a concern, especially in multi-agent workflows where a compromised planner, researcher, or executor could potentially access another agent's files or credentials. We currently use a microVM per agent with Kata so each workload gets its own kernel. I'm curious whether others are using gVisor, Kata, Firecracker, sandboxed runtimes, virtual clusters, or only namespaces and policy controls. How much startup time and resource overhead would you accept for VM-level isolation?
5 Answers
There are now several agent-sandbox platforms that let you choose between backends such as gVisor and Kata. That can be useful if different agents have different performance and compatibility requirements instead of forcing every workload into the same isolation model. A hardened, read-only base image with controlled package installation is another worthwhile layer.
For workloads that genuinely need filesystem access or arbitrary commands, we’ve had better results with Kata or Firecracker-style microVMs than with namespaces alone. gVisor can work, but some agent tooling that uses the filesystem heavily ran into syscall compatibility issues. With a warm pool and a tuned snapshotter, microVM startup can be brought down to roughly a second, which is acceptable for our workloads.
Some teams are solving this by reducing the need for a freely roaming OS in the first place. Keep agents short-lived when possible, expose code execution and outbound requests through narrowly scoped tools, and route requests using an ID rather than giving every agent broad access to shared state. For multi-agent communication, explicitly define the channels and permissions instead of letting agents discover each other through the cluster.
That distinction is useful. The planner and researcher may not need the same privileges as the executor, so isolating by capability could be as important as isolating by process.
A basic setup can be separate namespaces, dedicated service accounts, RBAC, network policies, and possibly a service mesh, but I would not treat that as equivalent to a kernel boundary. Namespaces and policies limit ordinary access; they do not provide the same protection against a hostile or compromised workload. For higher-risk agents, combining those controls with a sandboxed runtime or microVM gives a more convincing defense-in-depth design.
A layered approach seems more practical than relying on one boundary. Use strict RBAC and service accounts, default-deny network policies, separate namespaces where useful, and keep credentials out of the agent itself. The tools should hold credentials and enforce deterministic access rules. If the agent needs to execute code, expose that as an ephemeral tool with no access to the host or unrelated workloads.
That’s a good point about making the agents themselves less powerful. We’ve been treating the microVM as the main boundary, but reducing what the agent can do inside it would lower the impact of a breakout or prompt injection.
The tradeoff depends on the workload. Lightweight, short-lived tools may fit a thinner sandbox, while agents that need a fuller OS environment are better candidates for a microVM. Checkpointing and image size can also become important operational concerns.