Most organisations have far more AI agents and AI integrations than they know about. An employee connects an AI note-taker to their calendar. A marketing team builds an agent in a low-code platform with access to the CRM. A developer puts a model provider API key in a notebook. A SaaS vendor switches on an AI feature that reads your data. Each creates non-human identities (OAuth grants, API keys, service accounts, agent identities) outside any review, and each can become the way in. This guide explains where shadow AI hides, how to find it using signals you already have, and how to bring it under governance without simply banning it.
Key takeaways
- Shadow AI is an identity problem. Unsanctioned AI tools reach your data through OAuth grants, API keys, service accounts and agent identities; find those and you find the AI.
- Discovery needs several sources: identity provider and SaaS OAuth grants, secrets scanning, cloud AI service inventories, low-code agent platforms, endpoint and browser telemetry, network egress and spend data.
- Prioritise by access, not by tool. An unknown AI app with read access to all mail is a bigger problem than a popular chatbot with none.
- Make the sanctioned route the easy route. Banning without an approved alternative pushes usage further out of sight.
What counts as shadow AI
- Third-party AI apps with OAuth access to email, calendars, files, chat or CRM, granted by individual users.
- AI features inside existing SaaS that process your data, sometimes enabled by default or by a local administrator.
- Agents built on low-code platforms (for example in productivity, CRM or IT service management suites) with connectors to business systems.
- Model provider API keys created by teams and individuals and used in scripts, notebooks, applications and browser code.
- Self-built agents and AI workloads running in cloud accounts, often with broad cloud IAM roles.
- Coding assistants, IDE plugins, browser extensions and MCP servers installed by developers and staff.
- Personal AI accounts used with company data through copy and paste or file upload.
Why it matters: recent incidents
- Vercel and Context.ai (April 2026): an employee had connected a third-party AI productivity tool; its compromise led to exposure of Vercel customer data.
- Salesloft Drift (August 2025): OAuth tokens held by an AI chatbot integration were stolen and used against hundreds of Salesforce customer organisations.
- Klue (June 2026): OAuth tokens held by a SaaS platform on behalf of its customers were exposed in a credential theft campaign.
- CoPhish (October 2025): Copilot Studio agents were abused to trick users into granting OAuth tokens.
- LLM hijacking and the Azure OpenAI abuse case: stolen cloud and AI service credentials used to run models at the victim's expense.
- Google API keys and Gemini (February 2026): API keys embedded in client-side code became a data exposure risk once AI capabilities could be reached with them.
The common thread: a non-human credential created outside central control, holding access nobody was watching. This maps to OWASP NHI3 (Vulnerable Third-Party NHI) and to agentic supply chain risk (ASI04).
Where to look: discovery sources
| Source | What it reveals | How to use it |
|---|---|---|
| Identity provider and SaaS OAuth grants | Third-party apps users have authorised, with scopes and user counts | Export enterprise application and third-party app grants from your identity provider and major SaaS platforms; flag AI vendors and broad scopes (mail, files, offline access) |
| Secrets scanning | Model provider API keys in code, notebooks, CI/CD variables, tickets and chat | Add AI provider key patterns to repository, pipeline and collaboration tool scanning |
| Cloud AI service inventory | Managed model endpoints, agent runtimes, vector databases and the IAM roles they use | Query cloud asset inventories for AI services across all accounts and subscriptions, not only sanctioned ones |
| Low-code agent platforms | Agents built by business users, their connectors and the identities they run as | Use platform admin centres to list agents, owners, connectors and sharing settings |
| Endpoint and browser telemetry | Installed AI apps, IDE plugins, browser extensions and MCP configuration files | Use device management and endpoint detection inventories; search for known MCP and agent config file names |
| Network egress and secure web gateway logs | Traffic to AI provider domains and APIs | Report on AI domains by user, device and volume; distinguish API traffic from browser use |
| Spend and procurement data | Card and expense payments to AI vendors; model provider invoices | Match vendor names against the sanctioned list |
| SaaS configuration | AI features enabled in existing platforms and their data access | Review admin settings and vendor notices for AI features and data processing terms |
From findings to an inventory
For each AI tool, agent or integration found, record:
- What it is and who uses it (users, teams, count).
- The identities and credentials it uses: OAuth app and scopes, API keys, service accounts, agent identities.
- What data and systems it can reach, and the classification of that data.
- Whether it can act (write, send, delete) or only read.
- Who owns it, internally and at the vendor.
- Whether it is sanctioned, tolerated or prohibited.
Feed this into the same inventory you use for other non-human identities. The NHI Lifecycle Management Guide covers discovery and ownership in general, and the Agentic AI Identity Guide covers what an agent registry should hold.
Prioritising what you find
Score each finding on access and exposure rather than on how well known the tool is:
- Critical: write or send access to mail, files, code, CRM or finance systems; organisation-wide or admin-consented scopes; offline (refresh token) access; production cloud credentials.
- High: read access to confidential data; many users; vendor with weak or unknown security posture; API keys with no expiry.
- Medium: limited read access to internal data; few users.
- Low: no access to company systems or data.
Deal with critical items first: confirm with the users and owner, reduce scopes, move to a sanctioned alternative, or revoke.
Bringing shadow AI under governance
- Restrict user consent. Configure your identity provider so users cannot grant third-party apps high-risk scopes without admin approval, and offer a fast request process.
- Offer sanctioned tools. Provide approved AI assistants, model access through a central gateway, and approved agent platforms, so people have a legitimate path.
- Centralise model access. Route model API use through an internal gateway with its own authentication, so teams do not need personal provider keys, and keys can be rotated and monitored in one place.
- Govern low-code agents. Require owners, restrict connectors to approved systems, limit sharing and set data loss prevention policies in agent platforms.
- Review vendors. Add AI-specific questions to third-party risk reviews: data use for training, retention, sub-processors, token storage and incident notification.
- Revoke deliberately. When removing an app, revoke its OAuth grants and refresh tokens, not just its visibility, and rotate any keys it held.
- Monitor continuously. Discovery is not a one-off project; new tools and features appear weekly.
Common failure patterns
- Blocking AI websites at the proxy while OAuth-connected AI apps keep reading mail and files directly through APIs.
- Inventories that list AI tools but not the credentials and scopes they hold.
- Model provider keys created on personal accounts and billed to corporate cards, invisible to IT.
- Low-code agents shared organisation-wide, running with their creator's credentials.
- Removing an app from the approved list without revoking its existing grants.
Practitioner checklist
- Export and review third-party OAuth grants in your identity provider and main SaaS platforms, flagging AI apps and broad scopes.
- Add model provider API key patterns to secrets scanning across code, pipelines and collaboration tools.
- Inventory AI services, agent runtimes and their IAM roles across every cloud account.
- List agents, owners and connectors in each low-code agent platform.
- Use endpoint and network telemetry to find AI apps, extensions, MCP configurations and API traffic.
- Record each finding's identities, access and owner in your NHI inventory, and score by access.
- Restrict user consent for high-risk scopes and provide an approval route.
- Provide sanctioned AI tools and a central model gateway.
- Revoke grants and rotate keys when retiring an AI integration.
Standards and references
- OWASP Non-Human Identities Top 10 (2025): NHI2 Secret Leakage, NHI3 Vulnerable Third-Party NHI, NHI7 Long-Lived Secrets
- OWASP Top 10 for Agentic Applications for 2026: ASI04 Agentic Supply Chain Vulnerabilities
- NIST AI Risk Management Framework (Govern and Map functions)
- ISO/IEC 42001: AI management systems
- RFC 9700: Best Current Practice for OAuth 2.0 Security
Related NHI Mgmt Group resources: Agentic AI Identity Guide · NHI Lifecycle Management Guide · Who Governs AI? · NHI and AI Identity Breaches
