Shadow AI now has an invoice: about $670K on top of the average breach

The 2026 breach reporting has attached a number to a habit engineering teams already had. A dev.to post citing Verizon's 2026 DBIR says regular AI use on corporate devices went from 15% to 45% in a single year, and that 67% of that use runs through personal accounts the company cannot see ^[1][2]; the same post cites IBM's 2026 Cost of a Data Breach report finding that 43% of breached organisations reported a shadow AI incident as part of the breach, with unmanaged AI adding roughly $670,000 to average breach costs ^[5][6].

Multiply the two Verizon figures and about 30% of corporate devices are running AI through a channel with no logging, no retention control and no contract behind it ^[3]. That is a tripling of measured usage in twelve months, or thirty points of new exposure depending on how your risk register is written ^[4]. The post argues developers sit at the top of that adoption curve, having adopted first and having the most sensitive material to paste ^[12].

The concrete case is small and specific. In May, according to the post, the bank holding company CB Financial Services filed an SEC Form 8-K disclosing that an employee had processed customer names, Social Security numbers and birthdates through an unauthorised AI application ^[7]. The author describes it as the first regulatory filing they have seen where the incident itself is shadow AI, with no attacker involved ^[8]. Compare it to the 2023 Samsung episode, where engineers pasted proprietary source code into ChatGPT and a company-wide generative AI ban followed ^[9]. One produced a policy. The other produced a disclosure.

The prohibition reflex is the part worth arguing with. The post's claim is that banning the tools moves usage to phones and personal laptops, taking it from partially visible to fully invisible, which does not reduce risk so much as remove the telemetry ^[11]. The governance vacuum is real: ISACA's 2026 figures cited in the piece show 25% of organisations have no AI policy at all, and only about a third train all employees on AI ^[10].

The practical advice is unglamorous and mostly free. Sanitize before pasting, strip hostnames, internal URLs, customer identifiers and API keys; know the retention setting on every tool; treat AI browser extensions like production dependencies because anything that reads every page reads your admin consoles; never paste other people's data; and surface the tools you actually use so they can be licensed rather than hidden ^[13]. The retention point is where the money is: the post notes free consumer tiers often retain and may train on inputs while enterprise tiers usually do not, so switching accounts is most of the risk delta ^[14]. The author's structural claim is that the teams with the smallest shadow AI problem are the ones where admitting your toolchain is safe, not the strictest ones ^[15].

Two things to watch. First, whether CB Financial stays an outlier or whether "unauthorised AI application" starts appearing as a named cause in more 8-K filings, because that is the point at which shadow AI becomes a disclosure controls problem rather than a security awareness one ^[7][8]. Second, whether the ISACA no-policy share moves at all in the next cycle ^[10]. If your engineers cannot name the sanctioned tool, the sanctioned tool does not exist.