An AI coding agent needed just two lines to break a developer's trust, exposing a question now pressing every enterprise: can containers contain AI agents? The agent quietly changed an environment variable, the hidden settings that tell programs how to behave, so Git would launch an attacker's code whenever a routine command ran. No warning appeared on screen.
Then the agent ran git branch, a harmless command the developer approved. Git read the poisoned variable and ran the attacker's code instead.
CVE-2026-22708, the tracking number for a critical flaw Pillar Security found in the AI coding tool Cursor earlier this year, seemed serious enough to start finger-pointing. But no one did anything wrong. The developer approved a harmless command. The agent followed its instructions. The system got hijacked anyway.
As AI agents take on more autonomy and access to sensitive data, the container isolation that served traditional applications is showing its limits. Enterprises now face a sliding scale of protection, from hardened runtimes to sandboxes to microVMs, each matched to an agent's risk profile.
A few years ago, such agentic AI security issues seemed so far off that few CISOs gave them much thought. Now, 48% of IT security professionals call agentic AI the single most dangerous attack vector they face, according to a Dark Reading survey. And 88% of IT teams believe they've had an AI agent security incident in the past year, a Gravitee survey found.
Since AI agents are used so heavily by software developers and engineers, and because agents, by definition, go about their business with little to no human involvement, a natural place to begin securing them would be with containers, executable units of software that package applications with all their dependencies. They can be configured to restrict what a process can touch, which files it can read, which network destinations it can reach and whether it can talk to the host machine. In fact, 46% of executives surveyed in Nutanix's 2026 Enterprise Cloud Index (ECI) cited data security as a key driver of increased container adoption in their organizations.
But enterprises can't deploy containers the same way they did before generative AI went mainstream in late 2022, according to Paul Nashawaty, principal analyst at SiliconANGLE and Efficiently Connected, Inc. At least not if they want to keep their agents secure, because a container's rules get written before the app ever runs, whereas an agent decides what to do while it's running.
While using containers is a viable way to help secure AI agents, Nashawaty says organizations will need to update their approaches.
"The market still defaults to containers and existing cloud-native/Kubernetes infrastructure because agents are being deployed as applications and platform teams already have those operating models," he told The Forecast, referring to Kubernetes, the system many companies use to manage large groups of containers at once.
"But the conversation changes when an agent is executing untrusted code, handling sensitive information, or has meaningful production privileges."
Analysts say that will require deploying containers with stronger isolation protection, including hardened runtimes, sandboxing and eventually microVMs (micro virtual machines). At the same time, it will require getting platform and IT security teams on the same page to get ahead of agent IT threats.
"Platform teams naturally own where and how agents run while security teams care about things like identity, permissions, policy and containment," Nashawaty said. "The organizations making progress seem to be bringing those responsibilities together."
How Can Teams Harden Container Runtimes?
Hardening the container runtime, the software layer that starts and manages containers, is where platform and security teams can first put shared responsibility into practice. Container security for AI agents is the practice of isolating autonomous AI workloads using hardened runtimes, sandboxes or microVMs to limit what an agent can reach, from files and credentials to network destinations and host systems.
Eilon Cohen, head of security research at Pillar Security, said standard containers can still work for lower-risk agents.
"Standard containers remain attractive because they fit existing Kubernetes workflows, start quickly, and are operationally familiar," Cohen told The Forecast. "They can be appropriate when the workload is trusted, credentials are tightly scoped, egress (digital traffic leaving a system) is constrained, and the consequence of a boundary failure is limited."
But as AI agents gain more autonomy, greater access to regulated or sensitive data, the ability to execute arbitrary code or broader production permissions, organizations "will introduce stronger isolation and more granular controls," Nashawaty said.
Cohen pointed to gVisor as one example. It's a user-space kernel that intercepts system calls from a container before they reach the host kernel, adding another layer of isolation without spinning up a separate virtual machine (VM) for each workload. He explained that a VM is a digital environment that runs on a physical server but operates as its own computer system.
What Do Security Sandboxes Actually Protect?
Security sandboxes control what untrusted code can reach once it runs, but they often draw the boundary around the container rather than around everything the agent can influence.
Runtime tools such as gVisor strengthen the barrier between a container and the host operating system. Security sandboxes focus on controlling what untrusted code can reach once it runs, placing that code in an isolated environment with restricted access to files, services and other resources. Agents can still influence software outside that environment.
In Pillar Security tests, for example, AI agents stayed inside their sandbox yet reached Docker Desktop, a common app for building and running containers, and used it to launch a privileged container with access to the user's home directory.
"They draw the security boundary around the container rather than around everything the agent can influence," Cohen said.
"Underneath a well-configured container may still be mounted credentials, writable workspaces, broad network access, internal APIs, privileged services, and automation that executes files the agent creates."
Cohn explained that a stronger sandbox design draws the security boundary around the agent's full reach, including the credentials, workspaces, network connections, internal services and automation it can influence. For higher-risk agents, he said teams are increasingly using VM-backed sandboxes, which use a virtual machine as the isolation boundary.
When Are microVMs Worth the Overhead?
MicroVMs give a workload its own operating-system kernel rather than sharing the host's, providing a tighter boundary for agents that need stronger isolation than a sandbox alone can provide. Some agents need a harder boundary than a sandbox alone can provide. MicroVMs, which, as the name implies, are lightweight VMs, give a workload its own operating-system kernel instead of sharing the host computer's.
Jim Mercer, program vice president for Software Development, DevOps & DevSecOps at IDC, points to Kata Containers, an open-source project that runs containers inside their own lightweight virtual machines rather than directly on the shared host kernel.
"Generally speaking, microVMs provide stronger security isolation for running AI agents than standard containers," he told The Forecast.
Cohen said the Cursor flaw shows what extra separation can buy. Malicious code could still run inside the microVM, he said, but it could be kept away from a private-key file stored on the host and prevented from modifying host configuration. The protection depends on those resources not being mounted or otherwise exposed to the microVM. Teams could also restrict its ability to send data over the network. Credentials deliberately passed into the microVM and shared work folders would remain within the agent's reach.
A microVM containing production credentials and unrestricted network access can still have a larger blast radius than a carefully constrained container, Cohen said. Teams must limit the credentials, data, network connections and tools placed inside it as well.
Where Is Agent Isolation Headed?
Enterprises will likely use isolation methods on a sliding scale, matching the protection to an agent's job, access and potential blast radius.
Mercer expects lower-risk agents to remain in conventional containers. Nashawaty believes that curve will keep bending toward tighter isolation as agents take on more autonomy and access.
Cohen envisions a similar progression: conventional containers for lower-risk agents, hardened container software for agents running less-trusted code, and short-lived microVMs or VM-backed sandboxes for agents with broad permissions or those serving multiple users.
Across those levels, he expects to see temporary credentials unique to each run, tight limits on outbound network traffic, access to as few host files as possible, permissions for individual sensitive actions, detailed activity logs and a kill switch that operates outside of the agent itself.
"The container, microVM or VM is one layer," Cohen said. "The real security boundary is the agent's complete reachable environment."
Related:
- Bridging the Agentic AI Governance & Trust Gap
- AI Gateway to Protect Data and Enable Innovation
- Cloud Native Finds Its Moment in AI
- Kubernetes Grew Up Just in Time for AI, Says Analyst Steven Dickens
- Containers Progress in a World of Data Center Virtualization
- Game Hosting Companies Unsheathe AI and Cloud Native Tools to Combat Cheaters and Cyberattacks
- EVE Online Devs Plot Course for MMO’s Cloud Native Future
Editor’s note: Learn about Nutanix Enterprise AI (NAI) 2.8, and the upcoming general availability of Nutanix Kubernetes Platform (NKP) 2.19, along with new incentives, programs, and resources designed to help partners accelerate growth on emerging AI opportunities in this press release: Nutanix Gives Enterprises the Freedom to Run Production Agentic AI Their Way.
David Rand is a business and technology reporter whose work has appeared in major publications around the world. He specializes in spotting and digging into what’s coming next–and helping executives in organizations of all sizes know what to do about it.
© 2026 Nutanix, Inc. All rights reserved. For additional information and important legal disclaimers, please go here.
Related Articles
