The decision in front of me this quarter is not whether to allow GenAI. That ship sailed. It is whether I can see the GenAI already running on my data, because the thing I cannot inventory is the thing that shows up in the breach report. IBM's Cost of a Data Breach 2025, the first edition to formally study shadow AI as a breach factor, put a number on the gap I had been hand-waving past: one in five breached organizations named shadow AI as a contributing factor, and only 37% have any policy to manage or even detect it. That is not an awareness problem. It is a discovery problem, and discovery is an engineering job nobody on my team had been assigned.
What shadow AI actually is, and why it bites harder than shadow IT
Shadow AI is the unsanctioned use of AI tools and models with no security review: an engineer pasting a stack trace full of customer records into a personal ChatGPT account, a marketer wiring an OAuth-connected summarizer into the shared Drive, a team standing up a local model on a workstation that no CASB will ever see.
It behaves worse than the shadow SaaS we have been chasing for a decade. Classic shadow IT stores your data in the wrong place. Shadow AI ingests it, retains it, and sometimes trains on it. By the time you notice, the exposure is not a file in the wrong bucket you can quietly re-permission. It is text that left your boundary and is not coming back. You cannot revoke a prompt after the model has read it.
What makes this worth a brief now rather than next quarter is that the 2026 reporting cycle turned the anecdote into a trend line. Netskope's Cloud and Threat Report 2026 found the average organization logs 223 GenAI data-policy violations per month, with sensitive-data-to-AI incidents doubling year over year. The tooling to find this exists. The willingness to point it at ourselves is what is missing.
The cost premium is specific, and it is not small
When a CISO asks me why an ungoverned tool is worth a line item, I stop abstracting and quote the delta. IBM measured it: organizations with high levels of shadow AI paid $670,000 more per breach than those with low or no shadow AI. That is not a modeled estimate or a vendor projection. It comes out of 600 real incidents studied between March 2024 and February 2025.
The mechanism is mundane, not exotic. Shadow AI breaches took longer to spot, 247 days against 241, and spread wider, with 62% touching multiple environments. They also leaked more of the expensive stuff: 65% involved PII against a 53% global average, and 40% involved intellectual property against 33%. That over-indexing on PII and IP is the tell. The data people feed to AI is rarely junk; it is source code, regulated records, contracts, and credentials, exactly the categories Netskope reports flowing to personal AI instances most often.
There is a separate, sharper number underneath all of this. IBM found 13% of organizations suffered breaches of AI models or applications, and 97% of those lacked proper AI access controls. Ninety-seven percent. That is not a story about clever attackers. It is a story about deployments nobody fenced.
Why banning it makes the number worse
Here is the trap I have watched teams walk straight into, and the part most write-ups skip. The instinct on discovering shadow AI is to block it. Netskope's 2026 data shows nine in ten organizations now block at least one GenAI app, averaging ten blocked tools each. It feels like governance. It reports well to a board.
It does not remove the demand. It relocates it. Already 47% of GenAI users reach for personal AI accounts, and 60% of insider-threat incidents involve personal cloud-app instances. Block the corporate-visible path and the work moves to a phone, a home laptop, a personal login, precisely where your DLP, your CASB, and your egress logs see nothing. You did not reduce shadow AI. You converted visible shadow AI into invisible shadow AI and told yourself you fixed it.
This is the second-order cost the prohibition reflex creates. The 97% of AI breaches that lacked access controls is the downstream bill for choosing the satisfying move over the visible one. A blocked tool you can still observe in your logs is a governance opportunity. A tool that fled to an employee's personal device is a future incident with no telemetry attached.
No single sensor covers the surface
The reason discovery gets punted is that nobody owns the whole map, and no one product hands it to you. I learned this by trusting a CASB and getting a partial answer back.
A CASB is good at what it sees: known AI SaaS and the OAuth grants employees click through. It is blind to a local model someone pulled onto a laptop, to encrypted API calls going straight to a provider endpoint, and to browser-only interactions that never touch a sanctioned app boundary. Each of those is a real lane, and each needs a different sensor. Network egress analysis catches the API traffic. Endpoint DLP catches the local model and the copy-paste. OAuth-grant auditing catches the connected agents. Browser-layer inspection catches the chat tab. Run only one of these and you have not narrowed the problem, you have just stopped looking at three quarters of it (Netskope, Forcepoint, 2026).
The OAuth lane deserves singling out, because it is the one that exfiltrates while you sleep. A user clicking "allow" once on an AI summarizer with broad Drive or mail scopes is not a one-time event. It is a standing pipe. The agent reads continuously, on its own schedule, long after the person forgot they granted it.
A counterpoint worth holding
The honest version of this is not "shadow AI is reckless behavior you must stamp out." If 47% of your users are routing around sanctioned tools, the signal is that your approved tooling is slower than the work in front of them. People do not paste code into ChatGPT to leak it. They do it because the governed path either does not exist or takes three approvals and a week.
So the discovery program is not a hunt for bad actors. It is a measurement of where your own provisioning fell behind demand. That reframe changes what you do with the findings: you do not just revoke, you route. Every discovered tool is a request you failed to anticipate.
Where to start this week
Treat shadow AI as a discovery and routing problem, not a prohibition problem. Here is the order I would run it, each step tied to a trigger you can check.
- Inventory before you regulate. If you have no current shadow-AI inventory, run a 30-day egress and OAuth-grant discovery pass before writing a single policy line. The 37% policy-coverage figure means most teams are legislating for tools they never counted. You cannot govern what you have not enumerated.
- Pull the OAuth thread first. Audit every third-party OAuth grant touching mail, Drive, or your repos. If any AI-labeled app holds broad read scopes nobody formally approved, revoke it this week. OAuth-connected agents exfiltrate continuously, not on a click, so the clock is already running.
- Do not blanket-ban. Sanction a fast path instead. If your block list is climbing past a handful of tools (the Netskope average is already ten), read that as a demand signal, not a win. Approve one or two reviewed tools with enterprise data controls so the 47% reaching for personal accounts have a governed alternative that is actually faster than the workaround.
- Put DLP on the AI egress lanes, not just email. If GenAI policy violations cross roughly 200 a month, Netskope's average, treat that as your baseline and route those flows through DLP that can redact secrets and regulated data before they leave the boundary.
- Close the endpoint and browser blind spots before you claim coverage. If a CASB is your only sensor, you are missing local models and browser-only chat by design. Add endpoint DLP and browser-layer inspection, then re-run the inventory and compare the counts.
- Give every found tool an owner, a data class, and a review date. Anchor the program to NIST AI RMF and ISO 42001 so discovery becomes a standing system rather than a one-off scan. A tool with no owner is just a finding you will rediscover next quarter.
The $670,000 is what you pay for choosing not to look. The cheaper move is to look first, route second, and ban almost never.
Sources
- https://newsroom.ibm.com/2025-07-30-ibm-report-13-of-organizations-reported-breaches-of-ai-models-or-applications,-97-of-which-reported-lacking-proper-ai-access-controls
- https://www.cybersecuritydive.com/news/shadow-ai-security-risks-netskope/808860/
- https://www.infosecurity-magazine.com/news/personal-llm-accounts-drive-shadow/


Comments
Be the first to comment.