Agentic AI security challenges are reshaping NHI governance

At a glance

What this is: This is CyberArk’s analysis of five security challenges created by agentic AI, with the central finding that autonomous agents will expand identity risk faster than current governance models can absorb.

Why it matters: It matters because IAM and NHI teams will need to govern agent activity, privilege, and auditability as a first-class identity problem rather than an application-side exception.

By the numbers:

• 45-to-1.
• 2, yberArk says the ratio could skyrocket to over 2,000-to-1 if 50,000 humans manage 100 million AI agents per department.
• CyberArk notes that 80% of organisations report their AI agents have already acted beyond intended scope.
• Only 44% of organisations have implemented policies to govern AI agents, even though 92% say governance is critical.

👉 Read CyberArk's analysis of the five security challenges created by agentic AI

Context

Agentic AI creates a new governance problem because software can now act with delegated authority, not just assist users. For IAM and NHI practitioners, that means identity no longer stops at human users, service accounts, or APIs. It extends to autonomous agents that can request access, chain actions, and influence downstream systems, often across browsers, workstations, SaaS tools, and internal applications.

The article’s core message is that agentic AI will be difficult to avoid as it becomes embedded in day-to-day workflows, but the control model is still immature. That is a familiar pattern in NHI governance: capability expands first, visibility and oversight arrive later. The starting position described here is increasingly typical for enterprises experimenting with agents, which makes the governance gap more urgent rather than exceptional.

Key questions

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

A: Security teams should assign each AI agent a named owner, a defined purpose, and a lifecycle that includes approval, review, rotation, and retirement. Treat agent credentials as privileged NHI secrets, not generic application tokens. The goal is to make every action attributable, every privilege intentional, and every failure recoverable.

Q: Why do AI agents complicate zero trust architecture?

A: AI agents complicate zero trust because they can generate requests continuously, act across multiple tools, and inherit trust from users or workflows that were never designed for autonomy. Zero trust still applies, but it must be extended to machine identities with continuous verification, tight scoping, and session-level monitoring.

Q: What is the difference between a service account and an AI agent identity?

A: A service account usually represents a fixed workload or integration, while an AI agent identity can make decisions, chain actions, and adapt its behaviour based on context. That makes the agent higher risk because the same credential may be used across more varied and less predictable actions.

Q: How can organisations reduce the risk of shadow AI agents?

A: Organisations should discover agent creation points in browsers, SaaS tools, development platforms, and operating-system features, then require registration before deployment. Unknown agents should be blocked from privileged data and production systems until they are owned, logged, and reviewed like any other NHI.

Technical breakdown

Why shadow AI agents create an identity visibility gap

Shadow AI agents are autonomous tools deployed without formal IT or security oversight, often inside browsers, SaaS platforms, or development workflows. The technical issue is not only that they exist, but that they can inherit credentials, act through delegated tokens, and bypass normal approval chains. Once an agent can operate inside a trusted user session, conventional asset discovery may miss it because the activity looks like normal application usage. That creates an identity visibility gap, not just a software inventory problem. Practical implication: discovery must identify agent execution paths, not only installed software or registered workloads.

Practical implication: Classify agents as governed identities and require discovery that tracks where they execute, which tokens they use, and what data they can reach.

Human-in-the-loop controls are a privilege boundary

Human-in-the-loop review sounds like a safety control, but it also becomes a privilege boundary that attackers will target. If an agent can request exceptions, approvals, or escalations, then the human reviewer is part of the authorization chain. That changes the threat model from pure automation risk to social and identity abuse risk. The review step can be weaponised through phishing, fatigue, or manipulation, especially when humans approve high-volume tasks they do not fully inspect. Practical implication: treat approvals for agent actions as privileged access events and log them with the same rigor as administrative sign-off.

Practical implication: Apply strong authentication, step-up controls, and session recording to people who can approve agent exceptions or elevated actions.

Why machine-identity scale breaks traditional IAM assumptions

Traditional IAM was built for relatively stable human populations and predictable service accounts. Agentic systems invert that model by multiplying identities, shortening task windows, and increasing the number of entities that need authentication, authorization, and audit. The article’s 45-to-1 machine-to-human ratio signals that scale alone becomes a control issue, because manual reviews and coarse roles cannot keep pace with millions of ephemeral decision-making entities. As agents specialize and chain tasks, each identity can carry a narrow but potent slice of access. Practical implication: move toward continuous authorization, strict session boundaries, and identity lifecycle controls designed for machine scale.

Practical implication: Design NHI controls for high-volume, short-lived identities, not for static service accounts with long-lived access.

Threat narrative

Attacker objective: The attacker wants to abuse delegated agent authority to expand access, hide activity inside legitimate workflows, and reach systems or data faster than defenders can intervene.

1. Entry occurs when shadow AI agents are deployed through browsers, SaaS tools, or operating-system features without security visibility.
2. Escalation follows when compromised users, developers, or reviewers approve agent requests that extend access beyond intended scope.
3. Impact occurs when autonomous agents act with delegated authority across systems and data, amplifying the blast radius of a single identity compromise.

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

Agentic AI creates an identity governance problem before it creates an application problem. The article frames agents as productivity accelerators, but the more important security shift is that they become decision-capable identities with access paths that must be governed. That means IAM teams need to stop treating agent access as an extension of user access. They need to model it as a distinct identity class with its own controls, lifecycle, and audit requirements.

Shadow AI agents are the clearest example of the runtime governance gap. Once agents can be created inside browsers, SaaS tools, or development environments, inventory-only controls will miss the real risk. The field needs stronger runtime visibility, because the governance failure is not just unauthorised software, but unauthorised authority. Practitioners should assume hidden agents will appear wherever teams can move fastest.

Human-in-the-loop is not a workaround for agent risk. It is a high-value target. The article correctly identifies human review as essential, but review systems become attack surface when attackers can influence approvers or overload them with exception requests. That changes the security design goal from trust in people to resilience around people. Organisations should harden the approval path as carefully as the agent itself.

Identity blast radius becomes the decisive metric in agentic environments. The article’s machine-identity scale point is the right warning signal because the primary danger is not just more identities, but more ways for one identity to fan out across systems. In agentic AI, a small trust failure can become a large operational failure very quickly. Practitioners should measure how far a single agent credential can reach, then reduce that blast radius aggressively.

From our research:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, according to AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.
• That pattern aligns with the broader NHI problem space, which we map in OWASP Agentic Applications Top 10 for teams building controls around agent misuse and privilege abuse.

What this signals

The governance impact is immediate because agentic AI turns every access decision into a potential machine decision. For practitioners, that means identity review cycles need to move closer to runtime, and approval paths need to assume that agents will be both prolific and partially hidden. The organisations that succeed will be the ones that design for visibility before they scale deployment.

Identity blast radius: the practical risk metric for agentic AI is not how many agents exist, but how far a single compromised agent credential can move. That is why JIT access, session recording, and explicit ownership matter so much. If a team cannot bound the blast radius, it does not yet have an agent governance model.

As AI agents proliferate, program owners should expect security exceptions to rise faster than formal policy changes. That creates pressure to align NHI controls with broader identity governance, and to anchor the programme in standards such as the NIST AI Risk Management Framework and the OWASP Top 10 for Agentic Applications 2026.

For practitioners

• Define agents as governed non-human identities Classify every autonomous agent, assistant, and workflow bot as an NHI with an owner, purpose, and lifecycle. Link each identity to a specific business function and prohibit shared or ambiguous ownership.
• Instrument agent discovery and audit logging Track where agents run, which users can invoke them, what tokens they inherit, and which systems they touch. Preserve session-level logs so investigators can reconstruct agent actions without guessing.
• Limit approval authority for human reviewers Require step-up authentication and approval thresholds for any person who can authorize elevated agent actions. Separate routine task review from exception approval so attackers cannot exploit a single fatigue point.
• Apply just-in-time access to agent credentials Provision agent credentials only for the task window they need, then revoke them automatically. Pair JIT with strict session boundaries so long-lived tokens do not become standing trust for autonomous workflows.
• Shrink the identity blast radius Reduce the permissions attached to each agent, split broad workflows into narrowly scoped identities, and test the maximum reach of any one token. Use the result as a design limit for future deployments.

Key takeaways

• Agentic AI should be treated as an NHI governance problem, not only an automation upgrade.
• The main risk is not just more identities, but more authority moving through hidden or weakly reviewed paths.
• Teams should tighten ownership, runtime visibility, and just-in-time access before agent adoption scales further.

Key terms

• Agentic AI: Agentic AI is software that can perceive context, make decisions, and take actions toward a goal with limited human prompting. In security terms, it becomes a governed identity because it can request access, use tools, and influence downstream systems in ways that create real privilege and audit risk.
• Shadow AI Agents: Shadow AI agents are autonomous agents deployed outside formal IT and security oversight. They may be embedded in browsers, SaaS tools, or development workflows, which makes them difficult to inventory. Their main risk is not visibility alone, but the hidden authority they can exercise over data and systems.
• Identity Blast Radius: Identity blast radius is the amount of damage a single identity can cause if compromised or misused. For NHI and agent governance, it measures how far one token, session, or approval can spread across systems, data, and workflows. Smaller blast radius means better containment and easier recovery.
• Human-in-the-loop Approval: Human-in-the-loop approval is a control where a person validates or authorises an action an automated system wants to take. In agentic AI, this is not a soft safeguard. It is a privileged decision point that must be protected, audited, and limited because attackers may target the reviewer rather than the agent.

Deepen your knowledge

Agentic AI security and NHI governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is beginning to govern autonomous agents, the course is a practical starting point.

This post draws on content published by CyberArk: The Agentic AI Revolution: 5 Unexpected Security Challenges. Read the original.