Last year, security teams got their first hard look at a number they’d been dreading because 20% of all data breaches now trace back to shadow AI. That is not a projection. Thatis a reality documented by IBM’s 2025 Cost of a Data Breach Report, based on 3,470 interviews across 600 real breached organizations. (Souce)
The average shadow AI breach costs $4.63 million. That total represents $670,000 more than a standard incident. And in 97% of those cases, the breached organization had no proper AI access controls in place.
Your employees are not waiting for IT to approve a tool because they are already using these platforms to speed up their daily work.
What is shadow AI and why is it a security risk
Shadow AI is any AI tool, model, or service that employees use at work without IT or security team approval. This includes the obvious scenarios where a developer pastes source code into ChatGPT for debugging, a finance analyst uploading a revenue spreadsheet to an AI summarizer. However it also includes less visible vectors such as browser extensions that intercept page content, personal free-tier accounts connected to enterprise SaaS platforms via OAuth, and AI plugins quietly embedded inside tools like Notion or Slack.
This trend is different from shadow IT in one critical way. A rogue Dropbox account stores data. Shadow AI processes it. Feeds it into model training pipelines. Generates outputs that cite it back to whoever asks. Once data crosses that boundary, you have no visibility into where it went, who else the model surfaced it to, or whether it’s even deletable.
This data velocity is exactly where traditional security tools break down. Legacy Data Loss Prevention (DLP) was built to catch data at the exit door by blocking a file upload or flagging an email attachment. Unfortunately, legacy DLP never sees the moment an employee copies 200 rows of customer records directly into a chat window. Similarly, Data Security Posture Management (DSPM) which we call Data Security Intelligence (DSI) tells you where sensitive data lives at rest, but shadow AI exposure happens in motion at the exact moment of use.
According to IDC’s 2025 survey, 56% of employees use unauthorized AI tools at work, while only 23% use tools their organization governs. Salesforce’s 2026 Workforce AI Survey puts unauthorized AI tool usage at 67% of employees against just 18% of organizations that have any formal AI security policy.
The math on that gap is uncomfortable.

How much does a shadow AI data breach cost
The $670,000 premium on shadow AI breaches isn’t a rounding error. It’s the result of three compounding factors that security teams currently have no good answer for.
Detection time: The average breach lifecycle in 2025 is 241 days, but shadow AI breaches take an average of 247 days to identify. That 6-day gap reflects a structural problem because unsanctioned AI usage does not trigger traditional security alerts. It blends seamlessly into normal web traffic. Your Security Information and Event Management (SIEM) system sees an HTTPS request to api.openai.com the exact same way it sees a request to Google. Unless you are specifically watching for anomalous runtime prompts, you are essentially blind to the risk.
Data exposure breadth: Shadow AI incidents disproportionately affect the most sensitive record types. Customer PII was compromised in 65% of shadow AI breaches, versus 53% globally. Intellectual property showed up in 40% of shadow AI incidents. And at $166 per record, the cost-per-record in shadow AI breaches runs above the $160 global average. The data employees leak through these tools tends to be the data that hurts most.
Governance vacuum: According to IBM, 63% of organizations still lack formal AI governance policies. Of the ones that do have policies, fewer than half have an actual approval process for AI deployments. Only 34% conduct regular audits to detect shadow AI usage. The average enterprise, per Productiv’s 2026 analysis, has 14 distinct AI tools in active use — IT teams are aware of 4 to 5 of them.
At $10.22 million average per breach, U.S. organizations are getting hit hardest. Regulatory fines are part of this: 32% of breached organizations paid fines, with 48% of those fines exceeding $100,000.

What data do employees expose through shadow AI tools
The exposure pattern is consistent across industries. Employees aren’t pasting in junk. They’re pasting in the most useful context they have — which is also the most sensitive.
In 2024 research found that 27.4% of corporate data employees enter into AI tools is sensitive, up from 10.7% the year before. The breakdown: customer support information accounts for 16.3% of sensitive data exposures, source code 12.7%, and R&D materials 10.8%.
IBM’s own data on shadow AI breaches adds to this. The incidents disproportionately affected data stored across multiple environments — 62% of shadow AI incidents spanned multiple data stores, versus 53% globally. This is the fingerprint of an organization that never mapped where its data actually lives.
Harmonic Security found that 16.9% of sensitive data exposures — nearly 100,000 instances — happened on personal free-tier accounts with no enterprise data agreements, no retention controls, and no audit trail. When an employee uses their personal Gmail to sign into Claude and uploads a strategy deck, your DLP tools see nothing. Your CASB sees nothing. The event just doesn’t exist in your security telemetry.
This is the core visibility gap. Sensitive data — customer PII, source code, financial records, IP — flows out through AI interactions that no existing control layer was designed to watch. DSPM maps data at rest. DLP watches specific egress channels. Neither was built for the moment data moves through a user’s clipboard into a chat interface.
The exposure chain is worth naming explicitly:
- Copy-paste into AI chat interfaces
- File uploads to AI platforms (PDFs, spreadsheets, decks)
- API integrations between SaaS tools and AI services
- Browser extensions that read page content
- OAuth tokens granting AI agents persistent data access
Any one of these can be the leak path. Most organizations monitor none of them consistently.
Why is shadow AI so hard to detect
Part of the problem is behavioral. Software AG surveyed 6,000 knowledge workers and found 46% would continue using AI tools even if their organization banned them. Withum AI’s 2025 survey found 57% of employees actively hide their AI usage at work. This isn’t the junior employee problem people assume it is: Cybersecurity Dive’s 2026 research found 90% of security professionals themselves use unapproved AI tools.
The technical side is equally thorny. Shadow AI doesn’t announce itself. An employee accessing a personal ChatGPT account generates HTTPS traffic to openai.com. That looks identical to a sanctioned OpenAI API call. Without user-level identity resolution — correlating the individual user, the device, the data type accessed, and the destination — you can’t distinguish the two.
Traditional DLP tools were built for a world where data moves in predictable, structured ways: email, USB drives, file shares. They weren’t built to intercept a sales rep pasting customer PII into an AI prompt mid-conversation. And standard DSPM tools, while excellent at giving you a continuous inventory of where sensitive data lives at rest, have a hard ceiling here: shadow AI exposure is a runtime problem. The data isn’t sitting in a misconfigured S3 bucket. It’s moving in real time, through a channel no policy anticipated.
The Netskope 2026 Cloud and Threat Report puts the scale of the problem in plain terms: the average organization has over 1,550 distinct GenAI SaaS applications in use, up from just 317 in early 2025. Employees upload 8.2 GB of data to AI apps per month per organization. Most of that is happening outside of any security visibility.
Detection requires connecting three things that typically live in separate tools: what data was accessed (classification context), who accessed it and from where (identity and behavioral signals), and what they did with it at runtime (data movement and destination). When those layers are fragmented across a DSPM tool, a UEBA platform, and a DLP solution with different data models, the correlation that produces a detection signal doesn’t happen automatically — a human analyst has to make the connection manually, days or weeks after the fact.

What happens when employees use personal AI accounts at work
The Samsung leak in early 2023 is the clearest public case. Engineers pasted proprietary source code into ChatGPT during debugging sessions. The code leaked through the model. Samsung banned generative AI tools company-wide within weeks. That same year, employees at another major technology company were discovered sharing confidential internal code and strategy documents with an AI chatbot — similar outcome.
These incidents aren’t anomalies. They’re the predictable result of productivity incentives outpacing governance infrastructure.
When an employee uses a personal account to access an AI tool, the consequences compound:
No enterprise data retention controls: Consumer AI accounts may use input data for model training unless the user explicitly opts out — and most don’t think to. Once that data is in a training pipeline, deletion requests are complicated at best and practically unenforceable at worst.
No audit trail: Your organization has no log of what was uploaded, when, by whom, or what the model responded with. During a breach investigation, that absence of evidence makes containment nearly impossible — and regulators asking for a 72-hour breach notification window under GDPR or DPDP don’t accept “we didn’t know” as an answer.
No contractual protections: Enterprise AI tiers include data processing agreements, security certifications, and clear contractual terms around data handling. Personal free-tier accounts include none of that.
Persistent OAuth access: When an employee connects a personal AI tool to a work SaaS platform via OAuth — linking their personal Claude account to Google Drive, for example — the AI tool inherits whatever data access the employee’s account has. That access persists even after the employee is offboarded, unless someone specifically revokes it.
The core problem here isn’t just the leak itself. It’s that the blast radius is unknown. You don’t know what data went in, how sensitive it was, whether it was retained, or who else the model might surface it to. Scoping a shadow AI incident manually — pulling together query logs from a DAM, file access records from an endpoint agent, identity context from IAM — takes days. Most regulatory clocks don’t give you days.
How do enterprises prevent shadow AI data breaches
The instinct to ban doesn’t work. Software AG’s data showing 46% of employees would ignore an AI ban tells you what you need to know. Prohibition creates a hidden problem. Governance creates a visible one.
Effective shadow AI governance combines four operational components:
AI-aware data loss prevention: Standard DLP needs to be extended with policies that specifically target AI destinations — monitoring outbound data flows to known AI platforms, flagging uploads of files containing PII, source code patterns, or financial data. This needs to operate at the user level, not just the network perimeter. Critically, it needs to understand what the data means, not just whether it matches a regex pattern. A patient record copied into a chat window doesn’t look like a regex violation. Semantic classification catches it anyway.
Continuous data discovery across all environments: You can’t govern data exposure you haven’t mapped. DSPM-grade discovery — covering cloud, SaaS, endpoints, and on-premises — gives security teams a continuously updated picture of where sensitive data lives before it moves. That baseline is what makes AI-related exposure detectable: you know what’s sensitive, so you know when it goes somewhere it shouldn’t. Without that classification foundation, DDR and DLP are guessing at severity.
Runtime detection tied to behavioral context: Shadow AI exposure doesn’t look like malware. It looks like an authorized user accessing authorized data through an authorized device, then copying it somewhere unexpected. Detecting it requires behavioral sequence modeling — understanding that this user, accessing this data type, at this hour, sending it to this destination, is an anomalous pattern — not just a single-event alert. That’s DDR territory: correlating the classification context from DSPM with the behavioral signal from endpoint and network telemetry to produce a detection that fires on the pattern, not the individual event.
A usable approved AI access tier: Employees use shadow AI because approved tools either don’t exist or are too slow to procure. Enterprises that provide fast-tracked access to enterprise-tier AI tools — with clear data handling terms and security controls — see significantly lower unauthorized usage. The approved tool has to be genuinely useful, not a watered-down version that drives people back to their personal accounts.
Shadow AI governance policy enterprise teams need now
IBM’s finding that 63% of organizations lack formal AI governance policies, combined with only 34% auditing for unsanctioned AI, points to the same gap security leaders keep describing: the policy doesn’t exist yet, and the monitoring infrastructure to enforce it if it did doesn’t either.
A functional shadow AI governance policy for an enterprise security team needs to cover five things:
Approved AI tool registry: A maintained list of sanctioned AI tools with documented security reviews, data handling terms, and approved use cases. Updated quarterly as the tooling landscape shifts.
Data classification rules for AI inputs: Employees need explicit guidance on what data categories can be used with which AI tools. Source code, customer PII, M&A materials, and unreleased financial data should have categorical restrictions, not vague “use judgment” language. This only works if you have accurate, continuous data classification in place first. You can’t write a rule about customer PII if you don’t know where it lives.
Personal account prohibition with enforcement: The policy can’t just state that personal accounts aren’t allowed. It needs technical control CASB rules that block access to consumer AI platforms from corporate devices, or at minimum require authentication through a corporate identity provider.
Agentic AI review process: As AI agents take on autonomous tasks accessing files, executing code, making API calls each deployment needs a security review scoped to the data and systems the agent will touch. 61% of organizations currently have no governance technologies covering this. The exposure surface here isn’t a user making a bad judgment call; it’s an autonomous process with persistent access running outside any human oversight loop.
Incident response playbook for AI data exposure: When an employee reports they accidentally shared sensitive data with an unauthorized AI tool, teams need a defined process: who gets notified, what data classification applies, what regulatory notification thresholds apply, and what steps can actually limit downstream exposure. The organizations that contain these incidents fastest are the ones that already know exactly what data was at risk — because they had continuous classification running before the incident happened.

The fix isn’t a policy document
Most organizations respond to shadow AI risk by writing a policy and calling it governance. IBM’s data says 63% lack any policy at all, so writing one is a start. But policy without technical enforcement is just a document employees don’t read.
The organizations that will avoid the $670,000 premium on shadow AI breaches are the ones that combine an approved AI access program with runtime visibility into how data actually moves through AI interactions. That means knowing which AI tools your employees are using, what data is flowing into them — and having the classification foundation in place so you can answer, within hours rather than weeks, exactly what was exposed and how sensitive it was.
The 97% of breached organizations that lacked AI access controls when they were hit had the same risk exposure as the organizations that weren’t breached yet. The only difference was timing.
Matters.ai helps security teams close the shadow AI visibility gap — with continuous data discovery and classification across cloud, SaaS, and endpoints, DDR that detects anomalous AI-bound data movement in real time, and an AI security engineer that scopes and responds without waiting for manual correlation. See how it works →




