By NHI Mgmt Group Editorial TeamDomain: Agentic AI & NHIsSource: Grip SecurityPublished June 23, 2026

TL;DR: Organisations now have roughly one AI agent for every 17 identities, alongside 54% of enterprise apps containing AI functionality and 490% year-over-year growth in AI-related attacks, according to Grip Security. The finding shows that identity governance is now being stretched by AI-enabled access patterns that traditional human-centric IAM cannot fully see or control.


At a glance

What this is: Grip Security’s Rule of 17 argues that AI agents have become a large and rapidly expanding non-human identity population inside enterprise SaaS environments.

Why it matters: IAM, IGA, PAM, and SaaS security teams need to account for AI agents, OAuth grants, and machine identities as governed identities because visibility gaps now translate directly into access risk.

By the numbers:

👉 Watch Grip Security's webinar on the Rule of 17 and AI agent growth


Context

AI agent identity risk is no longer a future planning issue. The core problem is that organisations are now granting access to AI-driven systems faster than they can inventory, classify, or govern them, which leaves identity security programmes blind to a growing class of non-human actors.

In practice, AI agents inherit access through OAuth grants, service accounts, APIs, and embedded SaaS functionality, then operate inside workflows that were designed for human-paced approvals. That creates an IAM and NHI governance gap: access exists, but ownership, review cadence, and least-privilege boundaries often do not.

Grip Security’s Rule of 17 is best understood as a pressure test for existing governance models, not as a standalone metric. It shows how quickly AI agents can become operational identities in the same environment where human users, workloads, and service accounts are already difficult to control.


Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do AI agents create more identity risk than ordinary SaaS integrations?

A: AI agents can operate continuously, chain multiple tools, and act on delegated permissions with little human oversight. That makes their effective privilege broader than the original approval suggests. The risk is not only access, but the speed and persistence with which the agent can turn access into credential exposure or lateral movement.

Q: What breaks when access review does not cover non-human identities used by AI agents?

A: When access review ignores the NHIs behind AI agents, organisations lose visibility into stale privileges, inherited rights, and abandoned credentials that still allow action. That creates an audit gap and a control gap at the same time. The access path may still work even when no one can explain why it should.

Q: Who should be accountable for AI agent actions in enterprise systems?

A: Accountability should sit with the team that owns the agent, its policies, and the connected tools, not only with the person who typed the original prompt. When a software actor can send messages, update records, and move data across systems, responsibility must follow the governed identity and its enforcement layer.


Technical breakdown

How AI agents inherit access across SaaS environments

AI agents rarely arrive with clean, standalone identity lifecycles. They inherit permissions through OAuth grants, connected applications, delegated service accounts, API tokens, and embedded SaaS features. That makes them operational identities with effective access even when no security team has explicitly created a separate governance record. The technical problem is not just authentication. It is the hidden chain of delegated access that links users, apps, and back-end services across multiple tenants and business units. Practical implication: inventory the delegation chain, not just the visible application list.

Practical implication: map OAuth grants, service accounts, and API-linked access together before you try to govern AI agents.

Why traditional IAM models miss AI agent behaviour

Human-centric IAM assumes a request, approval, and review cycle that fits people. AI agents do not need to wait for office hours, training, or managerial approval to continue operating. They can execute continuously, interact with multiple SaaS systems, and expand their effective reach through the permissions already attached to the workflow. That means access reviews can show a clean entitlement on paper while the actual runtime behaviour has already drifted. Practical implication: move from static entitlement review to runtime visibility on AI-enabled activity.

Practical implication: pair entitlement governance with runtime monitoring for AI-enabled applications and workflows.

Identity blast radius in AI-enabled applications

When AI functionality is embedded across applications, every additional integration expands the potential blast radius of a compromised or over-permissioned identity. The risk is not limited to the agent itself. It extends to the data sources, workflow steps, and downstream systems the agent can touch. In NHI terms, this is a governance problem of scope, not just volume. An identity with broad SaaS reach can turn a single mis-scoped grant into multi-system exposure. Practical implication: classify AI agent access by data sensitivity and downstream reach, not just by application owner.

Practical implication: treat downstream data access as the control boundary for AI agent governance.


Threat narrative

Attacker objective: The attacker aims to abuse AI-enabled identity pathways to reach sensitive data and downstream workflows across SaaS environments.

  1. Entry occurs when AI functionality is introduced through embedded SaaS features, OAuth-linked applications, or delegated access paths that were not designed as standalone identities.
  2. Escalation happens when the agent accumulates permissions across multiple applications and workflows, creating a larger effective access surface than the original request suggested.
  3. Impact follows when an over-permissioned or compromised AI-enabled identity reaches sensitive data, internal communications, financial records, or connected workflows at enterprise scale.

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 have crossed from feature-level automation into governed identity territory. Once an AI system can touch applications, data, and workflows, it is no longer just a capability flag inside SaaS. It becomes a non-human identity with access scope, lifecycle risk, and review obligations. That shifts the question from whether AI exists in the stack to which identities are being created by it. Practitioners should treat every AI-enabled workflow as an identity governance event.

The Rule of 17 names a real governance pressure, not a fixed security benchmark. The value of the ratio is that it exposes the speed at which AI agents are multiplying relative to traditional identity controls. The useful conclusion is not the number itself but the control gap it reveals: discovery, ownership, and runtime oversight are lagging behind access creation. Security teams should read it as evidence that identity inventories are becoming incomplete by default.

OAuth grants have become a hidden AI identity factory. Many AI agents do not appear through explicit provisioning. They emerge through delegated access, embedded features, and connected apps that inherit authority from users or service accounts. That means the real governance unit is the access relationship, not just the named application or the end user. Identity teams should re-centre governance on delegation chains and runtime scope.

AI agent growth exposes the weakness of static review models. Human access review cadences were built around persistent users whose privileges could be observed and recertified over time. AI-driven access can be created, expanded, and operationalised far faster than those cycles can catch up. The implication is that access certification alone cannot describe the true risk posture of AI-enabled environments. Practitioners should expect continuous visibility to become the baseline, not the premium option.

Identity blast radius is now a first-class metric for SaaS security. A single AI agent can touch multiple systems, data sets, and business processes without ever looking exceptional in one application’s admin console. That makes blast radius more important than raw identity count. The discipline now is to ask how far an AI-enabled identity can move laterally through approved integrations. Teams should prioritise containment by scope, sensitivity, and downstream reach.

From our research:

What this signals

Rule of 17: the useful signal is not the exact ratio but the speed at which AI-enabled identities are entering SaaS estates faster than governance teams can classify them. With only 1.5 out of 10 organisations highly confident in securing NHIs, AI agent growth compounds an already weak baseline.

Security teams should prepare for AI access to be discovered through runtime behaviour, not through neat provisioning records. That makes delegation mapping and NIST Cybersecurity Framework 2.0-aligned continuous control more relevant than annual review cycles.

Identity blast radius: the practical metric for AI governance is how far one agent can move through SaaS, OAuth, and data pathways before human oversight catches up. Teams that cannot answer that question are already operating with incomplete identity governance.


For practitioners

  • Inventory AI-enabled identities across SaaS Build a consolidated register of AI agents, embedded AI features, delegated apps, and service accounts that can initiate or continue workflow actions. Include OAuth grants, API-linked access, and any identity that can touch sensitive data without a human present.
  • Map delegation chains end to end Trace how access is inherited from users to applications to back-end identities, then identify where AI functionality sits inside that chain. Use the path to determine who owns the access, who reviews it, and where revocation would actually break the workflow.
  • Classify AI access by downstream blast radius Prioritise AI-enabled identities based on the data sets and systems they can reach, not on application labels alone. High-sensitivity workflows should be reviewed as if they were privileged access paths because the operational effect is the same.
  • Move monitoring from entitlement to runtime Add continuous monitoring for AI activity in SaaS environments so permission drift, unexpected application chaining, and unusual data access are visible after deployment. Static certification is not enough once AI systems operate continuously.
  • Apply lifecycle controls to AI agents Assign ownership, review dates, and offboarding triggers to AI-driven identities just as you would for other non-human identities. If an AI workflow can be enabled in minutes, it also needs a defined removal path when the business process changes.

Key takeaways

  • AI agents are now a material non-human identity population, and the Rule of 17 shows that governance is lagging behind adoption.
  • Visibility gaps across OAuth grants, delegated access, and embedded SaaS AI create a larger attack surface than most IAM programmes can currently describe.
  • Security teams should shift from static entitlement review to lifecycle ownership and runtime control of AI-enabled identities.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-03AI agents inherit access through delegated credentials and OAuth grants.
NIST CSF 2.0PR.AC-4The article centres on controlling and reviewing identity permissions.
NIST SP 800-53 Rev 5IA-5AI agents depend on authenticator and secret management for access.
NIST Zero Trust (SP 800-207)Zero Trust applies to continuously verified AI access across SaaS boundaries.

Treat AI agents as continuously verified subjects and limit each tool or data path explicitly.


Key terms

  • AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
  • 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.
  • Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
  • OAuth Grant: An OAuth grant is the delegated permission an application receives to act on a user's behalf without storing the user's password. In NHI governance, it should be treated as a standing identity relationship with scope, ownership, and revocation requirements, not as a one-time setup detail.

What's in the full article

Grip Security's full webinar covers the operational detail this post intentionally leaves for the source:

  • Breakdown of the Rule of 17 methodology and how the ratio was derived from SaaS and AI identity data
  • Examples of how AI agents inherit permissions through OAuth grants, connected applications, and service accounts
  • Operational guidance on discovering AI-enabled applications and mapping access relationships across SaaS estates
  • Webinar-specific examples of how security teams can monitor AI activity continuously in live environments

👉 Grip Security's full webinar adds the research detail behind the Rule of 17, including visibility gaps, access patterns, and governance priorities.

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 identity security programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 15, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org