Zero Trust for AI agents: why traditional IAM falls short

At a glance

What this is: This is a LEVO analysis of why Zero Trust Architecture is being applied to AI agents, with the central finding that traditional IAM and perimeter-based controls fail when agents act dynamically and at machine speed.

Why it matters: It matters because identity teams now have to govern AI agents as non-human identities with distinct credentials, runtime policy enforcement, and auditable actions across the same control stack used for human and workload access.

By the numbers:

• 9 out of 10 enterprises expect AI agent, I agent deployment by 2025, according to LEVO.
• Zero Trust is already embraced by 63% of organisations, according to LEVO.

👉 Read LEVO's analysis of Zero Trust for AI agents and identity controls

Context

AI agent identity risk is becoming a governance problem because agent behaviour is not static, predictable, or human-paced. Traditional IAM assumes access can be provisioned, reviewed, and retired against a stable subject, but AI agents can spawn sub-agents, call tools, and change scope mid-session. That makes identity, not the network perimeter, the control point that now matters most.

Zero Trust Architecture is the article's answer to that shift: continuous verification, least privilege, and context-aware authorisation for every agent action. The practical question for IAM, PAM, and IGA teams is no longer whether AI will enter the environment, but whether their current identity controls can represent, monitor, and constrain machine actors without collapsing under runtime delegation.

The governance gap is typical, not exceptional. Most enterprise identity programmes were built for humans and long-lived service accounts, then extended to cover AI by exception rather than by design.

Key questions

Q: What breaks when AI agents inherit access from users and service accounts?

A: The main failure is that inherited access can be broader than the agent’s actual task, so privilege becomes easier to reuse than to govern. Once an agent can chain tool calls across systems, the original approval no longer describes the full blast radius. Security teams need to treat inherited access as a live identity surface, not a one-time provisioning artifact.

Q: Why do AI agents change the way organisations think about zero trust?

A: AI agents can operate continuously, act at machine speed, and influence multiple systems without waiting for a human decision at each step. That breaks static trust assumptions. Zero trust for AI therefore needs continuous verification, traceable identity, and least privilege for the agent itself, not just the human who requested it.

Q: What are the signs that AI governance is failing in the enterprise?

A: Common warning signs include rapid growth in AI use without matching policy coverage, sensitive files being copied into personal accounts, and a large share of AI apps carrying high or critical risk. Another indicator is weak visibility into who is using which tools and what data they are sending. If teams cannot answer those questions, governance is not working as intended.

Q: Should organisations prioritise runtime controls or agent productivity first?

A: Security teams should prioritise runtime controls before broad deployment because uncontrolled agent expansion creates compliance and breach risk faster than most programmes can remediate it. The practical sequence is identity, policy, telemetry, then scale. Without that order, productivity gains can quickly become unrecoverable governance debt.

Technical breakdown

Why AI agents break static IAM assumptions

Static IAM is built around predictable subjects, predefined roles, and access paths that can be reviewed after provisioning. AI agents do not behave that way. They can invoke tools, call APIs, and delegate tasks at runtime, which means their effective privilege changes with context, prompt, and session state. A role assigned at deployment time cannot fully describe what an agent will do later in the same session. That is why the article positions Zero Trust as a control model rather than a product feature. It replaces one-time trust decisions with continuous verification of identity, intent, and policy alignment.

Practical implication: model AI agents as runtime identities, not static accounts, when designing access and audit controls.

How Zero Trust changes agent authorisation

Under Zero Trust, every agent action is individually authenticated and authorised. That includes prompts, API calls, data retrieval, and any delegated sub-task. The technical shift is from broad standing access to short-lived, context-based permission decisions enforced in real time. Attribute-based access control becomes useful because it can evaluate data sensitivity, agent identity, and operational context at the moment of request. The result is tighter scoping and better forensic traceability, especially where regulated data or high-risk actions are involved.

Practical implication: require per-request policy evaluation for agent actions that touch sensitive data or external systems.

Why shadow agents and delegation chains expand the attack surface

The article highlights a shadow agent problem where autonomous bots interact outside central visibility, sometimes over ephemeral channels or in-memory exchanges. In that model, no single gateway sees the full chain of delegation, so data leakage and unauthorised action can happen without a clean enforcement point. The risk is not only compromise but also ungoverned agent-to-agent behaviour that defeats normal logging, DLP, and network controls. This is where microsegmentation, telemetry, and runtime blocking matter together rather than separately.

Practical implication: instrument delegation paths and session behaviour before you rely on agent-to-agent workflows in production.

Threat narrative

Attacker objective: The objective is to turn a trusted agent workflow into a high-speed insider-like path for data access, privilege abuse, and operational disruption.

1. Entry occurs when an over-permissioned AI agent is introduced through shared API keys, inherited user credentials, or a shadow workflow outside IAM visibility.
2. Escalation follows when the agent calls additional tools, spawns sub-agents, or inherits broad access that exceeds the original task scope.
3. Impact occurs when the compromised or misdirected agent exfiltrates data, triggers unauthorised actions, or propagates unsafe logic at machine speed.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agents do not fit the access-review model that IAM teams built for humans. Access review assumes a stable subject with standing entitlements that can be certified on a schedule. That assumption fails when the actor can change scope mid-session, call tools dynamically, and discard privileges after execution. The implication is not just more frequent review, but a different control model for runtime identity.

Zero Trust becomes the governing assumption for agent identity because perimeter logic cannot see inside delegation chains. The article is right to frame identity as the control point, because agent-to-agent behaviour, in-memory handoffs, and ephemeral channels remove the network choke points that older architectures relied on. Practitioners should treat this as a boundary change in identity governance, not a narrow security enhancement.

Shadow agents create a governance blind spot, not merely a visibility problem. Once agents operate outside central registration, policy cannot be enforced consistently and accountability becomes partial at best. That is why the real issue is identity lifecycle completeness for non-human actors, not just monitoring coverage. Teams need to know what exists before they can govern what it does.

Ephemeral credential trust debt is the right phrase for the risk this article surfaces. AI agents often rely on short-lived or inherited credentials that appear temporary but still carry broad authority during their active window. The debt is created when organisations assume short lifetime equals low risk, even though machine-speed execution can exhaust a full blast radius before human review is possible.

Runtime verification is now the minimum viable control plane for autonomous access. Once agents can invoke APIs, delegate work, and alter behaviour in response to prompts, static authorisation no longer tells you what the identity is allowed to do at the moment it acts. The practical conclusion is that identity, policy, and telemetry must move into the same runtime decision path.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, and a quarter encountered multiple attacks.
• The 52 NHI breaches Report shows how compromised credentials repeatedly turn governance gaps into breach paths.

What this signals

Ephemeral credential trust debt: AI agents often inherit short-lived access that still behaves like standing privilege during the session, so lifetime alone is not a control. If your programme cannot answer who approved the identity, what data it touched, and when the privilege was revoked, runtime governance is incomplete. For the control model behind that shift, compare it with NIST AI Risk Management Framework and the identity boundary described in Ultimate Guide to NHIs , Why NHI Security Matters Now.

AI agent programmes will increasingly need the same lifecycle discipline that identity teams already apply to service accounts, but with tighter runtime enforcement and faster revocation paths. The organisations that are best positioned will be the ones that can register agents, observe their tool use, and retire access before delegated actions compound into a wider incident.

If agent behaviour is not tied to a governed identity record, auditability becomes a reconstruction exercise instead of an operational control. That makes evidence collection, incident scoping, and compliance reporting harder at exactly the moment adoption is accelerating.

For practitioners

• Assign unique identities to every AI agent Treat each agent instance as a governed non-human identity with its own credentials, lifecycle, and audit trail rather than sharing tokens across workflows.
• Enforce per-request authorisation for agent actions Apply dynamic policy checks to prompts, API calls, and data access so that each action is evaluated against current context, not just initial provisioning.
• Constrain delegation chains and sub-agent creation Define which agent can spawn another, what it may delegate, and which actions require human review before execution reaches a high-risk boundary.
• Instrument runtime logging and kill switches Log every agent decision path, then block or revoke sessions when behaviour drifts into unauthorised systems, sensitive data exposure, or abnormal tool use.

Key takeaways

• AI agents expose a governance gap that traditional IAM was not designed to close, because their behaviour is dynamic and context-driven.
• LEVO's analysis points to a scale problem as much as a security problem, with adoption accelerating while many pilots stall on unresolved controls.
• The practical answer is runtime identity governance, where access is verified per action and agent behaviour is continuously constrained.

Key terms

• Zero Trust: A security model that assumes no identity — human or non-human — should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.
• Shadow Agent: An AI agent deployed without formal registration, identity governance, or security oversight — the agentic equivalent of shadow IT. Shadow agents are more dangerous than typical shadow NHIs because they actively take actions using their credentials.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.

What's in the full article

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

• Step-by-step Zero Trust implementation patterns for AI agents across identity, policy, and runtime enforcement.
• Detailed examples of microsegmentation and per-request authorisation used to constrain agent activity.
• The vendor's explanation of how to detect, log, and block shadow agents and risky delegation chains.
• Specific guidance on auditability and compliance controls for regulated AI deployments.

👉 LEVO's full post covers the agent control model, runtime verification steps, and compliance implications in more detail.

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 building or maturing an IAM programme, it is worth exploring.