Why AI Agents Need Stronger Sandboxing and What the Kata Containers Community Is Doing About It

If you want to understand where cloud-native security is heading in the age of AI agents, a recent OpenInfra Live panel discussion is a good place to start. The conversation brought together four engineers who think about this problem from very different vantage points: Xu Wang, founder of Kata Containers and vice chair of the Open Source Tech Committee at Ant Group; Janet Kuo, Kubernetes maintainer and SIG Apps lead at Google; and Zvonko Kaiser and Hema Bontha, both from NVIDIA’s cloud-native and enterprise product teams. The topic was agent sandboxing: what it is, why it matters, and what the open source community needs to build to get there.

What emerged was a detailed, technically grounded discussion of why AI agents break the assumptions that traditional container security was built on, and why hardware-virtualized isolation — specifically the kind that Kata Containers provides — is increasingly being pointed to as the right foundation for running agents safely on Kubernetes.

The Problem: AI Agents Break the Container Security Model

To understand why agent sandboxing is generating so much attention, you have to start with what makes AI agents fundamentally different from the workloads Kubernetes was originally built to run.

Traditional microservices are well-behaved, predictable tenants. They have static behavior: you know which database they connect to, which APIs they call, and what resources they consume. Container isolation was designed with this kind of workload in mind. AI agents are a different animal entirely.

“Microservices have a static profile: we know what they’re doing,” said Zvonko Kaiser. “But when you’re looking at agents, they have non-deterministic execution paths. Depending on what you’ve done with the agent in the past, it may change its behavior in the future… the unpredictability of what the LLM may do — including the effect of prompt injection — makes agent sandboxing a valuable solution to protect your valuable assets.”

The threat surface is substantial. Agents that execute LLM-generated code can run shell commands, access file systems, send messages, and call external APIs. They accumulate memory that shapes future decisions, a risk that Hema Bontha described in terms of what he called the “sleeping agent” problem: “It’s about being aware of a sleeping agent, memory persistence, and how that impacts the reasoning of how agents work in the future. That’s where the risk lies.”

And because agent behavior cannot be fully specified or predicted in advance, the security perimeter must be defined and enforced at the infrastructure level, not by the application itself.

The core vulnerability of traditional containers in this context is kernel sharing. When a container escapes its boundaries, it lands on the host kernel. From there, an attacker can move laterally across the cluster, enumerate workloads, and compromise the control plane. As Kaiser put it: “If it’s shared, it’s vulnerable…. The threat model is that we want to protect our precious infrastructure — and our other tenants that are running on the cluster — from a malicious workload.”

This risk isn’t purely theoretical, either. Kaiser pointed to the XZ backdoor incident as a reminder that even supply chain components you believe you trust can introduce malicious behavior. “You cannot control everything from the supply chain, from what’s going to be executed, what’s going to be side-loaded. Even if an LLM is just doing text summarization, it could do something through memory poisoning, through prompt injection, or side-loading of other things. I would say, independent of agent or MCP workloads, every workload running on infrastructure that you do not trust 100% — and there’s never 100% trust — you should run sandboxed.”

The Solution: Hardware-Virtualized Isolation

The panel converged on a clear architectural answer to these risks: hardware-virtualized sandboxing that provides a hard boundary between the agent and the host kernel. Kata Containers — the open source project that runs container workloads inside lightweight virtual machines — came up repeatedly as the right tool for the job.

Janet Kuo laid out the practical rationale: “For agents that have side effects — for example, when they need to run some generated code, or run some shell commands, or maybe interact with the network — they need strict sandboxing… Kata Containers doesn’t allow containers to share the host kernel. This provides a secure environment for agents to run.” She noted that not every agent requires this level of isolation — those doing pure text summarization or computation may be fine in standard containers — but that agents with real-world side effects need the stronger boundary.

Xu Wang, who has been building with Kata since co-founding the project in 2017, described the operational logic behind the approach: “The agent sandbox may run code that is written by the model… We cannot guarantee the security safety of the code, so we have to encapsulate the code inside a harder sandbox and isolate it from our infrastructure.” He drew an explicit analogy to the security posture applied to untrusted public cloud workloads: if you can’t vouch for the code, you treat it as untrusted by default, full stop.

Bontha highlighted two specific properties that make Kata particularly well-suited to agent workloads. The first is per-agent memory isolation: “The beauty of Kata-based sandboxing is that you get memory isolation per individual agent… any memory exposure — east, west, or how agents might compromise anything else running on the host — Kata cuts down that vulnerability significantly.” The second is zero persistence: “The way I think about agents is a short-lived deploy-execute-kill loop. With Kata, you allocate memory, run the agent, kill it, and clean up. You’re not leaving anything behind on the memory for another agent to pick up. You cannot build into a rogue tendency or insert something that can, in the long term, change the behavior of the host.”

Observability: You Can’t Trust What the Agent Reports About Itself

One of the more nuanced parts of the discussion concerned logging and observability and why getting this right is harder than it sounds.

The instinct might be to capture as much telemetry as possible from running agents. But Kaiser raised an important caveat: “Can we really rely on the agent that’s running in a sandbox to truthfully expose what it’s really doing? Any telemetry, any logging that you’re getting — you’re trusting the agent to give you the right logging… We need to make sure that the logging you’re getting is really what you’re expecting from the agent. This needs more work than just scraping all the logs and telemetry from an agent.”

Kuo described how the Kubernetes Agent Sandbox project approaches this: by keeping the observability infrastructure entirely out of band. “Because the agents’ output is unpredictable and untrusted, the logging infrastructure should be completely out of band. In the Agent Sandbox project, we have integration with OpenTelemetry for distributed tracing, so we can monitor the lifecycle and operations of the sandbox from the outside. We’re not looking at the agent’s isolated memory space.”

Bontha connected sandboxing and out-of-band logging as complementary requirements: “When you look at auditability and responsibility — let’s say an agent is running and an incident happens — how do you bring back the auditability to find the accountability? The combination of sandboxing the agent and having an out-of-band mechanism to log gives you the ability to validate, audit, and introspect what the agentic behavior has been and how it led to the end state. Sandboxing and logging go hand in hand.”

The Next Layer: Confidential Computing for Private Data

The panel’s discussion took an important turn when an audience member asked: how do you give an agent access to private data when it’s running in a sandbox?

Kaiser’s answer reframed the problem: “Kata-based sandboxing still leaves the infrastructure owner or other tenants the possibility to scrape via memory. Nothing is protected in memory…. The next step is to use confidential compute and confidential containers. Confidential containers use Kata as the base. Only with confidential compute do you get the guarantees that the data during runtime is encrypted and not accessible by the infrastructure or by other tenants…. The real, bigger problem is how we are protecting confidential data and how we are doing agent inferencing and other AI tasks on private data.”

This inverts the threat model. Where sandbox isolation says “we don’t trust the workload,” confidential computing says “we don’t trust the infrastructure.” Kaiser cited a Google study showing that more than 50% of companies leave over 66% of their private data unused for AI workloads because they cannot guarantee proper isolation and confidentiality. That is a significant barrier to enterprise AI adoption and one that confidential containers are specifically designed to remove.

Bontha described the combined value proposition: “Confidential computing is all about protecting your privacy, protecting your data in use. The combination of isolation from Kata, the encryption of memory provided by confidential compute support, and the private data that enterprises are sitting on — that combination has a lot of prospect, especially for where agentic AI is heading.”

Kaiser, who serves on both the architecture committee for Kata and the Technical Steering Committee for confidential containers, made the case for why open source is foundational to making any of these security guarantees trustworthy: “My belief is you cannot do confidential compute without open source. If you have any binary blobs… the provider will attest that the functionality will be provided, but how do you know what’s really happening inside? The complete stack needs to be open source… Even if it’s open source, you need reproducible builds… be it supply chain provenance, SBOMs — all the guarantees that someone is providing need to be open source and validated.”

What the Open Source Community Needs to Build

The conversation closed with each panelist’s view on where the open source community should focus to keep pace with the agent era.

Wang called for continued investment in both isolation strength and operational efficiency: “We have to enhance the security and isolation for these workloads… but not only the security — it also needs to be efficient and affordable. Agent sandboxing needs to work for most workloads.”

Kuo pointed to orchestration as the next frontier: “I’m starting to see more and more people doing multiple agents, running agents for a long time, with agents talking to each other. We need orchestration, and I think Kubernetes is the perfect tool for this. But as more and more people use those powerful agents, we need to think about how to make it secure, and we cannot just rely on users knowing how to make their agents secure. We should provide the right isolation to make it easy to run agents in a secure way.” Kuo is also leading the Kubernetes AI conformance program at the CNCF, which establishes platform standards — including DRA support, accelerator metrics, observability, and scheduling primitives — for reliably running AI workloads across environments.

Bontha focused on attestation as the community priority that underpins everything else: “When agents are in play, confidential computing becomes a more primitive requirement. The focus on how we can do attestation — and how we can potentially attest the state of an agent — is a requirement of some sort… My main focus is how do we support inference clouds, what level of attestation and guardrailing is required to make that seamless, and investing in those areas.”

Kaiser brought it back to first principles and issued a pointed warning for the open source community itself: “Everything needs to be attested: your logs, your supply chain, your workload, your hardware. You need a full chain of trust from silicon to service. If one component in that chain is not providing the cryptographic evidence you need, your complete chain is broken.” He added that the rise of AI-assisted coding makes rigorous code review more important, not less: “With all the agents and vibe coding happening right now, we need to be more resilient and rigorous on code review and what we are letting into the code repositories. We need to be vigilant, especially in open source, because anyone can contribute code.”

The full OpenInfra Live panel discussion including audience Q&A on GPU memory isolation, confidential data access, and the Kubernetes AI conformance program is available on YouTube: OpenInfra Live: AI Agent Sandboxes: Securing Memory, GPUs, and Model Access.

Tags: Agent sandboxing, AI, Kata Containers, Kubernetes