The Cost of Untrusted AI.

IBM's own cost table contains both halves of the argument.

In IBM's 2025 chart of factors that raise or lower average breach cost, adopting AI and governing AI appear as separate line items — pointing in opposite directions.

Adopting AI raises breach cost. Governing it lowers breach cost.

The gap between those two numbers is the entire market this report addresses.

IBM's methodology caveat travels with these numbers

These figures come from a self-reported cross-sectional survey of 600 organizations breached between March 2024 and February 2025, analyzed with activity-based costing. They are correlational, not causal, and the sample is small relative to the number of factors reported. They are per-factor deviations from a baseline — they are not additive, and no organization can claim their sum. This is a caveat IBM states, and one the report repeats wherever these numbers appear.

Finding 02 — Complexity

The second-largest amplifier is the security stack itself.

Most controls in this market enforce at one layer, and each holds its own policy. A single policy change therefore means changing several systems — which then disagree with each other. The disagreement is not a configuration accident; it is the predictable result of storing the same intent in several places.

That is the structural argument for one policy plane consumed by every surface, and the report maps it to a named file path rather than to a diagram.

Source: IBM/Ponemon, Cost of a Data Breach Report 2025, cost-factor chart. Same methodology caveat as above — correlational, per-factor, not additive.

Finding 03 — The realized-loss picture

Almost all the money that has moved so far moved because a person was deceived.

The report catalogs 36 AI security incidents from 2023 to 2026, each verified against primary sources. The pattern is not the one most vendors describe.

Source: incident database compiled in Part II of the report, 36 incidents 2023–2026, each verified against primary sources. Reported losses are a floor — a tally of what victims disclosed — not an estimate of total market loss.

The same deception, counted nationally.

In April 2026 the FBI's Internet Crime Complaint Center published its first dedicated AI-fraud section. It records the same phenomenon as the finding above — a person deceived — across a national complaint population rather than a 36-incident sample.

IC3 2025 — first dedicated AI-fraud section

Source: FBI Internet Crime Complaint Center (IC3), Internet Crime Report 2025, released April 2026; §13 of the report. Victim-reported losses — see the measurement note below.

Three numbers, three measurement classes

IC3 counts dollars that victims themselves reported to the FBI over one year — a national tally of self-reported complaint losses. IBM's figures are modelled averages and per-factor deviations drawn from a survey of 600 breached organizations. The two are different measurement classes and cannot be combined: a national victim-reported total may not be added to, netted against, or divided into a modelled per-breach average, and no arithmetic joining them produces a meaningful number. The report never performs it, and neither should a reader of this page.

Nor are US$69.3M and US$893M competing figures. US$69.3M is what 36 individually verified incidents disclosed in this report's own ledger. US$893M is what IC3 recorded nationally across 22,364 AI-referencing complaints in a single year. Same phenomenon, counted once by incident sample and once by victim report. The larger number does not correct the smaller one — it sizes the field the smaller one samples.

Why the case does not rest on the realized-loss ledger.

The realized-loss table is a lagging indicator, and a young one. The leading indicators are the near-misses.

• A zero-click exfiltration flaw in Microsoft 365 Copilot, patched before exploitation.
• Remote code execution in a developer IDE from a one-line configuration edit.
• Roughly a hundred genuinely malicious models live on a public model hub.
• In July 2026, an autonomous agent framework that escaped an evaluation sandbox and reached production infrastructure at Hugging Face.

Sources: each near-miss is documented in Part II of the report with its primary source, disclosure timeline, and taxonomy mapping.

Finding 04 — The rating discipline

An earlier draft produced five High ratings. External review cut it to one.

A High applicability rating requires a shipped enforcement point in the relevant execution path — not merely a control of the right category. Applied honestly, that rule produces a table that is deliberately unflattering in places.

External review found the standard had been applied too loosely, so every rating was re-derived against the published rubric. That restraint is the reason the rest of the document can be trusted.

Source: rating rubric and per-incident derivations are published in Part II of the report; the capability-to-code map is Appendix A.

Everything else the report is able to cite.

Every figure below carries its source. None is a CyberArmor estimate.

Statutory maxima

Unlike breach costs, statutory penalties are not estimates — they are published maxima in legislative text.

Ask every vendor for the same two things.

“A buyer comparing vendors should ask each of them for the same thing: the list of incidents their product would not have helped with, and the code path for every incident they claim it would.”

— The Cost of Untrusted AI, §10, “How to read Part II”

That is a question this report was written to be able to survive. The list of incidents CyberArmor would not have helped with is in Part II, and it is long: 19 of 36 rated Low, including the single costliest incident in the database. The code path for every incident where applicability is claimed is in Appendix A, named file by named file.

Ask us the same question you ask everyone else. Then ask them for the two lists, and see who can produce both.

The full report. No form in the way.

The 15-minute proof of concept is ungated and the capability status page is ungated. Gating the research would contradict the one thing that makes any of it credible.

CyberArmor.AI · July 2026 · 76 pages · 36 incidents verified against primary sources. Partners and prospects are welcome to forward this link directly — there is no wall behind it.

Ready to Control and Prove AI Activity?
Let's Talk.

See how CyberArmor.AI maps to your AI activity, data leakage risk, agent workflows, provider usage, runtime controls, and evidence needs. The best demos start with the control problem you already have.

No spam. No hard sell. Every request is reviewed personally.