For the first time, the breach data names AI as a top cost factor. This is what two of 2025's most-cited reports say about how AI is reshaping breaches, and where governance actually changes the outcome. Sources: IBM Cost of a Data Breach 2025 and MIT Project NANDA's State of AI in Business 2025.
The problem
AI is now the dominant new cost factor in data breaches
IBM's 2025 Cost of a Data Breach Report names two AI factors among the top cost amplifiers: shadow AI and sanctioned AI adoption. Together, they add more to the cost of a breach than any single non-AI factor.
- Shadow AI appears in 1 in 5 breaches (20%) — already a mainstream risk, not an edge case.
- AI-related incidents are just 13% of breaches, but the impact is outsized. Of those, 60% caused data compromise, 31% operational disruption, and 30% came via the AI supply chain (apps, APIs, plug-ins).
Shadow AI = employees using unsanctioned AI tools without employer approval.
AI factors rank among the top breach cost amplifiers
Security skills shortage amplifies the shadow-AI & AI-tools problem.
Cost added per breach (USD)
All 2025 cost amplifiers ranked. Both AI-related factors rank near the top, and their combined risk exceeds any single non-AI amplifier.
What gets stolen — shadow AI concentrates on PII and IP
Behind the cost numbers sits a simpler question: what data is actually being lost?
- Customer PII is the dominant breach target — and shadow AI makes it worse. 53% of all 2025 breaches involved customer personally identifiable information (PII). In shadow AI breaches that figure jumps to 65%.
- Intellectual property (IP) is the most expensive loss. It appears in 33% of breaches overall and 40% of shadow AI breaches, at $178 per record — the highest cost of any data class IBM tracks. In financial services, IP includes MNPI (material non-public information), which SR 11-7 and NYDFS Part 500 specifically require firms to govern.
- Employee PII appears in 37% of breaches overall and slightly less under shadow AI (34%), at $168 per record. Shadow AI drives up the loss of customer PII and IP — but not employee data.
Shadow AI breaches hit PII and IP hardest
Customer PII
$160/record
Intellectual property
$178/record
Employee PII
$168/record
Other corporate data
$154/record
Anonymized customer data
$115/record
% of breaches involving this data type
Data types compromised in 2025 breaches: overall rate vs. shadow AI rate, with cost per record.
Why this is a trajectory story, not a snapshot
Shadow AI didn't appear from nowhere. It grew out of the broader "shadow data" problem IBM flagged in 35% of 2024 breaches; the 2025 report carved out the AI-specific slice and added a second AI factor, sanctioned adoption. With employee AI use up an estimated 156% since 2023, both factors are compounding fast.
Known incidents that fit this pattern
- Samsung, 2023. Engineers pasted proprietary semiconductor designs into ChatGPT for debugging help. Samsung banned ChatGPT company-wide within weeks.
- DeepSeek, January 2025. A misconfigured database exposed chat history and internal logs for more than 1M users, including PII and API keys. Wiz Research disclosed the incident.
- Pharma clinical trial data, 2025. A major pharma found employees had uploaded clinical trial data to multiple AI tools — a potential FDA/EMA regulatory exposure worth tens of millions (Red Team Partner case write-up, March 2026).
The bottom line. The breach data and the incidents above point the same way: shadow AI concentrates on the most sensitive, most expensive, and most regulated data — and it leaks through everyday AI tools, not sophisticated attacks. That's the gap Meilynx closes. It sits inline in front of every governed AI call and runs PII and MNPI detection on prompts and responses in real time — with HIPAA Technical Safeguards supported through its compliance packs — so sensitive data is caught at the point of exposure instead of surfacing later in a breach report.
AI Controls
"Proper AI access controls" — what the 97% are missing
We mapped what the major AI security frameworks — AWS, NIST AI RMF, OWASP Top 10 for LLMs, Microsoft — say should be in place. The view below lays out the five layers and where adoption is weakest. (Adoption rates are directional, drawn from vendor surveys, not IBM.)
What “proper AI access controls” means — and where the gap lives
1. Identity & authentication
adoption ≈ 60%Includes SSO/MFA for users · Distinct identity per AI agent (not shared human creds) · mTLS service-to-service
Where it breaks Mature at user level. Gap: AI agents inherit human creds → over-permissioned.
2. Authorization & policy
adoption ≈ 40%Includes Model allow/deny lists · Per-team RBAC on prompts & tools · Tool/agent scope · Token rate limits
Where it breaks Largely absent — most enterprises route every team through one shared API key.
3. Runtime I/O controls
adoption ≈ 25%Includes Prompt injection detection · PII / MNPI / PHI filtering · Output scanning · Schema validation
Where it breaks Critical AI-specific control, often missing. OWASP LLM02 (Sensitive Info Disclosure) sits here.
4. Audit & evidence
adoption ≈ 35%Includes Tamper-evident logs of every prompt, response, decision · WORM storage · Examination export
Where it breaks Logs exist for IT systems but rarely for LLM calls. SR 11-7 / NYDFS 500 / EU AI Act require this.
5. Continuous monitoring
adoption ≈ 30%Includes Anomaly detection · Cost & token caps · Shadow AI discovery · Periodic audits
Where it breaks Even where policies exist, only 34% of orgs audit for unsanctioned AI (IBM 2025).
Five-layer view of AI access controls and where adoption is weakest.
The most common gaps (from vendor red-team reports)
- Shared API keys with no per-team scoping. Most enterprises route all teams' LLM traffic through one OpenAI/Anthropic key. There is no per-team RBAC, no model allow/deny, no token caps.
- AI agents inherit human credentials. An agent built to read Salesforce gets the engineer's full Salesforce permissions — including objects the agent should never touch. Token Security and Red Hat both call this out as the dominant 2026 access-control failure mode.
- No PII / MNPI filtering at the gateway. OWASP flags sensitive-information disclosure (LLM02) as a top-10 LLM risk — yet most companies never screen prompts or responses for it.
- LLM call logs are absent or non-tamper-evident. Companies have logs for IT systems and SaaS, but the prompt/response/decision trail for LLM calls is usually not captured. Regulators (NYDFS 500, SR 11-7, EU AI Act) increasingly require it.
Where Meilynx helps. Almost every gap above lives at the same chokepoint — the LLM gateway every governed AI call passes through. Meilynx enforces what's missing: model allow/deny and per-request cost caps instead of one unscoped shared key, PII and MNPI filtering on every prompt and response, and a tamper-evident, hash-chained log of who sent what to which model. It turns "proper access controls" from a survey checkbox into something you can actually enforce.
Governance Policies
"63% have no AI governance policy" — and what "having one" actually means
Policy on paper vs. policy enforced
Among the orgs that have a policy, fewer than half run a formal approval process for AI deployments, and only 34% audit for unsanctioned AI. Across all orgs, 61% have no technology to enforce policy at all.
AI governance maturity funnel — adoption decays at every step
n = 600 (IBM CODB 2025)
or still in development — 63% don’t
<50% of those with policies
61% lack governance tech (35% of those with a policy use it)
only 34% of those with policies
AI governance maturity funnel. Percentages compounded from IBM's published figures.
What separates the orgs with good governance from the rest
The strongest governance programs share five traits:
- Strict approval processes for new AI deployments — present in 45% of policies.
- Adversarial / red-team testing of models before production.
- Designated AI risk owner in legal/compliance, paired with a security counterpart.
- Mapping of AI controls to named regulations — SR 11-7, NYDFS 500, EU AI Act, ISO 42001, NIST AI RMF — rather than generic "best practice."
- Mandatory logging and audit of every AI deployment, with periodic shadow-AI sweeps.
Where Meilynx helps. A policy only matters if something enforces it — and 61% of organizations have no technology to do so, relying instead on training, attestations, and trust. Meilynx is that enforcement layer: it turns policy rules — model allow/deny, cost caps, content filters — into controls that run on every governed AI call, and it captures the tamper-evident, hash-chained log of prompts, responses, and decisions that SR 11-7, NYDFS 500, and the EU AI Act increasingly require. That's what closes the gap between policy on paper and policy in force.
Shadow AI
90%+ of companies have employees using personal AI accounts
Source and methodology
MIT Project NANDA's The GenAI Divide: State of AI in Business 2025 (July 2025) — built on 300+ disclosed AI initiatives, 52 organizational interviews, and 153 senior leaders — found that only about 40% of companies have an official enterprise AI subscription. Most AI use is happening on personal accounts, outside IT's line of sight.
A 50-point gap between sanctioned and personal AI use
AI tools employees report using
The adoption gap
Only about 40% of companies hold an official enterprise subscription, while 90%+ have employees on personal AI accounts. Tools are colored by how each is accessed — personal/consumer, enterprise-licensed, or unknown.
Independent shadow-AI research points the same way:
- Menlo Security 2025 (telemetry across hundreds of organizations): 68% of enterprise workers use free-tier AI through personal accounts, and 57% have pasted sensitive company data into them.
- Stack Overflow 2025 Developer Survey: 84% of developers use or plan to use AI tools in their workflow, with code generation as the dominant use case.
- Reco 2025 State of Shadow AI report: 71% of office workers use AI without IT approval, and 86% of organizations lack visibility into how data flows to and from AI tools.
Where Meilynx helps. The common thread across these surveys is invisibility — AI use running on personal accounts and unsanctioned tools, with no record of what data went where. Meilynx can't see what never touches it, and it doesn't claim to discover usage that bypasses it. What it does is make the sanctioned route the easy one: a single env-var change routes an application's LLM traffic through Meilynx, where PII and MNPI filtering and a full log of every prompt and response apply by default. The more capable that governed path is, the less reason anyone has to reach for a personal account — and for the traffic that does route through it, you see exactly which models and tools are in use.