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

At a glance

What this is: IBM's 2025 breach report shows that falling global breach costs mask a growing AI governance problem, with missing policies, shadow AI, and AI-enabled attacks affecting breach cost and recovery.

Why it matters: IAM, NHI, and AI security teams need to treat AI deployment controls as part of access governance, because unmanaged tools and privileges now influence both attack paths and recovery economics.

By the numbers:

• The 2025 report puts global average breach cost at $4.4 million, down for the first time in five years.
• The report says organisations using extensive AI-driven automation in defence recovered 80 days faster.
• IBM found that 63% of respondents still lacked an AI governance policy.
• IBM reported that 13% of breaches involved an AI tool.

Context

AI governance now sits inside the breach-cost problem, not beside it. The report suggests that organisations are no longer only paying for weak perimeter or identity controls, but also for unmanaged AI deployment, weak approval discipline, and poor oversight of tools that can touch data, workflows, and credentials.

For IAM and NHI practitioners, the governance issue is broader than model safety. AI assistants, plugins, and shadow apps create new access paths that can bypass normal onboarding, review, and offboarding discipline, which means identity governance must extend to how AI tools are approved, authenticated, and monitored.

The article treats the current maturity level as uneven, with some organisations already benefiting from AI in defence while many others still lack basic policy and approval controls. That split is now typical of the market rather than an edge case.

Key questions

Q: What fails when organisations let AI tools bypass approval and inventory controls?

A: The failure is governance visibility. Once AI assistants, apps, or plugins can be adopted without inventory and approval, the organisation loses track of what data they can touch, which permissions they inherit, and who owns their lifecycle. That turns ordinary tool use into an unreviewed access layer, which is why breach cost rises when shadow AI is present.

Q: Why does shadow AI create such a high breach risk?

A: Shadow AI creates high breach risk because it can access sensitive data outside normal oversight, then process or reproduce that data in places security teams do not control. Once the tool can read privileged information, the organisation may lose visibility into retention, logging, and downstream exposure.

Q: What signs show AI governance is too weak for security operations?

A: Common warning signs include no formal approval process for AI deployments, no clear owner for AI tools, and employees using assistants or plugins outside sanctioned channels. When those conditions exist, the organisation is likely treating AI as productivity software rather than as a governed access surface with identity and data implications.

Q: How should IAM and NHI teams respond to AI tools that access data and APIs?

A: They should treat them as governed non-human access paths. That means defining ownership, limiting data scope, reviewing permissions, and including AI tools in onboarding and offboarding processes. The key question is not whether the tool is intelligent, but whether its access can be controlled like any other privileged integration.

Technical breakdown

AI governance policy as an access control boundary

An AI governance policy is not just a compliance document. In practice, it defines which AI tools may be used, who can approve them, what data they may touch, and which workflows they may integrate with. Without that boundary, shadow AI and unsanctioned assistants can create unreviewed access paths that sit outside normal IAM, data protection, and change control. The report's emphasis on missing policy shows that breach cost is increasingly shaped by governance latency, not only by technical vulnerability exposure.

Practical implication: Treat AI approval rules as part of access governance, not as a separate policy exercise.

Why shadow AI changes the identity risk model

Shadow AI is unmanaged AI use by employees or teams, often through apps, assistants, or plugins that were never fully inventoried. That matters because the organisation then loses sight of what identities, tokens, and permissions those tools inherit. If a tool can reach mail, files, or APIs, it can become a delegated identity with a hidden blast radius. The report links shadow AI to higher breach costs because the organisation is not only responding to an incident, but also discovering an ungoverned access layer after the fact.

Practical implication: Inventory AI tools alongside human and non-human identities so delegated access cannot hide in unmanaged channels.

AI tools in breaches now include supply chain and social engineering paths

The article shows that AI-related incidents are not limited to a model being attacked directly. Many cases involve an AI app, API, or plugin in the supply chain, while other breaches use AI to polish phishing or generate deepfake impersonation. That means the risk sits across trust boundaries: third-party integration, identity proofing, and user reliance on machine-generated content. For defenders, the main issue is not whether AI is present, but whether its connection points are governed like any other high-trust integration surface.

Practical implication: Extend supplier, phishing, and identity verification controls to AI-enabled workflows and their integration points.

NHI Mgmt Group analysis

AI governance debt is now a breach-cost driver, not a side issue. The report ties breach economics to policy maturity, approval discipline, and the ability to govern AI tooling before it touches data or workflows. That makes governance lag a measurable security liability rather than an administrative gap. Practitioners should treat AI governance as part of core identity and access control.

Shadow AI creates a hidden delegated-access layer. Once employees can adopt AI assistants, apps, or plugins without inventory and approval, the organisation loses track of which tools inherit access to files, APIs, and collaboration data. That is a governance problem with IAM consequences, because the access path often looks like ordinary SaaS use until an incident forces discovery. Practitioners need explicit ownership for AI tool approval and lifecycle control.

AI-enabled breaches expose the boundary between tool security and identity security. The article shows that attackers can use AI for phishing, deepfakes, or supply-chain entry through integrations, which means the trust problem is broader than model safety. The relevant concept here is governed AI access surface: the set of AI tools, integrations, and permissions that must be treated as controlled access paths. Practitioners should govern that surface like any other privileged channel.

Recovery economics now reflect governance discipline. The gap between organisations with extensive AI-driven defence and those with weak policy suggests that preparedness is becoming a financial control as much as a technical one. This does not mean AI tools automatically reduce loss. It means organisations that can operationalise AI under a controlled policy model are better positioned to limit dwell time, disruption, and recovery drag. Practitioners should measure governance maturity in cost terms, not just policy counts.

From our research library:

• The global average cost of a data breach reached $4.99 million in 2026, up 12% on the previous year, according to IBM's 2026 Cost of a Data Breach Report.

What this signals

Governed AI access surface: the real control problem is no longer only model behaviour, but the access layer created by AI apps, plugins, and assistants. When those tools are allowed to inherit permissions without inventory and approval, they become part of the identity perimeter and should be managed as such.

Breach cost is now shaped by governance maturity as much as by technical defence. Organisations that do not control AI deployment pathways will keep discovering that the financial impact of an incident starts long before the first alert fires.

For practitioners

• Govern AI tools as access paths Map every sanctioned AI assistant, app, API, and plugin to an owner, approval route, and data-access scope before rollout.
• Inventory shadow AI with identity controls Add employee-used AI tools to discovery, access review, and offboarding processes so delegated permissions do not escape oversight.
• Require formal approval for AI deployments Make approval a prerequisite for any AI system that can read data, call APIs, or integrate into business workflows.
• Tighten third-party review for AI integrations Assess whether AI-enabled apps and plugins can move beyond their intended boundary, and block integrations that inherit broad access by default.
• Separate governance for defensive and user-facing AI Track AI used in security operations differently from employee productivity tools so one control model does not hide another's risk.

Key takeaways

• AI governance is now part of breach economics because unmanaged assistants, plugins, and apps can expand access without normal oversight.
• Shadow AI matters to identity teams because it creates a hidden delegated-access layer that traditional inventory and review processes often miss.
• The report points to a practical shift: AI tools must be approved, owned, and bounded like any other access path if organisations want to limit cost and recovery drag.

Key terms

• AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Governed AI access: Governed AI access is the approved use of AI services through defined identities, policy, and logging. It gives security and compliance teams a reviewable path for who may use which tools, what data they may submit, and how the resulting interactions are retained and monitored.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners build the control discipline needed for human and non-human access alike.