AI governance gaps are reshaping breach costs in IBM’s 2025 report

At a glance

What this is: IBM’s latest breach-cost research shows that AI governance maturity now affects both breach cost and operational recovery, not just innovation velocity.

Why it matters: For IAM, NHI, and AI governance teams, the report shows that unmanaged AI deployment can widen access, expand attack paths, and undermine control ownership across human and machine identities.

By the numbers:

• The 2025 Cost of Data Breach Report surveyed 600 organizations that experienced a data breach in the past year.
• The US average breach cost reached $10.22 million, an all-time high in the report.
• Organizations with extensive AI-driven automation in cyber defence saw breach recovery end 80 days faster and cost $1.9 million less.

👉 Read Swarmnetics’ analysis of IBM’s 2025 Cost of Data Breach Report

Context

Artificial intelligence is now part of the breach-cost equation because it changes how quickly defenders can detect, triage, and contain incidents. The article’s core point is not that AI is reducing risk on its own, but that governance quality, deployment discipline, and control visibility determine whether AI lowers losses or becomes another source of exposure.

For identity programmes, the overlap matters because AI systems often inherit access through APIs, plugins, service accounts, and embedded credentials. That creates a governance problem for human identity, NHI, and emerging agentic AI use cases at the same time, especially where shadow IT bypasses approval and lifecycle controls.

Key questions

Q: How should organisations govern AI tools that use enterprise data and APIs?

A: Treat every AI tool as a privileged integration, not a standalone productivity app. Require approval for the data it can touch, the connectors it can use, the human owner responsible for it, and the NHI credentials it depends on. Without those controls, the tool becomes a hidden access path rather than a managed service.

Q: Why do shadow AI tools increase breach risk so quickly?

A: Shadow AI bypasses normal procurement, security review, and entitlement management, so it often arrives with broad data access and weak ownership. If the tool uses API keys, service accounts, or plugins, attackers can exploit that delegated access just as they would any other unmanaged NHI. The risk is accelerated by the absence of lifecycle control.

Q: What breaks when AI governance policy is missing?

A: When policy is missing, organisations cannot prove who approved a deployment, what data it can access, or which controls apply to its connectors. That creates inconsistent approval, unclear accountability, and unrecovered access after the tool is no longer needed. In practice, missing policy turns AI adoption into unmanaged privilege expansion.

Q: Who is accountable when an AI tool causes data exposure or disruption?

A: Accountability should rest with the business owner of the AI use case, the technical owner of the integration, and the security function that approves access boundaries. For regulated environments, those responsibilities should be mapped to risk, audit, and incident response processes so AI systems are treated as governed assets, not informal utilities.

Technical breakdown

AI governance policy as a control boundary

In breach analytics, an AI governance policy is not a compliance document. It is the control boundary that determines who can deploy AI tools, what data they can touch, and whether their integrations are approved before production use. Without that boundary, AI adoption becomes a shadow access problem, because tools can reach internal systems through tokens, connectors, and application permissions that were never designed for uncontrolled reuse. The article’s figures show that governance gaps are already visible at population scale, not just in isolated teams.

Practical implication: treat AI deployment approval as an access-control decision, not only a technology review.

How AI tools extend the attack surface through connectors and plugins

The article points to supply chain-style incidents where an AI tool, app, API, or plugin became the entry point and then enabled access beyond the original system. That pattern matters because the real asset at risk is often the credential chain behind the integration, not the model itself. Once a connector is trusted, attackers can pivot from the AI interface into adjacent data stores, workflows, or privileged services. In practice, AI platforms behave like identity-integrated software with broad delegated permissions, which makes entitlement scope more important than the tool’s visible feature set.

Practical implication: inventory every AI connector as if it were a privileged integration with standing access.

Shadow AI and security debt in the identity plane

Shadow AI creates a security debt pattern similar to unmanaged NHIs. Employees adopt tools without lifecycle oversight, ownership records, or revocation paths, and those tools often carry machine credentials that outlive the task they were meant to support. That makes the identity plane the real weak point, because the organisation loses track of which human approved the tool, which NHI credentials it uses, and which systems it can reach. The report’s findings fit a broader trend: the fastest AI deployments are often the least governable ones.

Practical implication: tie every AI tool to an owner, a credential inventory, and an offboarding path.

Threat narrative

Attacker objective: The attacker’s objective is to convert a trusted AI integration into broader data access, operational disruption, or both.

1. Entry begins when an attacker abuses an AI app, API, or plugin, or when employees introduce shadow AI outside approved control paths.
2. Escalation follows when the trusted integration exposes data or services beyond the AI tool’s intended boundary, allowing the attacker to move deeper into connected systems.
3. Impact occurs when the attacker uses that access to disrupt operations, exfiltrate data, or extend compromise across the broader environment.

NHI Mgmt Group analysis

AI governance debt is now a breach-cost issue, not just a policy issue: when 63% of breached organisations still lack an AI governance policy, the market is already signalling that control design is lagging deployment speed. The consequence is that security teams inherit AI systems that are connected, data-rich, and weakly supervised from day one. Practitioners should treat governance maturity as a measurable risk reduction control, not an administrative checkbox.

Shadow AI is the identity problem most organisations are still undercounting: the article shows that ungoverned AI platforms and apps are entering workplaces through the same adoption patterns that created NHI sprawl. Once those tools have connectors, service tokens, or delegated API access, their identity footprint becomes a hidden attack surface. The important conclusion is that AI risk management now depends on inventorying the identities attached to the tools, not only on classifying the tools themselves.

AI security and NHI security are converging around delegated access: the most damaging failures are not model failures in isolation, but over-permissioned integrations that let one system speak for another. That is where IAM, PAM, and NHI governance intersect with AI oversight, especially for API keys, service accounts, and plugin-based workflows. Practitioners should assume that any AI system touching enterprise data has an identity lifecycle that must be governed explicitly.

Access review processes are too slow for AI deployment tempo: once AI tools are approved through informal routes, the access they accumulate often remains invisible until something breaks. The article’s breach-cost data reinforces a broader industry shift toward continuous authorisation, ownership, and revocation discipline. The practical conclusion is that organisations need lifecycle controls that match the speed of AI adoption, or they will keep paying for unmanaged access later.

AI governance standards are becoming operational prerequisites: the report aligns with NIST AI RMF thinking because the core problem is not whether AI exists, but whether organisations can govern it under accountable processes. For identity practitioners, that means linking AI oversight to control ownership, approval evidence, and entitlement boundaries across human and machine identities. The field is moving toward auditable AI governance, and teams that cannot trace delegated access will struggle to keep pace.

What this signals

AI entitlement sprawl is becoming a lifecycle problem, not a point-in-time approval problem: organisations that approve AI tools without binding them to owner, purpose, and offboarding evidence will keep accumulating unmanaged access. That is a governance failure because the control gap sits in the identity layer, where delegated permissions are easiest to forget and hardest to recover.

The practical response is to merge AI oversight with identity governance workflows, so human approvals, NHI credential scope, and connector review all sit in one operating model. For a standards lens, NIST Cybersecurity Framework 2.0 and NIST AI RMF both support this shift toward accountable, measurable controls, while OWASP NHI Top 10 remains useful where machine credentials are involved.

For practitioners

• Define an AI deployment approval gate Require every AI tool, app, API, or plugin to pass a documented approval step that records owner, business purpose, data scope, and assigned credential path before it reaches production.
• Map AI connectors to identity privileges Build an inventory of connectors, service accounts, API keys, and delegated tokens used by AI systems, then classify each one by data reach and privilege scope.
• Bring shadow AI into access governance Detect unsanctioned AI platforms through procurement, CASB, or endpoint signals, then force them into the same lifecycle controls used for other high-risk enterprise software.
• Shorten review cycles for AI-linked entitlements Reassess AI-related access on a tighter schedule than ordinary application access, especially where human users can add plugins or create new integrations without security review.
• Separate model risk from integration risk Assess AI system risk in two layers: the model itself and the credentials or permissions that let it touch enterprise data, because most real exposure comes from the second layer.

Key takeaways

• AI breach costs are increasingly shaped by governance quality, not only by attacker capability or defensive tooling.
• Unmanaged AI connectors, plugins, and shadow deployments create the same kind of hidden identity risk that NHI sprawl has long created elsewhere.
• Teams that tie AI approval to identity ownership, credential scope, and lifecycle revocation will be better positioned to limit both cost and disruption.

Key terms

• AI Governance Policy: An AI governance policy is the organisation’s rule set for approving, monitoring, and retiring AI tools. It defines who can deploy AI, what data they may access, and which reviews are required before use, so AI adoption stays inside accountable control boundaries.
• Shadow AI: Shadow AI refers to AI tools, apps, or services adopted outside formal security and procurement processes. These systems often bypass ownership, access review, and lifecycle control, which makes them difficult to audit and easy to abuse once they connect to enterprise data or credentials.
• Delegated Access: Delegated access is permission granted to one system to act on behalf of another, usually through tokens, keys, or API permissions. In AI environments, it can widen the blast radius if a tool inherits more access than its task really needs.
• Security Debt: Security debt is the risk accumulation that happens when organisations deploy technology faster than they govern it. In AI programmes, it appears when tools, connectors, and credentials are added before ownership, approval, and revocation processes are in place.

What's in the full report

Swarmnetics' full analysis covers the operational detail this post intentionally leaves for the source:

• How IBM’s survey framed AI governance policy maturity across breached organisations and why that matters for control design.
• The breakdown of AI-related breach types, including app, API, and plugin-driven incidents that moved beyond the AI tool itself.
• The reported differences between organisations with AI-driven defence automation and those without it, including recovery and cost impact.
• The report’s treatment of shadow IT AI use and why unapproved deployment paths complicate incident containment.

👉 Swarmnetics’ full post covers the AI governance findings, cost comparisons, and breach patterns in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It helps practitioners connect access discipline to the broader security programme they are responsible for.