$670,000 more. That's the average premium for breaches involving shadow AI in IBM's 2025 Cost of a Data Breach report. Shadow AI already accounts for about 20% of enterprise breach events. Roughly 75% of knowledge workers use generative AI at work, and 78% of them are using tools they brought in themselves. The gap between "we have a policy" and "we know what's actually running" is where risk lives. Finding shadow AI is about seeing what you have so you can govern it, not about locking the place down. You want to discover it before the post-incident report.
Why Shadow AI Shows Up in Breach Stats
Shadow AI is any AI use that happens outside the systems and processes your organization has approved and inventoried. The developer who pastes code into ChatGPT. The sales team using a free-tier summarization tool. The analyst who uploads a dataset to an external AI app to "clean it up." None of it is necessarily malicious. Most of it is people trying to get work done. But unvetted tools mean unvetted data handling: prompts and outputs that may be logged, trained on, or exposed by the vendor. When that data is sensitive or regulated, you get policy violations, compliance exposure, and in the worst case, a breach that gets attributed to shadow AI because the vector was a tool security never knew about.
The $670K premium in IBM's data reflects the same pattern as other shadow-IT incidents: longer detection and containment when you're not monitoring the system, higher regulatory and legal fallout when the tool was never approved, and more scope creep in the investigation because you're mapping the exposure after the fact. Finding shadow AI before it finds you is a cost and risk control strategy, not a productivity kill switch.
Detection Without Blocking Everything
Visibility and informed policy matter more than "no AI unless it's ours." If you become the department that blocks everything, usage goes further underground and you learn less. Detection should feed into a loop: discover, assess, then either sanction (with guardrails), replace with an approved alternative, or restrict with clear justification. Here's where the signals usually are.
CASB and cloud app logs. If you have a Cloud Access Security Broker or a SaaS security posture tool, you already have a feed of which cloud applications are in use, by whom, and often from where. Many of these platforms now classify apps that include generative AI or ML features. Use that classification, or build a list of known AI-enabled apps (OpenAI, Anthropic, Google AI, Microsoft Copilot, Midjourney, Jasper, Copy.ai, and the long tail of vertical tools), and correlate against your approved list. You're looking for traffic to domains and APIs that aren't in your sanctioned set. CASB can also show you when a new app appears in a department or when usage of an AI app spikes. That's your discovery signal. From there you can decide whether to bring the use case into a sanctioned tool, add the app to the approved list with conditions, or restrict it and explain why.
SSO and identity integrations. If you enforce SSO for business apps, you have a central place where logins happen. Apps that support SAML or OAuth but aren't in your IdP's application catalog are a strong signal. Someone is using something that didn't go through your normal onboarding. Cross-reference with known AI vendors and with any "bring your own app" or unmanaged app reports from your IdP. You won't see every free-tier signup (many tools don't require SSO), but you'll catch a lot of team-adopted or department-adopted AI apps that have been connected to corporate identity. That's a good list to reconcile with your AI inventory and your policy.
Network and proxy traffic. Outbound traffic to AI provider APIs is one of the most direct signals. OpenAI, Anthropic, Google (AI/Vertex), AWS Bedrock, Azure OpenAI, and other major providers have known endpoints. Firewall, proxy, or secure web gateway logs can show which hosts or users are hitting those endpoints. You need to distinguish sanctioned use (your approved apps or your own integrations) from everything else. That means maintaining a list of allowed destinations (e.g., your own API keys or approved SaaS that uses those providers) and flagging everything else for review. Network data can also reveal usage of AI features inside broader SaaS (e.g., traffic patterns to a vendor that recently added AI). It's noisier, but combined with CASB and SSO it fills gaps.
Browser and endpoint telemetry. Where you have endpoint visibility (EDR, browser security, or managed browser policies), you can see which sites and extensions are in use. That covers the long tail of web-based AI tools that don't show up as standalone SSO apps or as heavy API traffic from a single host. Browser telemetry can show repeated visits to AI tool domains, use of AI-focused browser extensions, or uploads to sites known to offer AI processing. Privacy and culture matter here: workers need to know that corporate devices are subject to security monitoring. Frame it as "we need to see which AI tools touch our data so we can secure them" rather than "we're watching every tab." Use the data to discover and then to steer policy and tooling, not to punish.
Turning Detection Into Governance
Detection alone doesn't reduce risk. You need a path from "we see this" to "we've decided what to do."
Triage by data and risk. Not every unsanctioned use is equal. A generic summarization tool used on public content is different from one used on customer PII or source code. Use your detection data to prioritize: which apps, which teams, which data (if you can infer it). Focus first on high-sensitivity data and high-risk domains (finance, HR, healthcare, legal). That's where the $670K and the 20% breach stat will bite.
Sanction where it makes sense. When you find a tool that's widely used and reasonably low risk, consider bringing it in. Negotiate an enterprise agreement, add data and security terms, run it through SSO and DLP, and put it on the approved list. You get visibility and control; users get to keep working. That's the opposite of being the department that blocks everything.
Replace or restrict when you have to. When the tool can't meet your security or compliance bar, offer a sanctioned alternative and explain why the other one isn't allowed. When there's no alternative and the use case is business-critical, you have a decision to make: accept the risk with explicit approval and controls, or restrict and document the business impact. Either way, the decision is informed by detection, not by guesswork.
Close the loop with the inventory. Every shadow AI use you discover is a candidate for your living AI inventory. Add it, assign an owner, classify risk, and track whether it's been sanctioned, replaced, or restricted. Over time, detection plus inventory turns "we don't know what's out there" into "we know, and we've decided."
The Culture Piece
Seventy-eight percent of knowledge workers bringing their own AI tools means the genie is out of the bottle. Detection will surface a lot of usage. If the first message from security is "stop," you'll get less visibility next time. If the message is "we're mapping what's in use so we can secure it and approve good options," you have a chance to align policy with reality. Communicate what you're looking for and why. Publish a short list of sanctioned AI tools and how to request one. Make it easy to ask "can I use X?" and give clear, fast answers. Shrink the shadow by bringing more of it into the light; control what remains when you can't or shouldn't sanction it. Eliminating shadow AI by fiat rarely works.
Shadow AI already accounts for a fifth of enterprise breaches and drives a measurable cost premium when it's involved. Find it with the tools you have, triage by risk and data, and turn detection into governance. The next incident shouldn't be the first time you're hearing about the tool.
We run independent AI risk assessments and governance reviews. Get in touch if shadow AI or AI-related breach risk is on your radar.