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 with signals you already collect, how to score and record what you find, and how to bring it under governance without simply banning it. It is written for identity, SaaS security and AI governance teams.
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.
- Use several discovery sources. Identity provider and SaaS OAuth grants, secrets scanning, cloud AI inventories, low-code agent platforms, endpoint and browser telemetry, network egress and spend data each see a different slice.
- 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.
- Record credentials, not just names. An inventory entry is only useful if it lists the scopes, keys and identities the tool holds and who owns them, so they can be revoked.
- Make the sanctioned route the easy route. Restrict risky consent, offer approved tools and a central model gateway, and keep discovery running: banning without an alternative pushes usage further out of sight.
What counts as shadow AI
Shadow AI is any AI tool, feature, model access or agent that processes company data or acts on company systems without having gone through your approval, identity and risk processes. It is broader than unapproved chatbots.
| Type | Example | Identity it creates |
|---|---|---|
| Third-party AI apps with OAuth access | AI note-taker, email assistant or office suite connected by an employee | OAuth grant with delegated scopes and refresh tokens |
| AI features inside existing SaaS | Assistant or agent switched on by a vendor or local administrator | Vendor-side service identity using existing integration permissions |
| Low-code agents | Agent built in a productivity, CRM or IT service management suite | Connector credentials, often the maker's own |
| Model provider API keys | Key in a script, notebook, CI/CD variable or browser code | Static API key, frequently long-lived |
| Self-built agents and AI workloads | Agent or model endpoint in a team's cloud account | Cloud role or service account, often broad |
| Developer and desktop tooling | Coding assistants, IDE plugins, browser extensions, MCP servers | Tokens stored locally, plus access to whatever the user can reach |
| Personal AI accounts | Company data pasted or uploaded into a consumer AI service | None you control: an untracked data flow |
The OWASP Top 10 for Agentic Applications describes the identity side of this. Its ASI03 entry warns that "Without a distinct, governed identity of its own, an agent operates in an attribution gap that makes enforcing true least privilege impossible", and gives "identity sharing" as an example: an agent acts on behalf of its maker and lets other users invoke its tools as that identity.
Why it matters: recent incidents
- Vercel Context.ai OAuth Breach 2026: Context.ai said an attacker "likely compromised OAuth tokens for some of our consumer users" of its AI office suite. The chain reached a Vercel employee's Google Workspace account and then Vercel internal access, exposing customer environment variables not flagged as sensitive.
- Salesloft Drift Breach 2025: OAuth tokens held by the Drift AI chat integration were stolen from Drift's AWS environment and used to export Salesforce data from 8 to 18 August 2025. Cloudflare alone rotated 104 of its own API tokens found in the exported data.
- Klue OAuth Breach 2026: according to Klue's investigation summary, a previously compromised GitHub token, which Huntress describes as "long-disused but still active", was used to collect customers' Salesforce OAuth tokens.
- CoPhish 2025: Copilot Studio agents shared as demo websites were used to send users to an attacker's OAuth consent prompt and forward the resulting token.
- LLMjacking 2024 to 2026 and Microsoft Azure OpenAI Abuse 2025: stolen cloud and AI service keys used to run models at the victim's expense. Sysdig, which coined the term, estimated the potential cost at over $46,000 per day; that is the vendor's estimate.
- Google API Keys Exposure 2026: Truffle Security found 2,863 live keys with Gemini access in public web data; keys meant as public identifiers became AI credentials once the API was enabled on the project.
- Samsung ChatGPT Source Code Leak 2023: staff entered source code and a meeting transcript into a public AI service; no attacker was involved, but the data could not be retrieved.
- ShadowRay 2024: Oligo Security reported that exposed Ray AI clusters held OpenAI and Hugging Face tokens, cloud credentials and database passwords.
The common thread is a non-human credential created outside central control, holding access nobody was watching. This maps to OWASP NHI3 (Vulnerable Third-Party NHI), NHI2 (Secret Leakage) and NHI7 (Long-Lived Secrets), and to ASI04 (Agentic Supply Chain Vulnerabilities), which OWASP describes as arising when agents, tools and related artefacts "are provided by third parties and may be malicious, compromised, or tampered with".
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 consent grants from the identity provider; in Google Workspace, the Accessed apps list shows user numbers and the Google APIs (OAuth scopes) each app uses; flag AI vendors and broad scopes |
| OAuth app governance tooling | User-installed OAuth apps across several SaaS platforms | Microsoft's app governance, for example, shows which user-installed OAuth apps can access Microsoft 365, Google Workspace and Salesforce data and who granted them |
| Secrets scanning | Model provider API keys in code, notebooks, CI/CD variables, tickets and chat | Confirm your scanners include AI provider patterns; GitHub's supported patterns include Anthropic API keys, and partner alerts go straight to the provider |
| Cloud AI service inventory | Managed model endpoints, agent runtimes, vector databases and the 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 |
| Endpoint and browser telemetry | Installed AI apps, IDE plugins, browser extensions and MCP configuration files | Use device management and endpoint inventories; search for known MCP and agent configuration files |
| Network egress and secure web gateway logs | Traffic to AI provider domains and APIs | Report on AI domains by user, device and volume; separate API traffic from browser use |
| Spend and procurement data | Card and expense payments to AI vendors; provider invoices | Match vendor names against the sanctioned list |
| SaaS configuration and vendor notices | AI features enabled in existing platforms and their data access | Review admin settings and data processing terms when vendors announce AI features |
No single source is enough. Network logs miss OAuth apps that call SaaS APIs from the vendor's cloud; OAuth exports miss API keys and personal accounts; secrets scanning misses keys that never touch a repository. For the OAuth side in depth, see the SaaS and OAuth App Governance Guide; for desktop tooling, the Browser Extension Security Guide and the MCP Security Guide.
From findings to an inventory
In the NIST AI Risk Management Framework, GOVERN 1.6 reads "Mechanisms are in place to inventory AI systems", and OWASP's ASI04 guidance includes maintaining an inventory of AI components. For identity teams, the inventory must also hold the credentials. For each AI tool, agent or integration found, record:
| Field | Why it matters |
|---|---|
| What it is, vendor and users (count, teams) | Scale and who to contact |
| Identities and credentials: OAuth app and scopes, API keys, service accounts, agent identities | What to revoke or rotate |
| Data and systems it can reach, with classification | Impact if compromised |
| Whether it can act (write, send, delete) or only read | Agency, and so blast radius |
| Internal owner and vendor contact | Accountability and incident notification |
| Status: sanctioned, tolerated or prohibited, with review date | Decision and expiry |
Feed this into the same inventory you use for other non-human identities rather than a separate AI spreadsheet. 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:
| Priority | Typical signs | Action |
|---|---|---|
| Critical | Write or send access to mail, files, code, CRM or finance; organisation-wide or admin-consented scopes; offline (refresh token) access; production cloud credentials | Contact owner and users within days; reduce scopes, move to a sanctioned alternative or revoke |
| High | Read access to confidential data; many users; vendor with weak or unknown security posture; API keys with no expiry | Vendor review and scope reduction; rotate keys into a vault or gateway |
| Medium | Limited read access to internal data; few users | Record, assign owner, review at next cycle |
| Low | No access to company systems or data | Record and cover through acceptable use policy |
When revoking, remember that RFC 9700 expects access tokens to be limited to the minimum privileges needed, so a grant that holds more than its function requires is itself a finding even if the vendor is reputable.
Bringing shadow AI under governance
- Restrict user consent. Microsoft notes that by default all users can consent to apps for permissions that do not need admin consent, and recommends allowing user consent only for apps from verified publishers, for permissions you classify as low impact. Turn on an admin consent workflow so users can request the rest; reviewers still need the rights to grant consent. In Google Workspace, restrict access to high-risk OAuth scopes and choose settings for unconfigured apps.
- Offer sanctioned tools. Provide approved AI assistants, approved agent platforms and a clear request route, so people have a legitimate path. Publish the rules in an AI Acceptable Use Policy Template.
- 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. See the LLMjacking Guide.
- Govern low-code agents. Require owners, restrict connectors to approved systems, limit sharing and set data policies; in Microsoft's Power Platform, data policies act as guardrails over the connectors used by Power Apps, Power Automate and Copilot Studio. See the Low-Code Agent Platforms Guide.
- Review vendors. Add AI-specific questions to third-party risk reviews: data use for training, retention, sub-processors, token storage and incident notification. NIST AI RMF GOVERN 6.1 calls for policies that address AI risks from third parties. See the Third-Party AI Risk Guide.
- Control data leaving by copy and paste. For personal AI accounts, use browser and data loss prevention controls rather than identity controls. See the Generative AI Data Loss Prevention Guide.
- Revoke deliberately. When removing an app, revoke its OAuth grants and refresh tokens, not just its visibility, and rotate any keys it held. NIST AI RMF GOVERN 1.7 covers decommissioning AI systems safely.
For ongoing ownership and review of agent identities, see the Identity Governance for AI Agents Guide.
Detection and monitoring
Discovery is not a one-off project; new tools and features appear weekly. Turn the discovery sources into alerts:
- New consent: alert on new OAuth grants to unverified or AI-category apps, and on any grant with mail, file or offline access scopes.
- New keys: alert when secrets scanning finds an AI provider key, and when cloud logs show model invocations from an identity or region that has not used them before.
- Spend anomalies: watch model usage bills and quotas; LLMjacking shows that a sudden cost spike can be the first sign of a stolen key.
- New agents and connectors: report weekly on agents created or shared in low-code platforms, and on new connectors to sensitive systems.
- Behaviour drift: OWASP's ASI10 (Rogue Agents) covers agents that "deviate from their intended function or authorized scope"; compare what an agent does with what it was approved to do.
Posture tools can automate part of this; see the AI Security Posture Management (AI-SPM) Guide.
Common failure patterns
- Blocking the website, not the integration: AI sites blocked at the proxy while OAuth-connected AI apps keep reading mail and files directly through APIs.
- Names without credentials: inventories that list AI tools but not the scopes, keys and tokens they hold, so nothing can be revoked quickly.
- Keys on personal accounts: model provider keys created on personal accounts and billed to corporate cards, invisible to IT.
- Agents running as their maker: low-code agents shared organisation-wide using their creator's credentials, the "identity sharing" pattern OWASP describes.
- Pilots never closed: trial integrations and tokens left active after the pilot ends, as in Klue's long-disused token.
- Delisting without revoking: an app removed from the approved list while its existing grants and refresh tokens keep working.
- Unrestricted keys: API keys created without API or application restrictions, which gain new powers when a new service such as an AI model is enabled.
Framework mapping
This is an indicative NHI Mgmt Group alignment, not an official crosswalk. Control IDs were checked against NIST CSF 2.0, the NIST SP 800-53 Rev. 5 catalogue, the CIS Controls v8.1 control list, a published ISO/IEC 27001:2022 Annex A index, the NIST AI RMF 1.0 and the OWASP lists cited; CIS is mapped at control level.
| Control area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 | OWASP and NIST AI RMF |
|---|---|---|---|---|---|
| Inventory of AI tools, agents and services | ID.AM-02, ID.AM-04 | CM-8, PM-5 | 5.9 Inventory of information and other associated assets | 2 | AI RMF GOVERN 1.6; ASI04 |
| Control of user-installed tools and consent | PR.PS-05 | CM-11, CM-10 | 8.19 Installation of software on operational systems | 2 | NHI3 |
| Third-party AI services and suppliers | GV.SC-04, GV.SC-07 | SA-9, SR-6, AC-20 | 5.19 Information security in supplier relationships, 5.23 Information security for use of cloud services | 15 | AI RMF GOVERN 6.1; ASI04 |
| Least privilege for OAuth grants and agent identities | PR.AA-05 | AC-6, AC-2 | 5.18 Access rights, 8.2 Privileged access rights | 6 | ASI03; NHI5 |
| AI API keys and tokens | PR.AA-01 | IA-5 | 5.17 Authentication information | 5 | NHI2, NHI7 |
| Acceptable use and data leaving by copy and paste | GV.PO-01 | PL-4 | 5.10 Acceptable use of information and other associated assets, 8.12 Data leakage prevention | 3 | n/a |
| Continuous discovery and monitoring | DE.CM-06, DE.CM-09 | CA-7, SI-4(4) | 8.16 Monitoring activities, 5.22 Monitoring, review and change management of supplier services | 15 | ASI10 |
| Decommissioning and revocation | ID.AM-08 | AC-2 | 5.18 Access rights | 5 | AI RMF GOVERN 1.7; NHI1 |
Metrics that show progress
| Metric | What it shows | Target direction |
|---|---|---|
| Discovery sources feeding the inventory (of the eight in this guide) | Coverage of discovery | Up |
| AI integrations with a recorded owner and credential list | Inventory quality | Up, towards 100% |
| Third-party OAuth grants to AI apps with high-risk scopes | Exposure through consent | Down |
| AI provider keys found outside the vault or gateway | Key sprawl | Down |
| Time from discovery of a critical finding to remediation | Response speed | Down |
| Share of model API traffic through the sanctioned gateway | Adoption of the approved route | Up |
| Retired AI integrations with grants and keys confirmed revoked | Clean offboarding | 100% |
Implementation roadmap
| Phase | Focus | Actions |
|---|---|---|
| First 30 days | First look | Export OAuth grants from the identity provider and main SaaS platforms; add AI key patterns to secrets scanning; pull AI vendor spend; triage critical findings |
| Days 31 to 90 | Inventory and restrict | Build the inventory with credentials and owners; restrict user consent to verified publishers and low-impact permissions with an admin consent workflow; list agents and connectors in low-code platforms; inventory cloud AI services |
| Days 91 to 180 | Provide the sanctioned route | Launch approved AI tools and a central model gateway; publish an acceptable use policy; add AI questions to vendor reviews; add endpoint and network discovery |
| Ongoing | Detect and review | Alerts on new consent, keys, agents and spend anomalies; quarterly review of tolerated tools; revoke grants and keys at retirement |
For the management system around this work, see the ISO/IEC 42001 Guide and the NIST AI RMF Guide.
Practitioner checklist
- Export and review third-party OAuth grants in your identity provider and main SaaS platforms, flagging AI apps and broad scopes.
- Confirm secrets scanning covers AI provider key patterns across code, pipelines and collaboration tools.
- Inventory AI services, agent runtimes and their 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, scopes, access and owner in your NHI inventory, and score by access.
- Restrict user consent to verified publishers and low-impact permissions, with an admin consent workflow.
- Provide sanctioned AI tools and a central model gateway so personal keys are unnecessary.
- Alert on new AI consent, new AI keys, new agents and model spend anomalies.
- Revoke grants and refresh tokens and rotate keys when retiring an AI integration or ending a pilot.
Standards and references
- OWASP: Non-Human Identities Top 10 (2025)
- OWASP: Top 10 for Agentic Applications for 2026
- NIST: AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
- IETF: RFC 9700, Best Current Practice for OAuth 2.0 Security
- NIST: The NIST Cybersecurity Framework (CSF) 2.0
- Microsoft Learn: Configure how users consent to applications
- Microsoft Learn: Configure the admin consent workflow
- Microsoft Learn: App governance in Microsoft Defender for Cloud Apps
- Google Workspace Admin Help: Control which apps access Google Workspace data
- Microsoft Learn: Power Platform data policies
- GitHub Docs: Supported secret scanning patterns
Related NHI Mgmt Group resources: Agentic AI Identity Guide · NHI Lifecycle Management Guide · AI Governance Guide · NHI breach database