They should treat them as formal IAM issues as soon as employees can use them without central approval, review, or offboarding. At that point, the tool is part of the access estate even if procurement never sanctioned it. Governance has to follow usage, not just purchase records.
Why this crosses into formal IAM before procurement does
Unapproved AI tools become an IAM concern at the point they create an access path, not at the point finance signs a contract. If people can log in, connect accounts, exchange data, or delegate actions without central approval, the organisation has already added a new identity-bearing trust relationship that needs ownership, review, and removal rules.
That shift matters because the control problem is no longer “Can we buy this tool?” It is “Who can use it, with what authority, against which data, and how do we revoke that access when roles change or people leave?” Once the tool sits inside daily work, it behaves like any other governed access route.
It also means shadow adoption can expand the access estate faster than procurement records can track it. A tool may be unofficial, but if it is used with corporate credentials, connected to SaaS data, or granted API scope, it is already part of the environment that IAM, access review, and offboarding processes are expected to control.
What makes the risk an IAM problem rather than only an AI governance problem
The IAM lens becomes necessary when the tool changes the organisation’s entitlement picture. That includes account creation, single sign-on, OAuth consent, API keys, shared logins, service integrations, or any workflow where one employee can indirectly act through the tool with organisational authority.
At that point, the issue is not just model output or acceptable use. It is privilege, lifecycle, and accountability. A central owner needs to know whether the tool can read mail, ingest files, reach internal systems, retain tokens, or persist access after the original user has moved on.
This is where the problem becomes visible to NHI lifecycle management thinking as well: if the tool or integration holds credentials or delegated access, it needs provisioning, review, rotation, and offboarding just like any other access-bearing asset. For teams mapping the broader pattern, Top 10 NHI Issues is a useful way to frame the governance failure modes that appear when access grows ahead of control.
Practical triggers for when to classify it as IAM
The simplest trigger is usage without central approval plus any form of access persistence. If the tool can retain sessions, store tokens, use delegated permissions, or reconnect after the user’s job changes, then it needs formal identity ownership and revocation handling.
Other triggers include SSO enablement, corporate account binding, connection to internal documents or SaaS data, shared team credentials, or any situation where staff can onboard the tool themselves and extend its reach without a review step. Those are not just adoption questions, they are entitlement questions.
When the AI tool is tied to employee accounts or shared credentials, a broader IAM operating model becomes relevant, not just ad hoc approval. NHIMG’s Identity Security Programme Guide is helpful here because it treats human, non-human, and AI-agent access as one governance surface. If the concern is specifically how credentials, secrets, and tool access proliferate, the Cloud Workload Identity Guide shows why keyless or tightly bounded access is safer than unmanaged static secrets.
Risk and Threat Considerations
Unapproved AI tools create exposure when they collect or retain access that no one can readily inventory, review, or revoke. The risk is highest when users connect corporate accounts, upload sensitive content, or grant the tool permissions that outlast the person who approved them for themselves.
Failure mechanism: The tool becomes a parallel access channel, often with weak ownership, unclear privilege boundaries, and incomplete offboarding. Attackers and insiders benefit from that gap because the organisation may see the tool as “unapproved software” while it is already acting as an authorised data and identity pathway.
Impact: Unrevoked access, silent data exposure, overbroad delegation, and orphaned integrations can persist after the original business need has gone. That can turn a convenience tool into a durable entry point for credential abuse, data exfiltration, or privilege creep.
For AI tools that actually execute actions or call other services, the threat profile also includes agent-style misuse and delegated privilege abuse. In those cases, Top 10 Agentic AI Identity Issues is a strong companion reference, because the failure is not simply “a bad app existed” but “a tool acted with access no one owned well enough to govern.”
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Unapproved AI tools often persist through tokens, keys, and delegated access that need lifecycle control. |
| AC-2 — Account Management | Shadow AI becomes formal IAM when user and tool accounts need ownership, review, and removal. | |
| IA-9 — Identification and Authentication (Non-Organizational Users) | AI tools and integrations often authenticate as external or non-organizational actors to SaaS and APIs. | |
| Recommendation — Inventory and rotate tool credentials, tokens, and keys under formal authenticator management. Bring AI-tool accounts into account lifecycle review, approval, and deprovisioning. Authenticate external tool connections with controlled, reviewable identity bindings. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The question is about when AI-tool usage becomes part of governed access and entitlement control. |
| Recommendation — Extend IAM governance to any AI tool that creates or persists access to business systems. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Unapproved AI tools often remain connected after the original user, team, or purpose changes. |
| Recommendation — Revoke AI-tool access paths promptly when the business need ends or ownership changes. | ||
Practitioner Guidance
What to prioritise: Treat discovery first, policy second. If a business unit already uses an AI tool with company accounts or corporate data, classify that tool’s access before you debate whether it should be approved.
What to verify: Confirm whether the tool can authenticate through SSO, accept delegated OAuth consent, store API keys, or keep sessions alive after the original user relationship changes. If any of those are true, add it to your IAM review and offboarding scope.
Common mistake: Teams often focus on procurement status and miss the actual control boundary. Approval without lifecycle control still leaves a live access path, which is the part IAM is supposed to govern.
Practitioner takeaway: The right trigger is not “Has purchasing approved this?” It is “Can this tool create, retain, or outlive access that the identity team must be able to see and revoke?”
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org