Why do AI tools create problems for IAM and identity governance programmes?

Why This Matters for Security Teams

AI tools do not just add another application to review. They introduce new identity pathways through browser sessions, personal accounts, consented OAuth grants, and delegated tokens that can sit outside normal IAM review cycles. That shifts the problem from simple access assignment to continuous governance of who authorised what, what the tool can reach, and whether that access still matches business intent. The control gap is especially visible in non-human identity (NHI) sprawl, which NHI Management Group documents in The State of Non-Human Identity Security.

For security leaders, this matters because identity governance depends on central visibility, stable ownership, and predictable lifecycle events. AI tools often break all three. A user can connect a model to mail, storage, ticketing, or code repositories in minutes, but the resulting access may not flow through the same approval, inventory, or recertification process used for enterprise apps. Current guidance from the NIST Cybersecurity Framework 2.0 still assumes that identities, assets, and access decisions can be identified and managed as part of a coherent control plane. AI tools make that assumption harder to sustain.

In practice, many security teams encounter unauthorised AI data movement only after a user has already connected a tool to sensitive systems and the identity trail is no longer easy to reconstruct.

How It Works in Practice

The practical failure mode is not that IAM disappears, but that it becomes fragmented across many small trust decisions. A user may authenticate to an AI assistant with a corporate account, then separately grant consent to access email, documents, calendars, or source control. From that point, the tool may act through browser cookies, delegated OAuth scopes, API keys, or embedded agent tokens rather than through a centrally governed enterprise application model. NHI Management Group’s Ultimate Guide to NHIs and Top 10 NHI Issues both reflect this shift: the risky entity is often the tokenized workload behind the interface, not just the human user at the keyboard.

Effective governance needs to follow the identity event across the full lifecycle:

• Discover AI-connected accounts, OAuth grants, browser-based sessions, and service tokens.
• Classify whether access is human-initiated, tool-mediated, or autonomous.
• Map each permission to an owner, purpose, and expiry date.
• Revoke stale grants and rotate secrets when a tool is removed or repurposed.
• Log the action path, not just the login event, so reviewers can see what the AI actually touched.

For implementation detail, NIST guidance on risk-based control selection remains useful, but AI-specific governance often needs tighter linkage to runtime policy, scoped delegation, and secrets hygiene. That is why recent breach analysis on LLMjacking is so relevant: attackers move quickly when exposed credentials or overbroad tokens are available. If a tool can chain actions across systems faster than a human reviewer can intervene, then classic periodic access review is too slow to be the only control.

These controls tend to break down in environments where AI tools are allowed to self-connect to SaaS apps, personal accounts, or developer platforms without a central consent registry because ownership and revocation become impossible to verify consistently.

Common Variations and Edge Cases

Tighter AI access control often increases friction for users and platform teams, so organisations have to balance usability against governance depth. There is no universal standard for every AI tool type yet, but current guidance suggests treating the highest-risk cases as the default priority: tools with mail access, file access, code execution, or external connectors deserve stricter review than read-only assistants. The operational tradeoff is that more control can slow adoption, while less control increases the chance of silent privilege creep.

Some environments also need to separate personal productivity AI from enterprise-managed AI. A user may have approved a consumer account in a browser, but that does not mean the organisation has accepted the downstream identity and data-sharing consequences. The same applies when an AI feature is embedded inside a business app: identity governance still needs to know whether the app is acting as a user proxy, a delegated service, or an autonomous agent. NHI Management Group’s 52 NHI Breaches Analysis is useful here because many failure patterns begin with poor visibility into who or what held the credential, not with a perimeter breach.

Best practice is evolving, but the direction is clear: maintain a current inventory of AI tools, enforce short-lived access where possible, and require explicit ownership for every consented integration. Organisations that wait for a formal incident before mapping AI-driven access paths usually discover that governance failed long before security did.

Related resources from NHI Mgmt Group

• Why do AI tools create new identity governance risks for IAM teams?
• Why do separate productivity tools create governance problems for IAM programmes?
• Why do shadow AI tools create identity risk for IAM programmes?
• What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?