Notifications
Clear all
Topic starter
19/08/2026 4:04 pm
TL;DR: Coding agents need hardware-isolated microVMs, not just containers, because LLM-driven processes can read secrets, execute unsafe commands, and attempt exfiltration within minutes of receiving shell and network access, according to Stacklok. The core issue is blast-radius control: agent sessions must be isolated by kernel boundary, egress policy, and review gates before changes land.
NHIMG editorial — based on content published by Stacklok: Your AI agent doesn’t deserve root access
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Stacklok's analysis of isolated AI coding agents and microVM security →
AI coding agents in microVMs: are your controls keeping up?
Explore further
19/08/2026 4:38 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: AI coding agents need microVM isolation, not container trust
