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.
Editorial analysis by NHI Mgmt Group, based on content published by Stacklok: “Your AI agent doesn’t deserve root access”.
Key questions
Q: What breaks when AI coding agents are allowed to run in shared container environments?
A: Shared containers break down because the agent still relies on the host kernel, so a runtime flaw, privilege error, or escape can affect the entire system.
Q: Why do AI coding agents with shell and network access create higher exfiltration risk?
A: They can be influenced by repository content, fetched instructions, or prompt injection, then use their delegated access to read local files and open outbound connections.
Q: What do teams get wrong about security inside coding agents?
A: They often assume placing a scanner or policy bot inside the agent makes the experience developer-first.
Practitioner guidance
- Isolate coding agents in hardware-backed microVMs Run agent sessions inside disposable microVMs with a separate guest kernel so a container escape does not become host compromise.
- Keep secrets out of the agent boundary Do not mount .env files, credential stores, or other sensitive workspace material into the agent session, and use exclusion rules before the VM starts.
- Enforce default-deny outbound network access Allow only the specific destinations the agent needs and block everything else at a layer below the agent so prompt injection cannot drive exfiltration.
Bottom line: AI coding agents are high-risk delegated actors, not benign assistants, because they can read files, run commands, and reach external services in the same session.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:38 pm
AI coding agents are becoming non-human identities with delegated execution, not just developer productivity tools. Once a model can read files, run commands, and act on network inputs, it needs identity-style containment: bounded privilege, scoped tool access, and a session model that assumes compromise is possible. The governance mistake is to treat the agent like a helper script instead of a runtime actor. Practitioners should govern these systems as high-risk non-human identities.
A few things that frame the scale:
- Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: Should organisations prioritize microVM isolation or review gates for coding agents first?
A: If agents can execute code with access to secrets or network paths, microVM isolation comes first because it constrains the compromise domain immediately. Review gates still matter, but they do not stop runtime exfiltration or destructive commands during the session. The safest sequence is confinement first, then promotion control.
👉 Read our full editorial: AI coding agents need microVM isolation, not container trust