Zero trust for AI agents in VMs: why identity must follow

At a glance

What this is: This analysis argues that VM isolation is not enough for AI agents when identity-based access controls are missing.

Why it matters: It matters because practitioners need to govern AI agent access by identity and context, not by network location alone, or they will leave over-permissioned paths, audit gaps and leakage risks in place.

Context

Virtual machines can separate AI agents from production systems, but they do not automatically control what those agents can reach once they are running. The governance gap is simple: a workload can be isolated at the infrastructure layer and still be over-trusted at the identity layer.

For AI agents, the relevant question is not whether the VM is fenced off, but whether every connection to data, APIs, model repositories and dashboards is authorised with the same discipline used for any other non-human identity. Without that, the VM becomes a container for weak trust, not a secure sandbox.

That makes this a workload identity and zero trust problem as much as a deployment model question. The article treats VMs as the starting point for safer experimentation, but the controlling issue is how access is issued, evaluated and constrained inside the VM.

Key questions

Q: What breaks when AI agents in VMs still rely on static trust and shared credentials?

A: VM isolation stops at the host boundary, but AI agents still need identity to reach APIs, data sources and external services. When those permissions come from shared secrets or broad network trust, the environment looks segmented while the workload remains overpowered. The result is weak accountability, lateral movement potential and data exposure from a system that appeared contained.

Q: Why do virtual machines not solve AI agent access risk on their own?

A: Because isolation does not remove the need for credentials, tokens, or service permissions. If those identities are broad, static, or shared, the AI agent can still overreach, move laterally, or leak data even while confined to a separate host.

Q: How should teams secure AI agents running inside virtual machines?

A: Treat the VM as a place to run the workload, not a trust boundary. Secure the agent with identity-based authorisation, discrete credentials, and continuous policy evaluation for every API, data source, and outbound endpoint it can reach. If the VM can access more than the task requires, the environment is overexposed.

Q: What is the difference between VM isolation and zero trust for AI agents?

A: VM isolation separates workloads from the host and other systems, while zero trust evaluates every access request on identity, context and entitlement. For AI agents, that difference matters because the workload can still reach data and services from inside the VM. Zero trust controls the request path, not just the environment boundary.

Technical breakdown

Why VM isolation does not equal access control

A virtual machine isolates compute resources, not trust relationships. AI agents inside the VM still need to call APIs, read data, query repositories and sometimes trigger external actions. If those connections are governed by shared credentials, static rules or broad network permissions, the workload behaves as if it sits inside a flat trusted zone even when the underlying host is segmented. That is the core weakness: perimeter and segmentation controls reduce blast radius, but they do not prove which identity is making each request or whether the request should be allowed in context.

Practical implication: treat the VM as an execution boundary, not an authorisation boundary.

Identity-based access for headless AI workloads

Headless AI workloads need machine-enforced identity controls because they cannot rely on interactive user approval. In practical terms, that means workload-level authentication, entitlement-based access and continuous policy evaluation for each connection the agent makes. Zero trust for this use case is not about placing the VM on a trusted subnet. It is about making every request prove who or what is asking, what it is allowed to reach and whether context still justifies the access. That is why static credentials and broad service permissions are such a poor fit for agentic workloads.

Practical implication: bind agent access to identity, context and explicit entitlements rather than host location.

Why outbound control matters as much as inbound control

The article’s real operational concern is not only who can reach the agent, but what the agent can reach from inside the VM. Once an AI agent has outbound network reach, it can exfiltrate data, call unapproved services or expand into adjacent systems if the access policy is too loose. This is where zero trust becomes more than a perimeter model: it constrains both ingress and egress at the identity layer. For AI agents, that prevents the VM from becoming a launchpad for uncontrolled API use or data leakage.

Practical implication: enforce outbound policy for AI agents with the same rigor as inbound access.

Threat narrative

Attacker objective: The attacker objective is to turn an apparently isolated AI workload into a trusted pivot for unauthorized access and data leakage.

1. The entry condition is legitimate deployment of an AI agent inside a VM that appears isolated but still has access to APIs, data sources and dashboards.
2. Credential or access abuse occurs when the agent relies on static credentials, shared secrets or broad permissions that outlast the task it is trying to perform.
3. Escalation happens when the compromised or over-trusted VM can move laterally, reach unintended services or leak data through permitted connections.
4. The impact is unauthorized access, lateral movement and data exposure across workloads that operators assumed were safely separated.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

VM isolation is a boundary control, not a trust model. Virtual machines reduce blast radius, but they do not answer the identity question that matters for AI agents: who or what is authorised to act, and under what context. When access is still granted through static secrets and broad network trust, the VM only relocates the problem. Practitioners should treat identity governance as the control plane, not the host boundary.

Workload identity is the missing layer in most AI sandbox designs. AI agents do not become safe because they run in a separate machine. They become governable when access is tied to authenticated workload identity, explicit entitlements and context-aware policy. That moves security from environment trust to request trust, which is the only model that scales when autonomous workloads are allowed to act.

Identity must follow the workload because network location no longer describes risk. The traditional assumption that internal equals trusted fails for AI agents in VMs because the agent can still call external services, reach sensitive data and act at machine speed. This is a classic zero trust problem for non-human identity, and the practitioner conclusion is straightforward: govern the caller, not the container.

Identity blast radius is the more useful metric than VM isolation. A well-isolated VM can still be a high-risk actor if the credentials inside it can reach multiple APIs, repositories or dashboards. The important governance question is how far the agent can move with its current entitlements, not how neatly the host is segmented. That shifts programme ownership toward NHI lifecycle and access policy discipline.

Agentic access policies need continuous evaluation because static placement assumptions fail quickly. If the control logic assumes the workload stays in one place and behaves predictably, it will miss the moment an AI agent starts using legitimate access in an unsafe way. The implication for security and IAM teams is to design for runtime authorisation, not just deployment-time isolation.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• The agentic AI market is already worth $5 billion and is projected to reach $50 billion by 2030.
• Read next: Zero Trust for AI Agents

What this signals

Identity blast radius: The useful unit of AI risk is no longer the server or subnet but the set of identities, secrets and APIs an agent can touch from inside it. If those entitlements are broad, the VM becomes a container for overreach rather than a control boundary.

Security programmes should assume that workload location will matter less than access scope as AI agents spread into operational environments. That pushes IAM, PAM and NHI governance closer together, because the same entitlement logic must cover humans, services and agents when they share infrastructure.

For practitioners

• Define workload-level identity boundaries Inventory every AI agent running in a VM and map the exact identities, secrets and entitlements it uses to reach APIs, data stores and model services.
• Replace broad network trust with context-aware policy Enforce identity, posture and purpose-based rules for each connection rather than trusting traffic because it originates from an internal VM.
• Remove static credentials from agent runtimes Eliminate shared credentials and long-lived secrets from agent environments where possible, and scope any remaining access to the narrowest task boundary.
• Constrain outbound reach from agent VMs Allow each AI agent to communicate only with approved APIs, services and destinations so a compromise cannot turn the VM into a data-exfiltration pivot.
• Audit agent observability at the connection layer Log which workload identity requested access, what it reached and whether the decision was approved dynamically so responders can trace agent behaviour after the fact.

Key takeaways

• AI agents in VMs are still governed by the identities and entitlements they carry, not by the isolation of the host alone.
• Broad network trust and static credentials are the conditions that keep VM-based AI workloads exposed to lateral movement and data leakage.
• The decisive control is identity-based authorisation with continuous policy evaluation inside the workload boundary.

Key terms

• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Headless Enforcement: Headless enforcement is security policy applied to workloads that have no human operator at the keyboard. It matters for AI agents and other non-human identities because authentication and authorisation must occur without interactive prompts, while still preserving context, auditability and least privilege.
• Continuous authorization: Continuous authorization is the practice of rechecking access as a session unfolds instead of trusting a single login decision. It matters for AI workflows because the request, context, retrieved data, and downstream action can all change between prompt and execution, making static approval too blunt.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.