AI agent identity and zero trust: why IAM models are breaking

At a glance

What this is: This is an analysis of why AI agents are becoming a new identity class and why existing Zero Trust and IAM controls struggle to govern them cleanly.

Why it matters: For IAM and NHI practitioners, the issue is that agent access can be real, productive, and still largely unauditable if identity, privilege, and lifecycle controls are not rebuilt around autonomy.

By the numbers:

• 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.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Token Security's analysis of Zero Trust for autonomous agents and AI identity

Context

AI agent identity is now a governance problem, not just a tooling problem. When an agent logs in with production access, it can inherit business authority without the visibility, ownership, and lifecycle discipline that IAM teams expect from human users or managed workloads. The primary keyword here is AI agent identity, because that is where the control gap appears first.

The article’s central point is that Zero Trust only works if the identity model underneath it is explicit. Agents often authenticate through shared service accounts, long-lived API tokens, and credentials distributed across clouds and applications, which makes accountability weak and decommissioning fragile. That is a familiar pattern in NHI programs, but the speed and autonomy of agents make the risk materially harder to contain.

This is not an edge case. The operational model described here is already becoming common as organisations rush to enable agentic workflows, and the governance consequences are predictable: unclear ownership, poor auditability, and privilege that outlives the task it was meant to support.

Key questions

Q: How should security teams govern AI agents that act like users but run like workloads?

A: Treat them as a distinct NHI class with their own identity, owner, scope, logging, and offboarding process. Do not rely on shared service accounts or generic tokens to represent multiple agents. Governance should bind each agent to a defined purpose, limit access to that purpose, and revoke credentials when the task ends.

Q: When does zero trust fail for AI agents?

A: Zero Trust fails when authentication is treated as the whole control model. If an agent can log in with broad, long-lived access and still act beyond the intended task, then the environment has verification at the door but weak enforcement inside it. Continuous checks must cover scope, behaviour, and lifecycle, not login alone.

Q: What is the difference between agent identity and service account access?

A: Service account access identifies a technical credential, while agent identity should identify the autonomous actor, its owner, and its permitted intent. If multiple agents share the same service account, you lose attribution and containment. A real agent identity model makes each action traceable and each privilege boundary enforceable.

Q: Why do AI agents create new NHI governance risks?

A: AI agents can reason, chain tools, and execute actions quickly, which means they can consume more privilege than traditional batch workloads. They also tend to inherit static credentials and scattered entitlements. That combination creates a governance gap where access is real, but oversight is incomplete and revocation is slow.

Technical breakdown

Why AI agent identity breaks traditional zero trust assumptions

Zero Trust assumes every request can be tied to a known subject, a policy decision, and a bounded level of trust. AI agents complicate that model because they act like software with human-like decision paths. They can chain tools, select next steps, and execute actions at machine speed, but often authenticate through generic service accounts or backend tokens. That means the control plane sees an access event, while the business cannot easily answer which agent instance acted, under whose intent, and with what scope. When identity is collapsed into shared credentials, policy loses precision and audit trails lose meaning.

Practical implication: Treat agent login as an identity design problem before it becomes an access review problem.

Service accounts, API tokens, and the hidden NHI trust layer

The trust layer behind many agents is still built on classic NHI patterns: static API keys, long-lived tokens, and credentials embedded across cloud and SaaS environments. These credentials may enable fast deployment, but they also create a weak binding between the agent, the task, and the environment. If the same secret can be reused across workflows or instances, then revocation, attribution, and boundary enforcement all become harder. In practice, the credential is carrying more authority than the agent’s declared intent, which is the opposite of least privilege. This is where agent governance and secrets governance collide.

Practical implication: Map every agent to its own credential path and remove shared secrets from autonomous workflows.

Identity lifecycle control for autonomous agents

Agents need lifecycle controls similar to humans and workloads, but with tighter coupling to intent and runtime state. That means issuing identity at creation, constraining it to a defined purpose, monitoring behaviour continuously, and revoking access when the workflow ends or the agent changes function. Without that lifecycle discipline, orphaned access is almost inevitable, especially when agents are cloned, updated, or retired without a clean deprovisioning process. The governance challenge is not only who approved the agent, but whether the identity expires as quickly as the task does. This is classic NHI risk, amplified by autonomy.

Practical implication: Build offboarding, rotation, and ownership workflows for agents before scaling deployments.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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 agent identity is becoming the next unmanaged NHI category. The field keeps treating agents as a feature layer on top of existing IAM, but the article shows that they already behave like a distinct identity type with their own access paths and audit needs. When an agent can act without a human in the loop, the old assumptions about named users and stable workloads stop working. Practitioners should classify agents as first-class NHIs, not temporary exceptions.

Shared credentials are creating an identity blast radius that Zero Trust was meant to reduce. If multiple agents, apps, or cloud services can operate through the same token or service account, then attribution collapses and containment weakens. That turns every credential into a potential multi-system pivot point. The practical conclusion is straightforward: identity boundaries must narrow, or the blast radius will keep expanding.

Agent governance now depends on lifecycle discipline, not just policy statements. A policy that says agents must be bounded is not enough if decommissioning, rotation, and ownership are informal. The article’s strongest insight is that operational control has to exist at issuance, during use, and at retirement. Security teams should treat agent identity as a managed lifecycle with visible owners and revocation paths.

Zero Trust needs an autonomy-aware interpretation to remain useful. The model still applies, but only if continuous verification includes task scope, intent, and runtime behaviour, not just authentication at login. Otherwise, agents will satisfy the letter of access control while violating its spirit. The right answer is not to weaken Zero Trust, but to adapt it for autonomous execution.

Agentic AI security and NHI governance are converging into the same control problem. The more an agent can reason, delegate, and act across tools, the more it resembles a privileged non-human identity with dynamic authority. That convergence means IAM, PAM, secrets management, and runtime monitoring can no longer be run as separate conversations. Practitioners should design one governance model for both identity classes.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, 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.
• For related control guidance, see Guide to the Secret Sprawl Challenge for rotation and revocation patterns that reduce the lifetime of exposed credentials.

What this signals

Ephemeral access is only half the answer for autonomous agents. Even if teams adopt short-lived credentials, they still need ownership, audit, and decommissioning controls that follow the agent across its lifecycle. The governance pressure point is no longer whether access can be granted quickly, but whether it can be revoked cleanly and attributed accurately when behaviour changes.

The wider programme implication is that IAM teams will need to merge secret management, workload identity, and agent governance into one operating model. That will force new review paths for delegated access, stronger logging for autonomous actions, and tighter separation between human intent and machine execution. Teams that keep those functions isolated will keep finding blind spots after deployment.

Identity blast radius: when one agent credential can unlock many downstream actions, the control objective shifts from broad access management to narrow containment. Practitioners should expect more pressure to prove that each agent has a bounded trust envelope, especially where production data, customer records, or privileged workflows are involved.

For practitioners

• Define a unique identity for every agent Assign each autonomous agent its own named identity, owner, and scope so logs can tie actions back to a specific instance rather than a shared backend token.
• Replace long-lived secrets with short-lived credentials Move agent access to short-lived tokens, automated rotation, and vault-based retrieval so credentials do not outlive the task or remain reusable across workflows.
• Create an offboarding path for every agent Require deprovisioning steps that revoke tokens, remove inherited entitlements, and close any shared access paths when an agent is retired or repurposed.
• Baseline agent behaviour and alert on scope drift Establish expected tool use, data access, and transaction patterns for each agent, then alert when behaviour crosses the defined boundary or touches new systems.
• Separate human delegation from machine authority When a user delegates a task to an agent, preserve the human context while still recording the agent’s own identity and the system-level credentials it used.

Key takeaways

• AI agents are already acting as non-human identities, and that requires a governance model beyond traditional user-centric IAM.
• Shared service accounts and long-lived tokens make agent actions harder to attribute, harder to revoke, and easier to overextend.
• Security teams should operationalise agent ownership, lifecycle controls, and short-lived credentials before autonomy scales further.

Key terms

• AI Agent Identity: An AI agent identity is the set of credentials, ownership, and policy context used to recognise a specific autonomous system in operations. In practice, it should be unique, auditable, and tied to a defined purpose so actions can be traced and revoked without affecting unrelated systems.
• Identity Blast Radius: Identity blast radius is the amount of damage a single credential or entitlement can create if it is misused or compromised. For AI agents and other NHIs, it expands quickly when shared tokens, broad scopes, or reusable access paths allow one identity to reach many systems.
• Delegated Agent Access: Delegated agent access is when a human user authorises an autonomous system to act on their behalf while the agent also uses backend credentials of its own. The challenge is preserving accountability, scope, and auditability when human intent and machine execution overlap.

What's in the full article

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

• The webinar discussion with Token Security CTO and Co-Founder Ido Shlomo and Numberline Security Founder Jason Garbis on identity-first access control for agents
• Examples of how delegated human context, backend identities, and system accounts collide in agent-driven workflows
• The article's practical recommendations for short-lived tokens, automated rotation, and vault-based access
• The full Zero Trust framing for agents that reason, chain tools, and execute actions without a human in the loop

👉 The full Token Security post covers agent identity, delegated access, and secret management in more operational detail.

Deepen your knowledge

AI agent identity and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for autonomous systems from a human-centric IAM baseline, it is worth exploring.