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

At a glance

What this is: This is an Appgate analysis of why virtual machine isolation alone is not enough for AI agents, and its key finding is that identity-based access control must extend into the VM.

Why it matters: It matters because IAM, PAM, and NHI teams cannot treat AI workloads as safely contained just because they run in a sandbox, especially when access is still credential-led and network-broad.

👉 Read Appgate's analysis of Zero Trust controls for AI agents in virtual machines

Context

AI agent identity in virtual machines is a governance problem, not just a hosting choice. If an AI agent inside a VM can still reach APIs, data sources, or dashboards through static credentials and broad permissions, the environment is isolated in topology but not in access.

That gap matters for NHI, agentic AI, and workload identity programmes because the control plane is still being decided by identity, not by the VM boundary. The question is whether access is enforced at the workload level or left to assumptions inherited from perimeter-era segmentation.

Key questions

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: 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: What breaks when AI workloads rely on network segmentation instead of identity controls?

A: Network segmentation can hide the access problem until the VM is already trusted internally. That creates a false sense of security, because the agent can still reach sensitive systems through whatever credentials or permissions were already available.

Q: What should security teams do first when hardening AI agents in VMs?

A: Start with entitlement review. Identify every service account, token, and API path the workload can use, remove unnecessary access, and then require continuous enforcement for both inbound and outbound connections.

Technical breakdown

Why VM isolation does not equal AI agent identity security

A virtual machine separates compute, but it does not automatically separate trust. An AI agent inside the VM still needs credentials, tokens, service accounts, or API permissions to do useful work. If those entitlements are static or overly broad, the VM becomes a convenient execution wrapper around an identity problem. The core failure mode is that network location is being mistaken for authorisation. Zero Trust changes that by binding access to the actor, the request, and the context, not to where the workload happens to run.

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

Identity-based access controls for workload-level zero trust

Workload-level Zero Trust means every connection to the AI agent is authenticated, authorised, and continuously evaluated. That is materially different from trusting an internal subnet or a protected host. For AI workloads, the control surface includes inbound requests, outbound API calls, model repositories, dashboards, and any secrets the agent can reach. If those paths are not explicitly constrained, the agent can overreach even when the VM itself is hardened. This is why entitlement-based access and continuous policy evaluation are central rather than optional.

Practical implication: scope AI agent entitlements per service, per data source, and per direction of traffic.

Why headless enforcement matters for automated AI workloads

Headless enforcement is relevant because AI agents and automated processes cannot rely on interactive user controls. A non-graphical client inside the VM lets policy follow the workload without needing manual logins or exception-heavy network changes. That matters for hybrid and multi-cloud deployments where teams want consistent enforcement across environments. The important point is not the client itself, but the architectural shift it represents: access is attached to the workload identity, not to an operator session or a fixed network zone.

Practical implication: use non-interactive enforcement patterns so automation does not create blind spots.

NHI Mgmt Group analysis

VM isolation is a containment model, not an identity model. The article is right to separate separation from security, because AI agents inside VMs still authenticate to tools, data, and management planes. Once those connections depend on shared credentials or broad trust, the sandbox starts behaving like a disguised flat network. Practitioners should stop treating virtualization as the control and start treating it as the host for the control.

AI agent access inside VMs exposes the same least-privilege failure pattern seen across NHI programmes. The difference is operational speed and runtime variability, not the underlying governance issue. If an agent can reach APIs or data sources beyond its narrow task scope, the programme has granted identity more authority than the use case justifies. Practitioners should align AI workload entitlements to task scope, not to platform convenience.

Identity-centric zero trust is the only durable way to preserve the security value of VM-based experimentation. Network segmentation still helps, but it cannot express who or what is being authorised at runtime. That leaves governance dependent on location, which is the wrong abstraction for AI agents, service identities, and automated workflows. Practitioners should re-centre control on workload identity and continuous evaluation.

Virtual machines can reduce blast radius, but they do not remove accountability gaps. If access is granted through shared secrets or broad service permissions, teams lose visibility into which AI workload accessed what and when. That weakens auditability and makes compliance evidence harder to defend. Practitioners should require identity-level traceability for every agent connection, not just host-level logs.

From our research:

• 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.
• 39% of security leaders say they do not know how often their AI systems are making autonomous changes to infrastructure, showing that visibility gaps are already operational rather than theoretical.
• For a broader control model, see the Ultimate Guide to NHIs for workload identity, lifecycle, and access governance patterns.

What this signals

Identity now has to follow the workload into the sandbox. VM-based AI deployment changes the shape of the control problem, but it does not change the fact that access decisions are identity decisions. The most durable programmes will treat the VM as a runtime container for policy, not as a substitute for it. For teams standardising workload access, the Ultimate Guide to NHIs remains the clearest reference point for governance patterns that scale beyond a single environment.

With 70% of organisations already granting AI systems more access than they would give a human employee performing the exact same job, per the 2026 Infrastructure Identity Survey, the programme issue is not VM hardening alone. It is whether identity governance can express task scope, runtime context, and revocation fast enough to keep pace with automation.

Identity blast radius: when AI agents are placed in VMs without workload-scoped entitlements, the environment can look segmented while still permitting broad access paths. That creates a governance gap between what infrastructure teams believe they isolated and what the agent can actually reach. Security leaders should prepare for more controls to move from network layers into workload identity policy.

For practitioners

• Map AI agent access paths inside every VM Inventory each API, data source, model repository, and dashboard the workload can reach, then remove any entitlement that is not essential to the agent’s task scope.
• Replace static trust with identity-bound policy Enforce authorisation at the workload level so the VM is not treated as trusted by default. Tie access to identity, posture, role, and context rather than subnet location.
• Eliminate shared credentials from AI sandboxes Move away from shared secrets and broad permissions for automated workloads. Assign discrete identities to AI agents and constrain each one to the minimum set of services required.
• Require continuous evaluation for outbound traffic Control what the AI agent can call outside the VM, including external endpoints and management APIs, so exfiltration and unintended tool use are not left to perimeter controls.

Key takeaways

• AI agents running in VMs still need identity controls, so isolation alone does not prevent over-permissioning or data leakage.
• The practical failure is a trust model built on host placement instead of workload identity, which leaves lateral movement paths open.
• Practitioners should scope access per workload, enforce continuous policy evaluation, and remove shared credentials from AI sandboxes.

Key terms

• Workload Identity: A workload identity is the machine-level or service-level identity used by software to authenticate and authorise actions. For AI agents, it is the basis for deciding what the agent may reach, which services it may call, and how its activity is traced and governed.
• Identity-Based Access Control: Identity-based access control authorises access by evaluating who or what is requesting it, along with context and policy. In AI environments, it is stronger than network-only trust because it can constrain a workload even when the host or subnet appears trusted.
• Identity Blast Radius: Identity blast radius is the amount of damage a credential, token, or workload identity can cause if misused or compromised. For AI agents, the blast radius depends on how much access the workload can exercise at runtime, not just how isolated the host appears.

What's in the full article

Appgate's full post covers the operational detail this post intentionally leaves for the source:

• How the Linux Headless Client is positioned for non-interactive AI workloads inside servers and VMs.
• Which identity-centric enforcement points are used for inbound and outbound AI agent traffic.
• How entitlement-based access is applied dynamically across role, posture, and context.
• Why Appgate links this model to auditability and compliance across hybrid environments.

👉 Appgate's full post covers the headless enforcement model, entitlement logic, and AI workload traffic controls.

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.