Because policy documents do not stop unsanctioned AI use on their own. Shadow AI usually appears when discovery is weak, ownership is unclear, and access controls are not aligned to the actual tools, tokens, and workflows people are using.
Why shadow AI persists after controls are “in place”
shadow ai keeps reappearing because the control problem is usually narrower than the usage problem. Teams may have policy, but if they do not know which AI tools are actually being used, who owns them, and what credentials or integrations they rely on, the real attack surface keeps growing outside the intended approval process.
The practical failure is often not absence of governance, but mismatch between the governance model and the live workflow. People can still reach external assistants, browser extensions, embedded AI features, and third-party copilots through personal accounts, consent grants, API keys, or shared workflows that sit outside the controls security teams think they have enforced.
Even when a tool is sanctioned, shadow AI can persist through unofficial channels if discovery is incomplete. A team may block one application while leaving similar services, token paths, or connected SaaS integrations visible enough for users to reroute around the restriction without breaking their day-to-day work.
Where the control gap usually sits
The deepest gap is often inventory. If you cannot continuously discover AI apps, OAuth grants, API keys, model-provider access, and AI-enabled SaaS features, you are managing policy on paper rather than usage in practice. NHIMG’s Shadow AI and AI Agent Discovery Guide focuses on those discovery paths because they are usually the fastest way to find what slipped past formal approval.
Ownership is the second gap. Shadow AI thrives when nobody is clearly accountable for approving a new tool, reviewing its data exposure, or deciding whether a workflow belongs in a corporate exception register. That ambiguity is especially common when business teams adopt tools first and security is asked to ratify the choice later.
Access control is the third gap, and it is usually the most misleading. Blocking a website does not automatically stop use if the same model, plugin, token, or embedded feature is reachable through another SaaS product or a personal account. Controls only work when they are aligned to the actual identity, token, and integration paths in use.
Why policy alone does not stop the behaviour
Policy is a boundary signal, not an enforcement mechanism. If users can access an AI capability through sanctioned browsers, extensions, personal logins, or delegated OAuth grants, the policy may still exist while the behaviour continues. NHIMG’s Vercel Context.ai OAuth Supply Chain Breach is a useful reminder that third-party AI access paths can create exposure even when the primary application looks legitimate.
Shadow AI also persists because users optimise for speed, not governance. When approved tools are slower, less capable, or harder to reach than consumer AI services, workers will find the path of least resistance unless controls make the safe path genuinely usable. The result is quiet workarounds rather than open defiance.
That is why the control set has to be behavioural as well as technical. Discovery, inventory, approval, token governance, and data handling rules need to line up with the way employees actually invoke AI features, not the way the policy handbook assumes they do.
Risk and Threat Considerations
Shadow AI creates recurring exposure because the organisation often cannot see what data was shared, which external services received it, or which credentials were used to make the connection. Once unmanaged tokens, permissions, or chat histories are involved, the issue becomes a standing confidentiality and third-party risk rather than a one-off policy breach.
Failure mechanism: Users route around weak discovery and incomplete access control through personal accounts, OAuth grants, API keys, embedded SaaS features, or unofficial plugins, leaving the organisation unable to govern the real workflow.
Impact: Sensitive data, code, prompts, and credentials can leave the controlled environment, and the same hidden paths can be reused for later data loss, unauthorized access, or supply-chain compromise.
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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Shadow AI often leaks data through exposed keys, tokens, and credentials. |
| NHI-03 — Vulnerable Third-Party NHI | Third-party AI apps and integrations can bypass intended governance controls. | |
| NHI-05 — Overprivileged NHI | Shadow AI is amplified when tools and integrations have broader access than needed. | |
| Recommendation — Discover and rotate exposed secrets used by unsanctioned AI tools. Assess third-party AI integrations before approving their access. Reduce AI tool and integration privileges to the minimum required. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Unmanaged AI workflows often abuse identities, tokens, and delegated permissions. |
| ASI04 — Agentic Supply Chain Vulnerabilities | Third-party AI services and plugins create supply-chain exposure in shadow AI use. | |
| Recommendation — Constrain agent and tool permissions to approved scopes. Review external AI dependencies before allowing enterprise access. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Shadow AI persists when user and service accounts are not governed across tool paths. |
| IA-5 — Authenticator Management | API keys, tokens, and secrets often enable the shadow AI workflow. | |
| AU-2 — Event Logging | Discovery and monitoring depend on logs that reveal AI usage and access paths. | |
| Recommendation — Inventory and control accounts that can reach AI services. Rotate and revoke authenticators used by unsanctioned AI tools. Log AI tool usage, token use, and connector activity. | ||
Practitioner Guidance
What to prioritise: Start with discovery of the actual AI usage surface, not with another policy refresh. If you do not know which tools, tokens, and integrations are live, your next control decision is guesswork.
What to verify: Confirm that the sanctioned path is materially easier than the unsanctioned one. Check whether users can still reach AI services through personal logins, approved browsers, vendor features, or third-party connectors that bypass the approval workflow.
Decision rule: If a tool can access production data, customer data, source code, or internal documents, treat it as an access-control and data-governance issue first, not a simple acceptable-use issue. Ownership, token scope, and revocation must be clear before the tool is allowed to scale.
Practitioner takeaway: Shadow AI does not persist because teams forgot to write rules, it persists because the rules are not anchored to real discovery and real access paths.
Related resources from NHI Mgmt Group
- Why do secrets and dependency issues still reach pipelines even when teams think their controls are mature?
- Why do Kubernetes clusters often remain risky even when teams think basic controls are already in place?
- Why do recurring security issues keep coming back even after teams spend more on controls?
- How do IAM and NHI teams decide where to place controls for AI agents?