The rule of 17 shows AI agent growth is outpacing IAM controls

At a glance

What this is: This is a Grip Security webinar analysis of the Rule of 17, which says AI agents are proliferating fast enough to create a measurable non-human identity governance problem.

Why it matters: It matters because IAM, IGA, and SaaS security teams need visibility into AI agents, inherited permissions, OAuth grants, and machine identities before governance blind spots become routine access risk.

By the numbers:

• The Rule of 17 says organizations now have approximately one AI agent for every 17 identities.
• Grip Security says 54% of enterprise applications now contain AI functionality.
• Grip Security says the average user is exposed to 33.5 AI-enabled applications.
• Grip Security says AI-related attacks increased approximately 490% year over year.

Context

AI agent identity sprawl is the governance problem created when AI systems gain access to SaaS applications, data, and workflows faster than security teams can inventory and control them. In this article, AI agent growth is the primary subject, but the underlying issue is the same one identity programmes face with service accounts and other non-human identities: access is expanding faster than visibility.

Grip Security's Rule of 17 frames the problem as a ratio. For every 17 identities, there is now one AI agent, and those agents are often embedded in SaaS products, workflow engines, copilots, and delegated access paths rather than existing as neatly managed standalone accounts.

That makes this a non-human identity governance issue, not only an AI adoption story. The operational question is whether organisations can see what those agents can access, what permissions they inherit, and how far those access paths extend into sensitive business data.

Key questions

Q: What breaks when AI agents are treated like standard human users?

A: You lose visibility into effective permissions, expected behaviour, and real blast radius. Human-centric controls can misclassify normal agent activity as compromise, or miss policy violations that happen entirely within legitimate access. The failure is not only technical, it is governance design that assumes a person is always behind the action.

Q: Why do AI agents increase risk in SaaS environments?

A: AI agents increase risk because they can operate through existing application permissions and continue using them as tasks change. That turns delegated access into a broader governance problem, especially when the permissions were never reviewed for non-human use. The result is a larger blast radius from the same underlying grant.

Q: What are the signs that an AI identity is failing governance even if access looks limited?

A: An AI identity is failing governance when teams cannot name an owner, explain why it exists, or trace what it did. Shared credentials, unclear purpose, missing retirement criteria, and weak attribution are strong warning signs. Those problems matter even if the identity only reaches low-risk data today, because the governance gap can expand quickly as integrations change.

Q: Should organisations treat AI agents at checkout as a separate identity pattern?

A: Yes. AI agents can place transactions at a speed and sequence that look unlike normal human checkout, which means legacy fraud controls may misclassify them. Teams should explicitly model authorised agents, capture session and permission context, and decide in advance how those patterns will be scored.

Technical breakdown

How AI agents inherit access through OAuth and delegated identity

AI agents rarely appear as isolated accounts. They often inherit access through OAuth grants, connected SaaS applications, service accounts, or user-delegated permissions, which means the effective identity boundary is the integration chain rather than the agent itself. That matters because the security posture depends on the weakest trust link in the delegated path. If an AI agent inherits broad application scope, it can act with the same reach as the underlying authorisation grant even when no one intended to provision a new standalone identity. The governance challenge is that these relationships are distributed across apps, not centralised in a single IAM record.

Practical implication: Track delegated access chains end to end so the permissions behind each AI agent are visible and reviewable.

Why traditional IAM assumptions break for machine and AI identities

Traditional IAM assumes a user requests access, a manager approves it, and security can later review that permission against a stable human role. AI agents break that model because they can operate continuously, scale instantly, and create downstream actions across multiple systems without a human-paced workflow. In practice, that means the review cadence, role model, and training-based governance built for humans no longer describe the actor actually using the access. The result is not just more identities, but a different identity behaviour pattern that human-centric controls were never designed to observe.

Practical implication: Re-evaluate human IAM workflows that assume access is stable, reviewable, and tied to a person.

Why SaaS ecosystems amplify AI agent identity risk

SaaS environments multiply AI identity risk because AI functionality is now embedded in products users already trust and connect. When AI features are built into collaboration suites, CRM platforms, support tools, and developer workflows, the enterprise often gains new non-human access without a formal deployment event. That creates a visibility gap: security teams may know which employees use the app, but not which AI functions are active inside it or which data sources they can reach. In a SaaS-heavy estate, the control problem is discovery first, then entitlement review, then ongoing monitoring.

Practical implication: Treat embedded AI inside SaaS as a discovery and entitlement problem, not only a vendor feature decision.

Threat narrative

Attacker objective: The attacker aims to exploit over-permissioned AI access paths to reach connected SaaS data and workflows at enterprise scale.

1. Entry occurs when AI functionality is embedded into SaaS tools or connected through delegated OAuth access, creating a new non-human identity path into enterprise systems.
2. Credential or permission abuse follows when the agent inherits scopes or service-account privileges broader than the task actually requires.
3. Escalation happens as the agent operates continuously across applications, creating downstream actions and cross-system reach that outlives the original approval intent.
4. Impact is sensitive data exposure and expanded attack surface across SaaS workflows, where over-permissioned AI identities can be abused or compromised at scale.

Breaches seen in the wild

• SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent identity sprawl is the new baseline risk for SaaS governance: the control problem is no longer how many human users exist, but how many non-human actors now inherit access through the software stack. A Rule of 17 environment means agent discovery, entitlement mapping, and permission review must be treated as core identity work, not edge-case AI oversight. Practitioners should assume every embedded AI feature can expand the effective identity estate.

Human-centric IAM assumptions are no longer sufficient for AI-driven access: the governance model was designed for actors whose access can be requested, approved, and recertified on a human cadence. That assumption fails when AI systems operate continuously and create downstream actions across multiple SaaS services without waiting for a review cycle. The implication is not merely more controls, but a rethink of what an access event even looks like.

Rule-of-17 visibility gaps create identity blast radius: when security teams cannot answer which AI systems exist, what they can access, and which permissions they inherit, they cannot bound the blast radius of compromise. This is the same structural problem that has long affected unmanaged service accounts, but AI agent sprawl makes it faster and less visible. Practitioners need to govern the relationship layer, not just the account layer.

AI governance is becoming identity governance by another name: once AI functionality is embedded in SaaS, the practical question is not whether a model is approved, but whether its access path is inventoried, authorised, and monitored like any other non-human identity. That makes IAM, IGA, and SaaS security inseparable in mature programmes. Security leaders should align AI oversight to identity ownership, not ad hoc application controls.

Rule of 17 is a measurable indicator of control lag: a rising ratio of AI agents to identities signals that governance processes are behind the pace of deployment. The number itself is less important than the operational message it sends about visibility, permission inheritance, and cross-system access. Practitioners should use that lag signal to prioritise discovery and entitlement clean-up.

What this signals

AI agent identity sprawl: the meaningful control boundary is no longer the employee account, but the full set of delegated and embedded non-human identities now operating inside SaaS. Programmes that still centre their governance model on human users will keep missing inherited permissions and access paths that were never intentionally reviewed.

As AI functionality becomes a default feature in enterprise applications, discovery must move upstream of traditional access review. Security teams should expect more entitlement inventory work, more OAuth relationship mapping, and more monitoring of non-human activity inside platforms that previously looked like ordinary SaaS.

For practitioners

• Discover AI agents across SaaS estates Inventory embedded AI features, autonomous workflows, copilots, and connected AI services so the non-human identity estate is visible before access review begins.
• Map delegated access relationships Trace which identities AI agents inherit, which OAuth grants exist, and which data sources those grants can reach across SaaS applications.
• Review AI permissions as non-human identities Apply identity governance to AI agents, service accounts, automation platforms, and machine identities rather than treating them as app settings.
• Monitor AI activity continuously Track permission drift, new AI deployments, and risky integrations continuously because AI systems operate outside human review cycles.

Key takeaways

• AI agents are becoming a material part of the enterprise identity estate, and the governance model has to expand beyond human users to keep pace.
• The risk is not just growth in AI adoption, but inherited access hidden inside SaaS integrations, OAuth grants, and machine identity paths.
• Security teams need discovery, entitlement mapping, and continuous monitoring that treat AI systems as governed identities, not app features.

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.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Embedded AI: Embedded AI is an AI feature built into an existing application rather than delivered as a separate tool. It matters because the app may already be approved, while the new model behavior changes what data is processed, retained, or sent to third parties.
• 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.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.