AI coding agents need microVM isolation, not container trust

At a glance

What this is: This is a Stacklok analysis of why AI coding agents need microVM isolation, showing that containers alone do not contain the risk from shell access, network access, or prompt injection.

Why it matters: It matters to IAM, PAM, and NHI practitioners because coding agents behave like privileged non-human identities, so access scope, secret exposure, and outbound reach need governance beyond conventional workload controls.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Stacklok's analysis of isolated AI coding agents and microVM security

Context

AI coding agents create a governance problem because they combine shell access, network reach, and tool invocation in a runtime that can be influenced by untrusted inputs. In identity terms, that makes them a form of non-human identity that may hold secrets, act with delegated privilege, and trigger downstream changes without the guardrails usually expected for human users.

The article argues that containers do not provide a strong enough boundary for this class of workload because they share a kernel with the host. For practitioners, the key question is not whether the agent can be useful, but whether its access can be confined to a disposable environment that prevents secret exposure, limits egress, and forces review before changes persist.

Key questions

Q: How should security teams run AI coding agents without exposing the host?

A: Security teams should run AI coding agents inside hardware-isolated environments that separate the guest kernel from the host, then layer in default-deny network controls and secret exclusion. The goal is not to trust the agent, but to make unsafe behaviour fail inside a disposable boundary rather than reaching the workstation or production workspace.

Q: Why do AI agents create a governance problem for IAM teams?

A: AI agents create a governance problem because they authenticate and act as autonomous software entities with tool access. If their actions are logged only as application activity, teams lose accountability, context, and revocation clarity. IAM must therefore extend to agent identity, delegated authority, and control-plane audit trails.

Q: What breaks when containers are used alone for untrusted agent workloads?

A: Containers break down as a trust boundary because they share the host kernel and can be escaped through runtime flaws, privileged configuration, or kernel vulnerabilities. For untrusted agent workloads, that means a single bad command or malicious input can turn into host-level compromise instead of staying in a contained session.

Q: How do teams keep an AI agent from exfiltrating secrets or code?

A: Teams should combine secret exclusion with network controls that operate below the application layer, so the agent cannot read sensitive material or reach arbitrary destinations. If the agent can only resolve approved hostnames and never sees tokens or SSH keys, prompt injection becomes much harder to turn into exfiltration.

Technical breakdown

Why containers are a weak boundary for AI coding agents

Containers isolate processes, filesystems, and resources, but they still rely on the host kernel. That means a kernel flaw, a runtime escape path, or a privileged container can collapse the boundary for every workload sharing that host. For AI coding agents, the risk is amplified because the agent can be induced to fetch, install, execute, or transform untrusted material during normal use. The result is that a single unsafe command can turn into host-level exposure instead of remaining inside a disposable session.

Practical implication: treat container-only isolation as insufficient for agents that can run arbitrary code or touch sensitive workspace data.

How microVMs change the isolation model for LLM-driven processes

MicroVMs add a separate guest kernel behind a hardware boundary, which materially changes the attack surface. If the agent gains root inside the guest, it still has to cross the hypervisor layer to reach the host, which is a much harder problem than escaping a container namespace. In this design, the microVM becomes the unit of trust for runtime execution. That matters for agentic workloads because the boundary needs to survive malformed commands, prompt injection, and unsafe package installation without depending on the agent's judgment.

Practical implication: use hardware-isolated execution for any AI agent that can install packages, run tests, or manipulate source files.

Why network and secret controls must sit below the application layer

The article's architecture shows that isolation is not just about compute. Hostname-level egress control, DNS enforcement, secret exclusion, and review gating are the controls that stop agent misuse from becoming exfiltration or persistence. If the agent can read .env files, resolve arbitrary domains, or call tools without policy, then the runtime remains a privilege escalation path even inside a VM. Effective containment requires controls the agent cannot modify from inside its own session.

Practical implication: pair microVM isolation with non-overridable secret blocking, default-deny egress, and post-session change review.

Threat narrative

Attacker objective: The attacker objective is to turn a trusted coding assistant into a path for secret theft, command execution, or destructive workspace modification.

1. Entry occurs when the AI coding agent receives shell access, workspace access, and a network connection inside a development workflow.
2. Escalation follows when the agent is prompt-injected or otherwise steered into reading secrets, installing untrusted packages, or running unsafe commands.
3. Impact occurs when those actions lead to secret exposure, unauthorized outbound requests, or destructive changes in the real workspace.

NHI Mgmt Group analysis

AI coding agents are becoming privileged non-human identities. Once an agent can read workspace files, run commands, and reach external services, it behaves like a governed identity rather than a simple automation script. That means IAM and PAM teams should think in terms of access scope, tool authorization, and session containment rather than developer convenience. The practitioner conclusion is straightforward: agent runtime access needs identity-grade governance.

Container isolation is the wrong trust boundary for agentic code execution. A shared-kernel model assumes the kernel remains trustworthy under stress, which is a weak assumption for untrusted or prompt-influenced workloads. Hardware-isolated microVMs shift the control point to a stronger boundary and reduce the likelihood that one unsafe command becomes host compromise. The practitioner conclusion is to re-evaluate where ephemeral developer workloads actually terminate.

Blast-radius control is the correct design principle for AI coding environments. The most useful named concept here is agent blast-radius containment: constraining what an agent can see, reach, and persist even when it behaves unexpectedly. That concept spans identity, network, and change-control layers, which is why it maps well to NIST CSF and Zero Trust thinking. The practitioner conclusion is to design for failure containment, not agent reliability.

Secret exposure and outbound reach must be governed as one control plane. If a coding agent can see secrets and exfiltrate to arbitrary destinations, the isolation story fails regardless of whether the code runs in a VM or container. The article's architecture correctly treats secret exclusions, DNS-level egress filtering, and review gates as a single safety system. The practitioner conclusion is to align secret governance with runtime enforcement, not treat them as separate programmes.

AI agent governance and NHI governance are converging operationally. Coding agents now sit at the intersection of delegated credentials, tool invocation, and autonomous runtime behaviour, which makes them materially different from ordinary application services. That intersection means identity teams should expect agent policy, workload identity, and secrets management to converge in the same operating model. The practitioner conclusion is to plan for shared governance across human, machine, and agent identities.

What this signals

Agent blast-radius containment: organisations are moving toward an operating model where the key question is not whether an agent can act, but how far any mistake can travel. That pushes identity teams toward short-lived sessions, strict tool authorization, and network controls that cannot be overridden from inside the agent runtime.

The governance lesson is broader than AI engineering. Once an agent can consume credentials and change code, it needs controls that look much closer to privileged access management than to ordinary application guardrails. Teams should expect policy, review, and revocation to become part of the same control chain.

MicroVM-based isolation will increasingly serve as the reference pattern for high-trust agent execution because it aligns with Zero Trust principles and reduces host dependency. Practitioners should watch for tighter integration between workload identity, secret handling, and session-level containment in development platforms.

For practitioners

• Implement hardware-isolated agent runtimes Move AI coding agents that can run shell commands into microVMs or equivalent hardware-isolated execution so host compromise is no longer the default failure mode.
• Block secrets from agent sessions Prevent .env files, long-lived tokens, SSH material, and other sensitive credentials from entering the agent workspace at all, rather than relying on post-use cleanup.
• Enforce default-deny egress for agent tools Require hostname-based outbound filtering below the application layer so prompt-injected agents cannot resolve or call attacker-controlled infrastructure.
• Add review gates before workspace changes land Treat every agent session as disposable and require per-file review, hash re-verification, and explicit acceptance before changes are written back to the real repository.
• Classify agents as governed non-human identities Assign ownership, scope, and approval rules to coding agents the same way you would for privileged service accounts or other high-risk non-human identities.

Key takeaways

• AI coding agents should be treated as governed non-human identities because their runtime access can reach secrets, tools, and source code.
• Container-only isolation does not contain the blast radius of prompt-influenced execution because it leaves the host kernel in scope.
• Hardware isolation, secret exclusion, default-deny egress, and change review work together as one containment model for agentic development.

Key terms

• MicroVM: A microVM is a lightweight virtual machine that provides hardware-backed isolation with a much smaller footprint than a traditional VM. In this context it gives an AI agent its own guest kernel, which is a stronger containment boundary than a container because host kernel compromise is no longer the default failure mode.
• Containment blast radius: The scope of disruption created by a security response action. In AI-driven operations, the concern is that an automated containment step can isolate more assets, interrupt more services, or remove more telemetry than intended if its boundaries are not explicitly defined.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Default-Deny Egress: Default-deny egress means outbound network traffic is blocked unless it is explicitly allowed by policy. For agentic workloads, this stops prompt-injected or compromised processes from contacting attacker-controlled hosts, even if the code inside the session is otherwise able to run normally.

What's in the full article

Stacklok's full blog post covers the implementation detail this post intentionally leaves at the architecture level:

• Step-by-step microVM setup flow for running a coding agent in a disposable Linux environment
• The egress policy mechanics that block non-approved hostnames and hardcoded IP exfiltration paths
• How the MCP tool authorization layer is constrained for agent sessions
• The workspace review workflow that re-verifies changes before they land in the real repository

👉 The full Stacklok post covers the microVM stack, network controls, and change-review flow in implementation detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and human identity lifecycle controls. It helps practitioners build the control model needed to govern privileged non-human access across modern security programmes.