AI agents are widening identity attack surfaces faster than safeguards

At a glance

What this is: This study argues that AI agents are expanding the identity attack surface faster than enterprises are putting formal guardrails, registration, and recovery controls in place.

Why it matters: It matters because AI agents now sit inside the same identity fabric as human and machine accounts, so weak governance can turn routine access into a rapid compromise path for AD, Entra ID, and Okta.

By the numbers:

• 93% already use or plan to use AI agents for sensitive security tasks such as password resets and VPN access.
• Only 65% of organizations say AI identities are fully registered, authenticated and authorized in a formal system.
• Only 32% are very confident they could regain control if AI exposes admin credentials.

👉 Read Semperis' study on AI agents and identity security risk

Context

AI agent identity risk is emerging because enterprises are treating software actors as operational shortcuts before they are treating them as governed identities. In practice, that means agents are being placed into the same systems that manage human and machine access, but often without the same assurance around registration, authorization, or recovery.

The central governance problem is not whether AI can automate useful work. It is whether identity teams can distinguish an AI agent from a conventional workload, assign it least privilege, and recover quickly when it behaves outside expected bounds. That question matters across NHI, autonomous, and human programmes because the identity layer is now shared infrastructure, not a separate domain.

Key questions

Q: How should security teams govern AI agents that can touch identity systems?

A: Treat every AI agent as a governed non-human identity with an owner, defined scope, and revocation path. If the agent can touch authentication or authorization state, give it privileged access controls, full logging, and explicit approval boundaries. The key is to manage the agent as part of the identity fabric, not as a convenience layer above it.

Q: Why do AI agents create more risk than ordinary automation in identity programmes?

A: Because they can be placed inside security workflows that change access state, not just execute repetitive tasks. Once an agent can reset passwords, approve access, or interact with identity infrastructure, a compromise can alter the control plane itself. That is a different risk class from scheduled automation, which typically follows fixed rules and narrower permissions.

Q: What breaks when AI identities are not formally registered?

A: Ownership, review, and recovery all become unreliable. If an AI identity is missing from the authoritative system, teams cannot confidently certify access, trace actions, or revoke privileges during an incident. The result is shadow identity risk, where the organisation has granted access without the governance record needed to control it.

Q: Who is accountable when an AI agent exposes credentials or changes identity state?

A: Accountability should sit with the business owner of the agent, the identity team that granted scope, and the control owner responsible for the affected workflow. If the agent touched privileged systems, incident handling should follow the same seriousness as any privileged access failure, because the issue is not just misuse but governance collapse across the identity layer.

Technical breakdown

AI agents as non-human identities in the identity fabric

An AI agent becomes an NHI when it receives credentials, policy scope, and access to production systems. At that point, it is no longer just a model or workflow helper. It is an identity subject that can authenticate, request resources, and perform tasks inside systems such as Active Directory, Entra ID, Okta, SSH, and encryption environments. The technical failure is often not the model itself but the identity wrapper around it. If the agent is registered inconsistently, tracked in a separate system, or granted broad privileges, the blast radius follows the identity path rather than the model path.

Practical implication: classify every agent as an NHI with explicit lifecycle ownership before it touches privileged systems.

Why sensitive security tasks change the risk profile

Password resets, VPN access, and help desk remediation are high-trust identity operations because they can modify access state rather than just consume it. When AI agents are allowed into those workflows, the agent becomes part of the control plane that decides who can enter the environment. That creates a sharper risk than simple data access because a compromised or mis-scoped agent can change entitlements, not only read them. In identity terms, the agent is no longer adjacent to the control plane. It is inside it.

Practical implication: separate read-only AI assistance from any workflow that can alter authentication or authorization state.

Recovery readiness for identity systems under AI exposure

Identity recovery is different from ordinary incident cleanup because it must restore trust, not just uptime. If an AI agent exposes admin credentials or manipulates identity state, teams need to know which accounts, tokens, policies, and trust relationships must be rebuilt before the environment is trustworthy again. That includes the ability to locate all AI identities, revoke them cleanly, and verify that delegated access was not persisted elsewhere. The study’s concern is therefore about control recovery, not just detection.

Practical implication: test whether identity systems can be returned to a trusted state after agent credential exposure without manual guesswork.

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 governance is now an identity problem, not an AI side issue. Once agents receive credentials, they become part of the identity system and inherit its failure modes. That means registration, authorization, and recovery must be managed through identity controls, not treated as an overlay on top of automation. Practitioners should stop drawing a boundary between AI operations and identity governance, because the boundary has already dissolved.

Formal registration is the first control that breaks when AI identities scale faster than governance. The study shows a material share of organisations either do not fully track AI identities or track them only partially. That creates an identity inventory problem before it becomes a privilege problem. If an agent is not in the formal system, neither ownership nor certification can be made reliable, which undermines the basic assumptions of NIST-CSF and OWASP-NHI.

Identity recovery readiness is a resilience requirement, not a cleanup task. The inability to regain control after AI credential exposure is a sign that the programme is optimised for prevention only. When identity systems are in the blast radius, recovery becomes the condition that determines whether an incident stays technical or turns into business disruption. Practitioners should treat trusted-state restoration as a core control objective, not an afterthought.

AI identities should be governed as privileged actors whenever they can alter access state. Password resets, VPN access, and other security workflows give agents authority that can outsize their apparent role. That changes the governance model from simple workload access to privileged identity execution, which is why least privilege, segregation of duties, and explicit ownership need to be re-evaluated at the identity layer. The practitioner conclusion is straightforward: access-changing agents deserve PAM-grade scrutiny.

Identity blast radius is the right named concept for this category of risk. The study is not just describing broader attack surface growth. It is showing that as AI identities enter the control plane, one compromised or mis-scoped agent can expand the reach of an incident across authentication, authorization, and recovery domains. The implication is that identity teams must evaluate every agent by the damage it can propagate, not only by the task it is meant to perform.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 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.
• Use the OWASP Agentic AI Top 10 to map agent identity and tool-use risks into a practical control set.

What this signals

Identity blast radius: as AI agents move closer to authentication and authorization workflows, the programme risk shifts from isolated misuse to systemic trust failure. Teams should expect more pressure to prove who owns each agent, what state it can change, and how quickly it can be removed from production without breaking recovery.

With 92% of organisations saying some AI is installed on local machines with access to SSH and encryption keys, the operational boundary between endpoint exposure and identity compromise is narrowing fast. That makes identity observability, not just endpoint monitoring, a prerequisite for credible response.

The right forward-looking test is whether your identity programme can distinguish a helpful agent from a privileged one before it reaches a sensitive workflow. If that distinction is unclear, the organisation is already depending on assumptions the current control set does not verify.

For practitioners

• Inventory every AI agent as an identity subject Place each agent in the same authoritative inventory used for service accounts and privileged workloads. Record owner, purpose, system scope, and revocation path so the agent cannot exist outside formal identity governance.
• Restrict agents from access-changing workflows Keep AI agents out of password reset, account recovery, and entitlement modification flows unless there is a narrowly defined approval model and full audit trail. Treat these flows as privileged identity operations, not generic automation.
• Test identity recovery under AI credential exposure Run recovery exercises that assume an agent exposes admin credentials or alters identity state. Validate that teams can revoke access, rebuild trust relationships, and restore verified control without relying on ad hoc manual steps.
• Separate human and agent trust boundaries where access diverges Do not reuse human identity patterns for agents that touch production identity infrastructure. Segregate authentication paths, review cadence, and policy exceptions so agent compromise cannot inherit human trust assumptions.

Key takeaways

• AI agents are becoming governed identities with access to critical systems, which means identity teams now own part of the AI risk surface.
• The study’s numbers show a sharp mismatch between adoption and control, especially where agents can influence security workflows and recovery paths.
• The practical response is to inventory, constrain, and rehearse recovery for agents as privileged NHIs before they become unbounded parts of the control plane.

Key terms

• AI Agent Identity: An AI agent identity is the account, credential set, and policy scope used to let a software actor operate inside production systems. In governance terms, it must be tracked like any other non-human identity, with ownership, authorization boundaries, and revocation steps that work when the agent misbehaves.
• Identity Blast Radius: Identity blast radius is the amount of systems, accounts, and trust relationships that can be affected when one identity is compromised or mis-scoped. For AI agents, the concept is especially important because a single privileged agent can influence authentication, authorization, and recovery paths at the same time.
• Trust Boundary: A trust boundary is the point where one identity context should no longer inherit the privileges or assumptions of another. In AI agent governance, separating human and agent trust boundaries helps prevent a software actor from borrowing human convenience, approval models, or access scope without equivalent controls.

Deepen your knowledge

AI agent identity governance is a core topic in the NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is deciding how to classify, scope, and recover these identities, it is worth exploring.

This post draws on content published by Semperis: State of Identity Security in the AI Era. Read the original.