IBM published its annual Cost of a Data Breach Report on July 29. The 2026 edition studied 602 breached organizations across 17 industries and 16 countries, covering incidents from March 2025 through February 2026. The average breach now costs $4.99 million, up 12% in a year.
Buried under the headline number is the finding that should reorganize your week: among organizations that were attacked through their AI models, 92% had no access controls on those systems.
The expensive new attacks in IBM's report, model inversion and prompt injection, cost about $6 million each. But 92% of the organizations they hit had skipped a control that predates AI entirely: deciding who can reach the system. Only about 4 in 10 organizations limit access to their AI at all. The fix is unglamorous. Put your identity stack in front of every model, scope retrieval to what each user may see, and log every interaction. Your architecture decides whether you can actually do that.
What did IBM actually find?
The report reads like a checklist of things security teams already know how to do, not done. The numbers that matter for AI:
| Finding | Number |
|---|---|
| Average cost of a breach, all causes | $4.99M, up 12% |
| AI-breached organizations lacking access controls on the AI | 92% |
| Organizations that limit access to their AI systems at all | About 4 in 10 |
| Cost of a model inversion incident | About $6.07M |
| Cost of a prompt injection incident | About $5.89M |
| Shadow AI incidents vs. last year | Doubled |
| Organizations with no shadow AI governance | More than two-thirds |
IBM's researchers describe the new attack class as behavioral: instead of compromising a server, the attacker manipulates how the model reasons and responds. That is different from a traditional exploit, and it is why recovery costs run higher. You are not restoring a system. You are figuring out what an AI was talked into.
But notice what had to be true first. To manipulate a model, you have to reach it. In 92% of these cases, nothing was checking who could.
Why does access control fail on AI first?
Because AI enters the building through a side door. A database gets provisioned by people who wire it into the identity stack on day one. An AI tool arrives as a pilot, a browser tab, a feature a vendor switched on inside software you already license. Nobody provisions it, so nobody restricts it. The report's shadow AI numbers say this is getting worse: incidents doubled in a year, and more than two-thirds of organizations have no governance for AI that staff adopted on their own. We wrote about finding shadow AI before an auditor does, and the advice has not aged.
Agents raise the stakes again, because an agent is a non-human identity that acts on its own schedule. An agent with broad credentials and no tool restrictions is the 92% problem with hands.
What does an access control on an AI system look like?
The same thing it looks like everywhere else. Four layers, in the order an attacker would meet them:
Identity in front of the model. Nobody queries it without authenticating through your identity provider. This sounds obvious. It is the control 6 in 10 organizations have not applied.
Permission-aware retrieval. When the AI searches your documents to answer a question, it should only search what the asking user is cleared to see. Filtering after retrieval is too late, because the model has already read the document. We covered the mechanics in permission-aware RAG.
Scoped agents. Agents run under the calling user's credentials, with an explicit list of tools they may use and human approval on actions that leave the building.
A log you would show an auditor. Who asked, what was retrieved, what came back, who approved. Without it, an AI incident is unfalsifiable: you can't prove what leaked, so you have to assume everything did.
Our guide to implementing AI access controls walks through the full build.
Does running AI privately fix this on its own?
No, and anyone who tells you otherwise is selling placement instead of security. A self-hosted model with no authentication in front of it is an open endpoint that happens to be on your rack.
What a private deployment changes is enforceability. When the model, the retrieval index, and the logs run inside your network, the access rules come from the identity stack you already operate, and you can inspect every layer directly. You are not reading a vendor's trust page to learn whether your controls exist. Cognetryx is built on that premise: retrieval honors your existing permissions before the model ever sees a document, agents run scoped and approved, and every interaction is written to a log you hold. The controls IBM found missing are the product.
What should you do this quarter?
The report says 85% of breached organizations plan to increase security spending. Before the budget goes to new tooling, three moves close most of the gap IBM measured:
1. Inventory. List every AI system in use, including the embedded features your vendors shipped without asking. Shadow AI doubled last year; the list is longer than you think.
2. Identity, everywhere. Every model on the list goes behind your identity provider with least-privilege scoping. Anything that can't be put behind it gets a harder question: why is it still on the list?
3. Logging. Turn on interaction logging you could hand to an examiner, and check that someone reads it.
The attacks in IBM's report are new, and the research behind them will keep evolving. The condition that let them work is a door nobody locked, and you can fix that one this quarter.
See where your AI access controls stand
A short assessment maps every AI system you run against the controls IBM found missing: identity, permission-aware retrieval, scoped agents, and logs you hold.
Book a Free AI Strategy Assessment