Shadow AI is any AI tool, feature, model, agent or integration used for work without the organisation knowing about it or approving it, and it now causes real breaches. In IBM's 2025 Cost of a Data Breach research, conducted by the Ponemon Institute across 600 breached organisations, one in five reported a breach due to shadow AI, organisations with high levels of shadow AI saw an average of USD 670,000 in higher breach costs, and only 37% had policies to manage AI or detect shadow AI. This list ranks the ten risks that matter most, for security, IT and risk teams deciding what to tackle first. For how to find shadow AI, see the Shadow AI Discovery Guide.
The Top 10 at a glance
The table ranks ten common shadow AI risks, what goes wrong in each case and the first control that reduces it. Each risk is explained in its own section below, with detection signals and fixes.
| # | Risk | What goes wrong | First control |
|---|---|---|---|
| 1 | Sensitive data pasted into public AI tools | Source code, customer data and meeting content leave the organisation | Approved enterprise AI plus DLP on prompts and uploads |
| 2 | Unknown vendor data use and retention | Inputs retained, reviewed or used for training under consumer terms | Intake review of terms, retention and training opt-out |
| 3 | Broad OAuth grants to AI apps | Long-lived tokens to mail, files and calendars sit with an unvetted vendor | Restrict user consent, review granted apps |
| 4 | AI features switched on inside sanctioned SaaS | Approved platforms add AI that reads data under new terms | Contract and admin review of embedded AI settings |
| 5 | Unsanctioned agents and MCP servers | Local agents run code and tools with the user's credentials | MCP allowlists and managed configuration |
| 6 | Malicious or fake AI tools, extensions and packages | Lookalike tools steal data or credentials | Approved catalogue, package and extension allowlists |
| 7 | Personal accounts and AI API keys | Work done in personal accounts; keys leaked or shared | SSO-only enterprise tenants, secrets scanning |
| 8 | Unreviewed AI output in decisions and code | Wrong answers and insecure code reach customers and production | Human review rules by use case |
| 9 | Regulatory and contractual exposure | Unlawful processing, missed obligations, breached client contracts | AI register, DPIAs, literacy training |
| 10 | No inventory, owner or audit trail | Nobody can say what AI is used, by whom, with what data | Discovery plus an AI register with named owners |
1. Sensitive data pasted into public AI tools
The risk: staff paste source code, customer records, contracts or meeting transcripts into consumer chatbots, translators and summarisers to get work done faster. In the Samsung ChatGPT leak, engineers entered semiconductor source code and a recorded meeting transcript within weeks of the tool being allowed; Samsung capped prompts at 1,024 bytes and later restricted generative AI on company devices.
Why it matters: IBM found that shadow AI incidents compromised personally identifiable information in 65% of cases and intellectual property in 40%, above the global averages of 53% and 33%. OWASP lists this as LLM02:2025 Sensitive Information Disclosure.
What to do: provide an approved enterprise tool as good as the consumer one, then apply DLP to prompts, pastes and uploads. Blocking without an alternative pushes use onto personal phones. See the Generative AI Data Loss Prevention Guide.
2. Unknown vendor data use and retention
The risk: free and consumer tiers often carry terms that allow inputs to be retained, reviewed by humans or used to improve models,.
Why it matters: once data is in a vendor's training or review pipeline you cannot recall it, and processing personal data without a contract that meets GDPR Article 28 is itself a compliance failure.
What to do: run every AI tool through a light intake check covering training use, retention period, data location, sub-processors and deletion. See the DeepSeek and High-Risk AI Vendor Assessment Guide.
3. Broad OAuth grants to AI apps
The risk: users click "Sign in with Google" or "Sign in with Microsoft" on an AI note-taker, inbox assistant or meeting bot and grant it read access to mail, files and calendars. The grant is a long-lived non-human credential held by the vendor.
Why it matters: in the Vercel Context.ai breach, one employee's broad grant to a consumer AI office suite survived the AI vendor's own compromise, and the stolen token gave the attacker the employee's Workspace account without password or MFA.
What to do: in Microsoft Entra, limit user consent to "Allow user consent for apps from verified publishers, for selected permissions" and enable the admin consent workflow; in Google Workspace, review the Accessed apps list and change unconfigured third-party app access away from the default "Allow users to access any third-party apps". Existing grants are not revoked by these settings, so review them. See the SaaS and OAuth App Governance Guide.
4. AI features switched on inside sanctioned SaaS
The risk: the CRM, ticketing, document and meeting platforms you already approved add AI assistants, summaries and agents, sometimes enabled by default.
Why it matters: the original review did not cover the new data flows or sub-processors, and the AI may see everything the platform sees.
What to do: treat new AI features as a change to an approved service: check the admin console for AI toggles, read the AI terms and sub-processor list, and decide per feature. See the Embedded AI in SaaS Guide.
5. Unsanctioned agents and MCP servers
The risk: developers and power users connect coding agents and desktop assistants to MCP servers that read files, query databases and call APIs. The MCP specification says tools "represent arbitrary code execution".
Why it matters: in the Amazon Q MCP config vulnerability, Wiz reported that opening a repository could start MCP servers defined in its .amazonq/mcp.json, and the processes inherited the developer's AWS session.
What to do: use the enterprise controls the tools provide, such as the GitHub Copilot "Registry only" MCP policy or a managed MCP allowlist, and inventory MCP configuration files on endpoints. See the Unsanctioned AI Agents and MCP Servers Guide.
6. Malicious or fake AI tools, extensions and packages
The risk: attackers publish lookalike AI browser extensions, desktop apps, model files and MCP packages that people install without review.
Why it matters: the postmark-mcp malicious MCP server on npm worked normally for fifteen versions, then version 1.0.16 quietly added a blind copy to every email the agent sent. OWASP covers this under LLM03:2025 Supply Chain.
What to do: allowlist browser extensions, route packages through an internal registry or proxy. See the AI Browser Extensions Security Guide.
7. Personal accounts and AI API keys
The risk: staff use personal AI subscriptions for work, or paste self-created API keys into scripts, notebooks and agent configuration files.
Why it matters: personal accounts sit outside SSO, offboarding and legal hold, and API keys in files are found and abused (MITRE ATT&CK T1552.001 Credentials In Files).
What to do: provide enterprise tenants with SSO and SCIM so access ends at offboarding, issue API keys centrally from a secrets manager, and scan repositories and endpoints for AI provider keys. See the Top 10 Secrets Management Mistakes.
8. Unreviewed AI output in decisions and code
The risk: AI answers go into customer replies, legal and HR decisions, financial analysis and production code without anyone checking them.
Why it matters: OWASP LLM09:2025 Misinformation and LLM05:2025 Improper Output Handling describe how confident but wrong output causes harm.
What to do: define which use cases need human review before output is used, and keep AI-generated code under the same review and scanning as human code. See the AI Hallucination Business Risk Guide.
9. Regulatory and contractual exposure
The risk: shadow AI processes personal data without a lawful basis, contract or DPIA, uses client data in breach of confidentiality terms, or deploys AI in uses that regulation restricts.
Why it matters: under Article 4 of the EU AI Act, which has applied since 2 February 2025, providers and deployers must take measures to support the AI literacy of their staff, which is hard to show for tools you do not know about.
What to do: record approved AI use in an AI register, run DPIAs where personal data is involved, and train staff on what is allowed. See the EU AI Act AI Literacy Obligations (Article 4) Guide.
10. No inventory, owner or audit trail
The risk: the organisation cannot list which AI tools, agents and integrations are in use, who owns them and what data they touch.
Why it matters: every other risk on this list depends on visibility. IBM found 63% of breached organisations either had no AI governance policy or were still developing one, and that among organisations with AI governance policies only 34% performed regular audits for unsanctioned AI. NIST AI RMF GOVERN 1.6 asks for mechanisms to inventory AI systems.
What to do: combine discovery sources into an AI register with a named owner for each entry. See the AI Register and AI Inventory Template.
Mapping to OWASP
| Risk | OWASP Top 10 for LLM Applications 2025 | OWASP Agentic Top 10 2026 | MITRE ATT&CK / ATLAS |
|---|---|---|---|
| 1. Data pasted into public tools | LLM02 | Not specific | T1567 Exfiltration Over Web Service; AML.T0057 LLM Data Leakage |
| 2. Vendor data use and retention | LLM02, LLM03 | Not specific | Not specific |
| 3. Broad OAuth grants | LLM06 | ASI03 | T1528 Steal Application Access Token |
| 4. Embedded AI in sanctioned SaaS | LLM02, LLM06 | ASI02 | Not specific |
| 5. Agents and MCP servers | LLM06 | ASI02, ASI04, ASI05 | AML.T0053 AI Agent Tool Invocation |
| 6. Malicious tools and packages | LLM03 | ASI04 | T1195.002 Compromise Software Supply Chain; AML.T0010 AI Supply Chain Compromise |
| 7. Personal accounts and API keys | LLM02 | ASI03 | T1552.001 Credentials In Files |
| 8. Unreviewed output | LLM05, LLM09 | ASI09 | Not specific |
| 9. Regulatory exposure | LLM02 | Not specific | Not specific |
| 10. No inventory or owner | Not specific | ASI10 | Not specific |
For control mapping, NIST CSF 2.0 ID.AM-02 (inventories of software and services) and PR.PS-05 (unauthorised software prevented) and NIST SP 800-53 CM-10 and CM-11 cover the governance side. See the OWASP Top 10 for LLM Applications Guide and the OWASP Top 10 for Agentic Applications Guide.
Where to start
- Offer a good approved tool first. An enterprise AI assistant with SSO, no-training terms and logging removes most of the reason for risks 1, 2 and 7.
- Close the consent door. Restrict user OAuth consent and review existing AI app grants (risk 3).
- Get visibility. Turn on generative AI discovery in your CASB or SSE, export identity provider grants and start an AI register with owners (risk 10).
- Control agents and MCP on developer endpoints. Enforce MCP allowlists in the coding tools you support (risks 5 and 6).
- Write it down. Adopt a policy that sets out how unapproved AI is found, triaged and either approved or retired. Start from the Shadow AI Policy Template and pair it with the AI Acceptable Use Policy Template.
Related NHI Mgmt Group resources: Shadow AI Discovery Guide · Shadow AI Policy Template · Unsanctioned AI Agents and MCP Servers Guide · Top 10 Agentic AI Identity Issues · AI Usage Monitoring Guide