AI agents expand NHI attack surface faster than IAM can govern

At a glance

What this is: This blog argues that AI agents are becoming a new class of non-human identity and that existing identity governance models do not yet control their access, ownership, lifecycle, or monitoring well enough.

Why it matters: It matters because IAM, NHI, and PAM teams now have to govern machine identities that can be created quickly, inherit broad access, and act faster than traditional review and remediation cycles.

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.

👉 Read Token Security's analysis of NHI risk in AI agents and agentic workflows

Context

AI agents are software identities that can make decisions and take actions in business systems, which means they need the same governance discipline as other non-human identities. The problem is that most identity programmes were built around accounts with stable ownership, predictable use, and review cycles that assume access changes slowly.

Token Security frames this as a shift in the enterprise identity fabric. As more workflows move from human-triggered automation to AI-driven execution, security teams have to track who owns each identity, what it can reach, and when it should be retired. That is an IAM and NHI governance problem before it is an AI problem.

Key questions

Q: How should security teams govern AI agents as non-human identities?

A: Security teams should govern AI agents the same way they govern other privileged non-human identities: assign ownership, define purpose, scope access tightly, monitor behaviour continuously, and revoke credentials when the task ends. The difference is that AI agents can act faster and across more systems, so governance has to be runtime-aware rather than review-only.

Q: Why do AI agents increase NHI risk in enterprise environments?

A: AI agents increase risk because they are often created quickly, inherit broad permissions, and can touch multiple systems in one workflow. That combination raises the chance of privilege creep, poor accountability, and data exposure. If identity teams cannot inventory and bound the access, the AI agent becomes a durable attack path.

Q: What breaks when AI identities are not decommissioned properly?

A: Orphaned AI identities keep credentials, permissions, and system reach after the business need has ended. That leaves stale accounts available for misuse, compromise, or accidental reuse. It also makes audits unreliable because the organisation can no longer prove which identities are active, owned, or legitimate.

Q: Who should be accountable for AI identity governance?

A: Accountability should sit with the business or technical owner that depends on the AI system, not with security alone. Security can define controls and monitor enforcement, but ownership must cover provisioning, review, and retirement. Without a named owner, the AI identity is effectively outside governance.

Technical breakdown

AI workflows, AI agents, and agentic AI have different identity profiles

The article usefully separates three patterns. AI workflows follow preset rules, AI agents make decisions within predefined boundaries, and agentic AI can adapt objectives dynamically. From an identity perspective, that matters because each step increases uncertainty around access scope, accountability, and lifecycle control. A workflow may be governed like a service account with limited functions. An AI agent can expand its use of permissions through context. Agentic AI raises the hardest questions because its behaviour and access needs are less predictable over time.

Practical implication: Classify AI systems by behavioural autonomy before assigning identities, roles, or lifecycle controls.

Why AI-driven identities strain discovery, ownership, and review

AI identities often appear faster than security teams can document them, and many inherit access from their creators or from shared automation patterns. That creates gaps in discovery, ownership assignment, and access certification. If the organisation cannot answer what the identity was created for, who owns it, and what systems it can touch, governance becomes reactive. The article’s core point is that inventory is not a one-time exercise when identities can be created and repurposed continuously.

Practical implication: Build continuous discovery and ownership mapping for AI identities, not periodic clean-up after deployment.

Why lifecycle management and monitoring have to operate at machine speed

AI-driven identities can act in seconds, which compresses the time available to detect misuse, contain compromise, and decommission unused accounts. The article highlights behavioural monitoring, automated lifecycle management, and audit logging because the normal human-paced remediation model is too slow for machine-operated identities. In practice, the issue is not just more access. It is that access can become obsolete, excessive, or malicious before a monthly review ever sees it.

Practical implication: Tie AI identity monitoring and deprovisioning to runtime signals, not calendar-based access review alone.

Threat narrative

Attacker objective: The attacker wants to turn a legitimate AI identity into a fast-moving access path for data theft, control bypass, or workflow manipulation.

1. Entry occurs when AI identities are created through normal enterprise adoption paths, often by developers or business teams that need quick access to models and tools.
2. Escalation happens when those identities inherit broad permissions, shared service accounts, or poorly scoped credentials that let them reach multiple systems without tight limits.
3. Impact follows when a compromised or over-permissioned AI agent manipulates workflows, bypasses controls, or exfiltrates sensitive data across cloud and SaaS environments.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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 governance is becoming an NHI problem before it becomes an AI policy problem. The article is right to treat AI agents as non-human identities because the control failures are familiar: unclear ownership, excessive access, weak lifecycle discipline, and limited monitoring. The practical shift is that identity teams can no longer treat AI adoption as an app-layer issue. They have to govern the identity itself, or the access model expands faster than the programme can absorb.

Discovery and inventory are now continuous identity controls, not project work. The article shows why static inventory breaks down when AI identities are created quickly and used across multiple systems. That turns visibility into an operating requirement, not a quarterly audit task. In OWASP-NHI and NIST-CSF terms, the issue is not only finding the identity but proving what it is allowed to do over time. Practitioners should treat undocumented AI identities as unmanaged production assets.

Privilege creep is the wrong lens for AI agents if the identity can recontextualise access at runtime. Traditional NHI governance assumes access scope can be set, reviewed, and certified against stable use. AI agents complicate that model because their access can be technically valid yet operationally broader than their original purpose. The implication is that entitlement reviews alone will not explain behaviour well enough. Security teams need a stronger link between purpose, runtime activity, and revocation.

Automated decommissioning becomes a governance requirement once AI identities outlive their tasks. The article correctly calls out orphaned accounts and lifecycle management gaps. In a machine-speed environment, unused identities are not just hygiene issues, they are persistent attack paths. That is especially important where AI is embedded into support, security, or operations workflows and ownership changes over time. Practitioners should assume every undocumented AI identity is a standing liability until proven otherwise.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• SailPoint also found that only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That same report shows 92% of organisations agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, which points to a control gap that is still widening.

What this signals

Identity review cycles are no longer enough for AI-driven access. When AI identities can be created, re-used, and retired inside operational workflows, periodic recertification becomes a lagging control. Security teams should expect runtime visibility, ownership mapping, and fast deprovisioning to become baseline requirements for both NHI and agentic AI programmes.

AI identity sprawl will force IAM and GRC teams to work from the same inventory. The governance model breaks if security sees one set of identities, compliance sees another, and engineering creates a third. A shared record of ownership, purpose, and current access becomes the minimum viable control plane for AI adoption.

With 33% of organisations already reporting AI agents accessing inappropriate or sensitive data beyond intended scope, per SailPoint's AI agents research, the next control question is not whether AI will expand access. It is whether the organisation can prove that every new identity has an owner, a purpose, and a kill switch before deployment reaches scale.

For practitioners

• Define AI identity classes before provisioning Separate AI workflows, AI agents, and agentic AI into distinct governance classes so access scope, ownership, and lifecycle rules match actual behaviour. Tie each class to a named business owner and a documented purpose before credentials are issued.
• Map ownership for every AI-driven identity Require a human accountable owner for each AI identity, including service accounts used by AI systems and any credentials shared across environments. If ownership cannot be named, the identity should be treated as ungoverned production access.
• Automate decommissioning and expiry checks Build retirement triggers into the identity lifecycle so dormant or task-complete AI accounts are revoked promptly. Include inherited credentials, shared accounts, and API keys used by AI systems in the same offboarding process.
• Monitor AI access for scope drift Track when AI identities access systems, data, or actions beyond the original approved use case. Feed those signals into incident response and recertification workflows so behavioural drift becomes a review trigger, not a surprise.

Key takeaways

• AI agents are not just another automation layer. They are non-human identities that need ownership, scope, monitoring, and retirement controls.
• The main risk is not only over-permissioning. It is that AI identities can act at machine speed, making discovery and response too slow if governance stays manual.
• Identity teams should move from periodic review to continuous lifecycle control, because undocumented AI identities become standing attack paths.

Key terms

• Non-Human Identity: A non-human identity is any credentialed digital entity that accesses systems without being a person, including service accounts, API keys, tokens, certificates, workloads, bots, and AI agents. In practice, these identities need ownership, lifecycle management, and access controls because they can move data and trigger actions at machine speed.
• AI Agent: An AI agent is software that can make decisions and choose actions within an operational context rather than merely execute a fixed script. For governance, the important point is not the AI label but the fact that the identity can use credentials, touch systems, and create risk without a human clicking every step.
• Agentic AI: Agentic AI refers to systems that can adapt objectives and choose how to pursue them with minimal human intervention. That makes identity governance harder because access needs may shift during runtime, and the normal assumption that a role can be fully defined at provisioning time becomes weaker.
• Identity Lifecycle Management: Identity lifecycle management covers provisioning, changes, access review, and decommissioning across the life of an account or credential. For AI and other non-human identities, the lifecycle has to be continuous and ownership-based because the identity may be created quickly, used briefly, and remain risky if it is never retired.

What's in the full article

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

• The article breaks down the three AI identity categories with use-case examples that can help teams map real deployments to governance classes.
• It outlines the specific discovery, lifecycle, and compliance questions security leaders should ask before AI rollout.
• It describes the platform capabilities Token Security says it uses for AI identity discovery, monitoring, and lifecycle management.
• It connects AI identity risk to concrete controls such as least privilege, audit logging, and decommissioning.

👉 Token Security's full post covers the AI identity categories, governance questions, and control model 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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.