IBM’s 2026 breach cost data shows why exposure control now matters

At a glance

What this is: This is an analysis of IBM’s 2026 breach-cost findings for product security, with the central claim that AI, shadow AI, and supply-chain dependency are raising both breach frequency and breach cost.

Why it matters: It matters to IAM and security teams because AI systems, connected services, secrets, and access paths are now part of the same exposure surface, so identity governance must extend into software and AI delivery pipelines.

By the numbers:

• The global average cost of a data breach reached $4.99 million, up 12% year-over-year.
• AI-driven attacks increased 56% and added an average of $1 million to every breach.
• 43% of breached organizations
• Only 19% know precisely where AI code lives within their environments.

👉 Read Cycode’s analysis of IBM’s 2026 breach-cost findings for product security

Context

The core problem is exposure management that cannot keep pace with modern development and AI adoption. When organisations do not know where AI code, models, agents, secrets, and connected services live, they cannot control the identities and access paths that attackers are increasingly targeting.

IBM’s report treats breach cost as a business outcome of delayed detection, overextended trust, and weak governance across the software lifecycle. That framing is especially relevant for identity teams, because the same visibility gaps that create product security risk also create blind spots around machine identities, API credentials, and third-party access.

For product security programmes, the article’s starting position is typical rather than exceptional: many organisations are using AI faster than they can inventory it, which makes control design lag the actual attack surface.

Key questions

Q: What breaks when an AI agent is not part of identity inventory?

A: When an AI agent is not part of identity inventory, governance breaks at the point of discovery. Teams cannot reliably answer who owns the agent, what credentials it uses, or what systems it can reach. That makes access review, offboarding, and incident response incomplete because the trusted entity was never formally brought under control.

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 do security teams get wrong about AI in procurement?

A: They often focus on model capability and ignore governance boundaries. The real issue is whether the vendor can prove what data is used, who can access it, how it is retained, and whether the organisation has a clear opt-in decision before the capability becomes active.

Q: How should product security teams reduce exposure before AI reaches production?

A: They should require pre-production review of AI-generated code, dependency changes, service credentials, and connected integrations. The goal is to catch unauthorised access paths and excessive privilege before release, when remediation is still cheap and reversible. This is where prevention beats after-the-fact investigation.

Technical breakdown

Why AI-driven attacks change breach economics

AI-driven attacks compress the time defenders have to identify, escalate, and contain an incident. In practice, that means attackers can automate reconnaissance, prioritise high-value services, and move faster through exposed application paths, connected APIs, and cloud workloads. The cost increase is not only about more sophisticated payloads. It reflects a shorter defender decision window, more business disruption, and higher recovery effort across the environment. In product security terms, the attack surface now includes AI-generated code, agent workflows, and third-party AI services that may not be fully inventoried.

Practical implication: inventory AI assets and connected identities before they become ungoverned attack paths.

How shadow AI expands the identity and secrets problem

Shadow AI is unmanaged AI use outside approved workflows. That matters because every hidden model, agent, plug-in, or embedded service introduces credentials, tokens, permissions, and data flows that security teams may never review. IBM’s findings connect this directly to cost and disruption because unknown AI components are hard to monitor, hard to scope, and hard to revoke when risk appears. For IAM and PAM teams, the issue is not only access approval. It is lifecycle governance for machine identities and secrets embedded in code, pipelines, and runtime integrations.

Practical implication: tie discovery of AI services to secrets inventory and access lifecycle controls.

Why supply-chain and AI supply-chain risk converge

Modern software now depends on both traditional software supply chains and AI supply chains. Traditional dependencies include libraries, packages, and CI/CD tooling. AI dependencies include models, prompts, retrieval systems, agent frameworks, and generated code. Each dependency creates a trust relationship that can be abused if identity, provenance, or configuration controls are weak. That is why the most expensive incidents often start with compromised APIs, plug-ins, cloud misconfiguration, or a third-party relationship rather than the model itself.

Practical implication: treat software and AI dependency governance as one control plane, not separate risk registers.

NHI Mgmt Group analysis

AI exposure has become an identity governance problem, not only a product security problem. IBM’s findings matter because the risk is no longer limited to model quality or code defects. When AI assets, agents, and integrations are embedded in delivery pipelines, the security question becomes who or what can invoke them, with which secrets, and under what lifecycle controls. That is where IAM, PAM, and NHI governance intersect directly. Practitioners should treat AI inventory as an access inventory.

Shadow AI creates governance debt that looks like ordinary sprawl until it fails. Hidden AI services often carry unaudited credentials, unmanaged plug-ins, and unclear ownership. The result is a control environment where revocation is slower than deployment and policy cannot keep up with runtime change. This is a classic visibility gap, but one that now includes machine identities and AI-linked secrets. Practitioners should assume unmanaged AI is unmanaged access until proven otherwise.

Exposure reduction is now the economic control variable. IBM’s report reinforces a broader pattern across security disciplines: the earlier a vulnerable dependency, identity, or secret is found, the lower the breach cost. That makes preventive governance more valuable than post-incident optimisation. For identity programmes, the practical lesson is to shift from periodic review to continuous discovery and lifecycle enforcement across service accounts, API keys, and agent permissions.

Product security teams need a named concept for this problem: AI trust sprawl. AI trust sprawl is the accumulation of models, tools, APIs, plug-ins, and generated artefacts that each inherit implicit access. The risk is not just volume. It is the inability to explain, audit, and constrain every trust edge before attackers do. Practitioners should design for explicit trust boundaries across the full software and AI stack.

Detection-heavy operating models are still chasing yesterday’s exposure. IBM’s numbers show that many organisations are better at finding incidents than preventing the conditions that make them expensive. That pattern is familiar in identity security too, where stale credentials and excessive privilege often persist long enough to be exploited. Practitioners should reweight governance toward prevention, not just investigation.

What this signals

The next planning question for security leaders is not whether AI is in the environment, but where identity governance can still explain every access path. When AI assets, service accounts, and third-party integrations are managed as one estate, teams can reduce exposure before incident response becomes the only control left.

AI trust sprawl: the more models, agents, APIs, and generated artefacts an organisation adopts, the more implicit trust edges it accumulates. The practical signal is whether discovery, approval, and revocation can keep pace with deployment across the full software and AI lifecycle.

For identity teams, the lesson is to align NHI controls with product-security workflows such as dependency review, pre-production gates, and secrets lifecycle management. That alignment is what turns visibility into reduced breach cost rather than just better reporting.

For practitioners

• Inventory AI assets and their identities Map models, agents, prompts, plug-ins, APIs, service accounts, and tokens to named owners and business systems. No AI component should remain outside the access inventory, because hidden assets cannot be governed or revoked.
• Bind secrets to lifecycle controls Track API keys, tokens, and certificates used by AI and software pipelines with the same rotation, expiry, and offboarding rules applied to other non-human identities. Prioritise credentials that are embedded in code or automated workflows.
• Converge software and AI supply-chain review Review dependencies, third-party services, retrieval components, and generated code as one trust chain. Use the same approval, provenance, and exception handling process across both traditional software assets and AI artefacts.
• Shift controls left before deployment Move validation of AI-generated artefacts, dependency changes, and access entitlements into pre-production gates. The goal is to remove exposures before release rather than relying on detection after compromise.

Key takeaways

• AI-driven breach economics are rising because hidden assets, secrets, and dependencies are expanding faster than governance can keep up.
• The report’s cost data reinforces a familiar identity lesson: if you cannot inventory what holds access, you cannot contain what gets compromised.
• Product security and IAM teams should treat AI inventories, machine identities, and lifecycle controls as one operational problem, not separate workstreams.

Key terms

• 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.
• AI Trust-Path Sprawl: The accumulation of hidden or poorly governed access paths across AI models, orchestration layers, plug-ins, data pipelines, and connected services. It is an identity and governance problem because each path can expand who or what can read data, call tools, or trigger actions.
• Machine Identity: The digital identity of a machine, device, or workload — such as a server, container, or VM — used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
• Agentic Development Lifecycle: The Agentic Development Lifecycle is the control pattern for building, approving, deploying, and reviewing AI agents before they reach production. It extends software change discipline into identity governance by requiring traceability for creation, access grants, business purpose, and ongoing oversight.

What's in the full article

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

• Cycode's breakdown of how IBM quantified cost reductions across DevSecOps, IAM, and security automation.
• The article's product-security interpretation of AI-driven breach economics and where prevention outperforms response.
• The discussion of how AI agents, models, and third-party services alter the attack surface across the development lifecycle.
• Cycode's framing of where Cycode's own Agentic Workflows and Context Intelligence Graph fit into operational prioritisation.

👉 The full Cycode post expands on AI-driven breach economics, supply-chain exposure, and prevention-first controls.

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 control. It is designed for practitioners who need to connect identity governance to real operational risk.