Shadow AI Is in 43% of Breaches Now, and the $670,000 Figure Is a Year Old

Shadow AI now appears in 43% of breached organisations, up from 20% a year earlier. The average breach involving it cost $5.39 million. Most coverage still quotes the older $670,000 figure. That number described a different comparison in a different year. The category moved faster than the commentary about it, and the governance numbers moved the wrong way.

The short answer

Shadow AI is employee use of AI tools your organisation has not approved, or does not know about. IBM's 2026 breach study found it in 43% of breached organisations. The average cost was $5.39 million per breach. In 21% of those incidents the organisation paid a regulatory fine.

What shadow AI means inside a breach report

Shadow AI is the AI equivalent of shadow IT. It covers tools and models an employee brings into the work of the company. There is no security review, no contract, and no record in the asset inventory.

The definition matters because it is narrower than the way the phrase gets used in vendor marketing. A salesperson pasting a customer list into a personal chatbot account is shadow AI. So is an engineer wiring a model API into a production service on a personal card. So is a department buying a niche AI tool on expenses.

What sits outside the definition is equally important. An approved copilot used badly is a training problem, not shadow AI. A sanctioned model that hallucinates is a quality problem. Confusing those categories produces governance programmes that measure the wrong thing. Then they report progress on it.

The category exists at all because it now has a price attached. IBM added shadow AI as a cost factor in the 2025 edition of its annual breach study. By the 2026 edition it had become one of the largest amplifiers the study tracks. Categories get invented when the money becomes visible.

The 43% number, and why $670,000 is out of date

The IBM Cost of a Data Breach Report 2026, published on 30 July 2026, is the reason this topic has moved. Ponemon Institute conducted the research across 602 organisations that suffered a breach between March 2025 and February 2026. It draws on 3,558 interviews across 17 industries.

Two figures did the work. Shadow AI incidents climbed to 43% of breached organisations from 20%. The average cost of those breaches rose to $5.39 million from $4.63 million. The global average breach cost across all causes was $4.99 million, up 12% and a record for the series.

What changed between the two reports

Adoption changed, and controls did not keep pace. The 2025 report described a category most security teams had heard of and few had measured. The 2026 report describes one that has arrived in nearly half of all breach investigations.

The governance data explains the mechanism better than the cost data does. Only 40% of breached organisations applied access controls to AI models and data at all. Among those who suffered an AI-related breach, 92% had no proper access controls in place. That is an improvement on the 97% in the prior edition. It is not a number anyone should be relieved by.

The premium and the total are different numbers

Here is the part almost every summary gets wrong. The famous $670,000 came from the 2025 report. Breaches at organisations with high levels of shadow AI averaged $4.63 million there, against $3.96 million at organisations with little or none. That is a premium between two groups.

The 2026 headline of $5.39 million is a total, not a premium. Subtracting the $4.99 million global average from it produces roughly $400,000. That arithmetic compares shadow AI breaches against all breaches, not against breaches at low shadow AI organisations. The two are not interchangeable. Treating the smaller gap as evidence the risk is shrinking would be a mistake.

My reading is that the premium probably widened rather than narrowed. The cost of the affected group rose 16% while the overall average rose 12%. I would not publish that as a finding. The honest statement is narrower. The comparable premium has not been disclosed in the 2026 edition. Anyone quoting $670,000 in August 2026 is quoting a figure that describes last year's population.

Both editions draw on roughly 600 breached organisations and are self-reported. The samples are different companies, so movement blends real change with sample change.

What a shadow AI incident actually does to you

Cost averages are abstract. The consequence data is more useful for anyone explaining this to a board. It describes outcomes a non-technical director can picture.

Of the shadow AI incidents recorded in the 2026 study, 49% resulted in data loss or compromise, 42% caused operational disruption and 35% produced reputational damage. In roughly one in five, the organisation paid a regulatory fine.

That fine rate is the number I would put in front of a finance director. At 21% it is now a budgetable line. Commercial terms decide who carries that exposure, which is the subject of the piece on the AI contract clauses a CFO should insist on.

The wider report explains why these incidents run expensive. Mean time to identify and contain a breach reached 247 days, six days worse than the prior year. An unapproved tool has no owner, no logging and no runbook. Every hour of that 247 is harder than it would be on a sanctioned system.

Why unsanctioned use keeps growing anyway

Nobody adopts shadow AI to be difficult. They adopt it because the unapproved tool finishes the task. The approved one does not exist yet, or exists and is worse.

Personal accounts are the exposure surface

The clearest measurement comes from network telemetry rather than surveys. Netskope inspects cloud traffic for its customers. Its 2026 threat research reported that 47% of workplace generative AI users were on personal accounts, down from 78% a year earlier. The data most often caught in policy violations was source code, regulated data and intellectual property.

This is vendor telemetry, a weaker source class than a regulatory filing. The sample is Netskope's own customer base. Read the direction rather than the decimal. It says two things at once. Personal account use is falling sharply, and it is still roughly half of all workplace AI activity.

Source code deserves separate attention. It is the category where engineers most often reach for whatever tool is fastest. That tradeoff runs through the analysis of when to build rather than buy coding agents. The security answer usually decides the build question before the cost answer does.

Blocking has a poor track record

The instinct is to block the domains and move on. It rarely holds, for a reason that predates AI by twenty years. People route around controls that stop them doing their job. They route around them onto devices you cannot see.

Microsoft and LinkedIn measured the same behaviour in their 2024 Work Trend Index. It found that 78% of AI users were bringing their own tools to work, rising to 80% at small and medium companies. That study is now two years old and the specific rate has certainly moved. It established the pattern early: this is demand-led adoption, not a discipline failure.

Free tiers make the economics worse. A capable model at no cost through a personal login is the path of least resistance for anyone facing a deadline. The metering behind those tiers is examined in the breakdown of what free AI tiers actually cost the vendor.

Finding shadow AI with data you already have

Most teams believe discovery requires a new tool. It usually does not. Five signal sources exist inside almost every company already. Correlating three of them will produce a defensible inventory in about a week.

Five signals, ranked by effort

Start with the cheapest and stop when the picture stabilises. The point of the exercise is a list of tools, owners and data classes, not a perfect count.

No single row is sufficient. The free tier gap in row three is why expense data alone gives a comforting and wrong answer.

This is the same discovery problem as software sprawl, and the same methods apply. The inventory work described in the piece on rationalising an estate of 291 applications transfers directly. If your company has already done a SaaS discovery exercise, you are two thirds of the way through this one.

One framing choice will save you an argument. Publish the inventory as a map, not a charge sheet. The first team to be disciplined for appearing on it is the last team that will tell you anything.

A classification that survives contact with a real team

An inventory without a classification is a list nobody acts on. The useful cut is not by tool and not by department.

Classify by the data, not by the tool

Tool-based rules go stale in weeks because new tools appear weekly. Data-based rules hold, because the sensitivity of a customer record does not change when a new model launches. Write the rule once against the data class and it survives the next product cycle.

The bottom two rows are where most governance programmes lose credibility. Applying regulated-tier process to public data trains people to ignore the whole policy.

Each discovered tool then gets one of three verdicts. Sanction it and put a contract behind it. Wrap it, meaning allow it through managed accounts with monitoring but without a full procurement cycle. Or block it and name the replacement in the same sentence. A block without an alternative is a request that will be refused quietly.

Agent-based tools need a fourth question. What is the tool permitted to do, rather than permitted to see? Where that authority is unclear, the remedies are thin when an agent acts wrongly. That is set out in the review of liability caps and remedies in AI agent contracts.

The alternatives people actually adopt

The single highest-return move available is unglamorous. Give people the same class of tool through an account you control. Netskope's telemetry shows personal account use falling from 78% to 47% in a year. That migration is already happening at scale, and it works when the managed option is genuinely equivalent.

Equivalence is the hard part. If the approved tool is a slower model behind an approval queue, the migration stalls. The shadow usage persists on phones. I would rather sanction a good tool with imperfect terms than mandate a poor tool with excellent ones. Only one of those two gets used.

The governance side needs the same realism. Two thirds of breached organisations had no AI policy in place. The share with a policy fully implemented actually fell to 32% from 37%. The share with a policy in development rose to 33% from 22%. Drafting went up and implementation went down. That is what a governance programme looks like when it is staffed by committee rather than by an owner.

One more finding is worth acting on, and it points the other way. Organisations using security AI and automation extensively saved an average of $1.93 million per breach. They contained incidents 65 days faster. Only 36% used those tools extensively. The same technology that created this risk category is also the most effective single reducer of breach cost in the study.

Pilots of that tooling fail for ordinary reasons rather than exotic ones. The failure modes are catalogued in the breakdown of why agent pilots stall. The pattern that shows up repeatedly is a deployment with no owner and no baseline. That is the same defect that makes shadow AI expensive.

Where this argument is weakest

The numbers above are the best available. They are not as strong as their circulation implies, and here is why.

Correlation is doing a lot of work here

The study shows that breaches involving shadow AI cost more. It does not show that shadow AI caused the extra cost. An organisation with widespread unapproved AI use very likely has weak asset management, weak access control and thin security staffing. Each of those independently raises breach cost.

Shadow AI may therefore be partly a marker of a disorganised environment rather than the mechanism of the loss. IBM does not claim causation. The honest reading is that some meaningful share of that $5.39 million belongs to the conditions that allowed shadow AI, not to shadow AI itself.

The sample excludes the largest breaches

The study covers roughly 600 organisations. It historically restricts itself to breaches in a bounded record range, which excludes the enormous incidents that dominate news coverage. The reported figure is a mean of self-reported, activity-based cost estimates. It is sensitive to a handful of expensive cases and is not a median.

Two further limits deserve stating. The base for every percentage here is organisations that were already breached. So 43% is not the shadow AI rate in the general economy, and it should never be quoted that way. IBM also sells AI security and governance products, sponsors the research, and publishes findings that align with its catalogue. That does not make the numbers wrong. It does mean the framing has an interested party behind it. No independent replication of this specific finding exists yet.

Frequently asked questions

Where to start this week

Two things, and neither needs budget approval.

First, pull 30 days of DNS or egress logs and your identity provider's OAuth consent list. Write down every AI destination that appears. Sort the result by the sensitivity of the data those teams handle, not by traffic volume. That ordering is the whole prioritisation, and it takes an afternoon.

Second, pick the single highest-volume unapproved tool and answer one question about it in writing. What would the sanctioned equivalent have to do for this team to switch voluntarily? If the answer is nothing you can deliver this quarter, sanction the tool with terms. A block you cannot enforce is not a control.

Related reading