A year ago, one in five breached organizations found shadow AI somewhere in the story, some tool an employee had started using that nobody had approved and nobody was tracking. In IBM's 2026 Cost of a Data Breach report, it's closer to one in two. The number went from 20% to 43% in twelve months, and the breaches with shadow AI in them ran about $5.39 million each, roughly three quarters of a million dollars more than the year before.
The easy explanation is that AI tools spread faster than security teams could react. That's true, and it leaves out the more uncomfortable part. Most of those organizations were not ignoring the problem. IBM found that 68% of breached organizations had no AI governance policy in place, but a third of that group had one in development. They were working on it. The work just hadn't produced anything that reached an employee's laptop.
That distance between having a position on AI and having a control over it is the actual finding in this report. And closing it starts with seeing what's happening, not with restricting it. The order matters more than most companies expect.
The numbers describe an access control problem
Incidents involving an AI model or application hit 21% of breached organizations, up from 13%. Among the organizations that suffered an AI-related breach, 92% lacked proper AI access controls, which IBM defines as role-based access and multifactor authentication. Across all breached organizations, only 40% applied access controls to AI models and data at all.
None of that is exotic. Compromised APIs, applications, or plug-ins accounted for 27% of AI-related breaches, and cloud misconfigurations affecting AI workloads accounted for another 27%. These are failure modes every security team already knows how to handle. They're showing up on a surface that didn't exist three years ago, attached to systems nobody put in an inventory.
The consequences look like ordinary breach consequences too. Data loss or compromise in 49% of shadow AI incidents, operational disruption in 42%, and a regulatory fine in roughly one in five.
Why a ban moves the problem instead of solving it
The standard response to shadow AI is to name the approved tools and block the rest. We think that produces a predictable outcome: the employee with a deadline opens the same model on a personal account, on a personal device, outside every logging path the company controls.
A blocklist changes behavior on the sanctioned path. It has no effect on the unsanctioned one, which is where the risk was in the first place. What it reliably does is convert a visible problem into an invisible one, then report the drop in sanctioned usage as progress.
The people doing this are not adversaries. They're trying to finish work faster, using something that genuinely helps them, in an environment where nobody told them which uses are dangerous and why. A policy that treats them as the threat gets routed around by lunchtime.
Visibility first, then control
The order that works starts with three questions a security team should be able to answer about last week, not next quarter. Which AI tools did people actually use? What data did those tools receive? Which identity was behind each request?
Most companies can't answer any of them, which is why the policy conversation stalls. You can't write a meaningful rule about a system you can't describe. Once the answers exist, the controls become obvious and narrow: this team can send this class of data to this tool, everything else gets flagged, and the record of what happened survives the incident.
The approach that covers the most ground is putting a gateway in the path. Agents reach outside systems through MCP, a protocol that standardizes how a model asks a tool to do something on its behalf. If agents connect through one gateway instead of each reaching its tools directly, that gateway sees every request, and the record becomes a byproduct of the traffic rather than a project each team has to run separately.
That single position answers all three. Tool inventory stops being a survey nobody returns and becomes a registry: an unregistered tool doesn't connect, so what's in use and what's approved are the same list. Data exposure gets handled before the fact, because the arguments of every call pass through one place, and policy can strip or block a class of data on the way out instead of finding it in a log next quarter. Identity is where the change is largest. Most agent deployments authenticate with one shared service credential, so every action traces back to "the agent" and stops there. Requiring the calling user's identity on each request is what makes attribution possible, and it's also what makes offboarding work, since a departing employee's agents lose access along with their account.
A gateway sees agent traffic, not browser traffic, and plenty of shadow AI is a person pasting text into a chat tool in a tab. The controls for that are ones most companies already own. Putting AI vendors behind single sign-on makes usage visible in identity logs and gives you a revocation path. Egress monitoring catches the destinations. Expense reports catch more than security teams expect, since a new AI subscription usually appears on a credit card before it appears anywhere else. None of this reaches a personal phone, and nothing will.
What this costs to ignore
A policy nobody can enforce is a description of what a company would prefer. The jump from 20% to 43% in a single year is what happens when preference runs well ahead of instrumentation, and the access control numbers say the same thing from another angle: the organizations getting breached through AI are the ones that never got past intent.
The practical question isn't whether to allow AI tools. That decision was made for most companies by their own employees, months ago. It's whether the company can see what those tools are doing while there's still time to shape it. Right now, most can't, and the gap between the 43% and the 40% who applied any controls is the entire story of this year's report.
Before the next policy draft goes into review, ask what your team could actually answer today about last week's AI usage. If the honest answer is nothing, that's the first project, and the policy will be a better document for waiting.