How should teams govern shadow AI in existing IAM programmes?

Shadow AI belongs in the IAM operating model, not in a separate AI exception queue

Governance works best when shadow ai is treated as an access path problem: who can connect, what they can reach, and how that access is approved, reviewed, and removed. In practice, the IAM programme becomes the control plane for discovery, ownership, entitlement review, and offboarding, so sanctioned and unsanctioned AI usage are assessed under the same governance logic.

This is where an identity-first view matters. If the programme only tracks approved tools, it misses the user-to-tool relationship that actually creates risk. Teams need a way to map AI usage back to users, groups, roles, applications, and delegated permissions, otherwise the programme can only describe policy, not enforce it.

That also changes how teams should define scope. The right question is not whether a tool is “official” AI, but whether it is using corporate identity, tokens, consent grants, service accounts, or browser sessions that already sit inside the IAM estate. When that connection exists, the AI use case is already part of access governance, even if no one intended it to be.

What shadow AI changes in identity governance and access review

Shadow AI creates a governance gap when access is granted through channels that bypass normal app onboarding, inventory, or approval. That often shows up as OAuth consent, personal API keys, unmanaged connectors, or a user creating a workflow with business data but no corresponding owner, reviewer, or offboarding trigger. The control problem is not the model itself, it is the untracked authority behind the model use.

Teams should therefore extend existing joiner, mover, leaver and recertification processes so they cover AI use alongside normal application access. If a user leaves, changes role, or loses a business need, any connected AI tools, integrations, and token grants should fall into the same removal and review workflow as other entitlements. IAM and IGA Basics is a useful baseline for structuring that review model across people, machines, and access entitlements.

Discovery is equally important. The practical inventory is not just a list of approved AI products, but a record of consented apps, service connections, key usage, and identity-linked activity that indicates an unapproved AI pathway. Shadow AI and AI Agent Discovery Guide shows how to find those pathways through OAuth grants, API keys, and other telemetry, then bring them under governance.

A mature IAM programme should also distinguish between ownership of the user account and ownership of the AI relationship. The account may be legitimate, but the attached AI use may be temporary, experimental, or created outside procurement. That is why entitlement review needs to ask not only whether access is permitted, but whether the connected AI use still has a named business owner and an active approval path.

How teams should operationalise control without slowing legitimate AI use

The most effective model is to reuse existing IAM control points rather than invent a separate shadow AI approval process. Discovery feeds inventory, inventory feeds ownership assignment, ownership feeds access review, and access review feeds revocation or reapproval. That sequence keeps governance practical because it aligns with the controls teams already use for applications, integrations, and privileged access.

Teams should prioritise the identities and grants that can actually move data or trigger actions. A low-risk AI chatbot with no enterprise access is not the same as an unsanctioned connector with mailbox, file, or source-control privileges. Put review effort where the identity can create material exposure, and do not treat every AI mention as equal. Identity Security Programme Guide is a good reference for organising that governance across scope, RACI, and control ownership.

Offboarding needs special attention because shadow AI tends to persist as forgotten consent or token sprawl after the original use case disappears. If a user can no longer explain why an AI tool has access, that is already a governance failure, even before any misuse is detected. The decision rule should be simple: no clear owner, no active business justification, no retained access.

For programmes already using cloud or workload access governance, the same pattern applies to non-human tokens and service identities that underwrite AI workflows. Where AI is chained to API credentials or service principals, entitlement review should cover those dependencies too, not just the human user who clicked approve. Cloud Workload Identity Guide is relevant here because many shadow AI paths are really workload identity problems in disguise.

Practitioner Guidance

What to prioritise: Start with the access paths that connect users to AI tools, especially OAuth grants, API keys, and unmanaged connectors. Those are the points where shadow AI becomes governable in an IAM programme because they expose ownership, privilege, and revocation leverage.

Decision rule: If you cannot tie a shadow AI use case to a user, role, owner, or service identity, treat it as an ungoverned entitlement path rather than an isolated AI concern. If you can tie it to an identity, bring it into normal review, recertification, and offboarding cycles.

What good looks like: Every AI-related access path has a named owner, an explicit business purpose, a review cadence, and a removal trigger. The programme can answer who approved it, what it can reach, and how it will be withdrawn when the need ends.

Practitioner takeaway: Shadow AI becomes manageable when IAM stops asking only whether a tool is approved and starts asking whether the connected access path is owned, reviewable, and revocable.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• How do security teams align AI governance with existing IAM and data security programmes?
• How should IAM teams govern AI agents as identity programmes mature?
• How should security teams govern generative AI workloads without breaking existing IAM models?