AI access controls lag as breach costs fall in IBM data

At a glance

What this is: IBM’s 2025 breach data shows falling average breach costs alongside a widening AI access control gap that is now showing up as measurable breach impact.

Why it matters: IAM teams need to treat AI, NHI, and human access as one governance surface because uncontrolled machine access now changes breach cost, blast radius, and response speed.

By the numbers:

• 97% of organizations that experienced an AI-related breach lacked proper AI access controls.
• Shadow AI now contributes an additional $670K per breach.
• $4.44M.
• 16% of breaches involved attackers using AI, primarily for phishing and deepfake impersonation.

👉 Read Pomerium's analysis of IBM's AI breach risk findings

Context

AI security risk is no longer just about model misuse or prompt injection. The deeper issue is identity and access: when AI systems, plugins, and autonomous agents can reach internal data and tools without tight authorisation, the breach surface becomes a governance problem rather than a pure technology problem.

IBM’s 2025 breach data suggests that organisations are getting faster at containing incidents, but they are not closing the control gap around AI access. That matters for NHI, agentic AI, and human identity programmes because the same patterns keep repeating: long-lived secrets, weak oversight, and access granted faster than it can be governed.

Key questions

Q: How should security teams handle AI systems that need access to internal data and tools?

A: Security teams should treat AI systems like high-risk non-human identities and grant only request-scoped access. The key control is not whether the system can authenticate, but whether each action is checked against current context, purpose, and blast radius before it reaches internal resources.

Q: Why do AI systems increase the risk of credential misuse?

A: AI systems increase credential risk because they can reuse long-lived secrets across multiple tools and services at machine speed. Once a token or API key is exposed, the resulting access can spread much faster than a human-driven workflow, which makes standing privilege especially dangerous.

Q: What do organisations get wrong about shadow AI governance?

A: The most common mistake is treating shadow AI as a usage issue rather than an identity issue. Unmanaged AI tools create unsanctioned access paths, secrets, and data flows that bypass lifecycle controls, so discovery, approval, and revocation all have to include AI-connected identities.

Q: How do we know if AI access controls are actually working?

A: You know they are working when access decisions are granular, session-aware, and visible in logs that show exactly what the AI system requested and what it was permitted to do. If broad credentials still open multiple internal systems without per-request checks, the control is not effective.

Technical breakdown

AI access controls and the identity perimeter

AI systems become an access problem when they are allowed to authenticate, call tools, or move data without the same control discipline applied to human users. In practice, that means the security boundary shifts from the network edge to the identity layer, where permissions, context, and session behaviour determine what the system can reach. If AI agents, copilots, plugins, and APIs are permitted to act with broad standing privileges, the organisation has created an identity perimeter that can be traversed at machine speed. This is why Zero Trust principles matter here: every request must be authorised as if it were untrusted, even when it comes from a sanctioned internal workload.

Practical implication: map every AI-facing trust boundary to an identity control and remove blanket access to internal systems.

Why misused credentials matter more in agentic environments

The article’s core security message is that attackers are increasingly logging in rather than breaking in. That pattern becomes more dangerous when AI is involved, because long-lived secrets, API keys, and embedded credentials can be reused by automated systems across multiple services. Once an AI component has valid credentials, the attack path shifts from single-system compromise to rapid lateral movement, especially where toolchains, plugins, and internal APIs are loosely coupled. For identity teams, this is the same old credential problem with a faster execution layer and a larger blast radius.

Practical implication: treat every AI-connected secret as a high-risk identity artifact and eliminate persistent credentials where possible.

Continuous authorisation for non-human identities

Continuous authorisation is the control model that matters when access decisions cannot be safely made once and trusted for the rest of a session. For non-human identities, that means the system should verify context before each request, not just at login or token issuance. Static approval models fail because AI workflows can expand their own access path across tools, models, and data stores after the initial grant. In an environment where the same identity may touch internal APIs, model endpoints, and administrative surfaces, per-request evaluation is the only way to keep privilege aligned to current intent and context.

Practical implication: enforce per-request authorisation for AI and workload identities, not just at the point of authentication.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity controls, not model quality, are now the decisive AI security layer. The article is right to frame AI as a breach-cost issue, but the underlying mechanism is identity governance failure. When AI systems can authenticate, call tools, and access internal resources without explicit control boundaries, breach cost falls for defenders only if access is already tightly constrained. Practitioners should treat AI governance as an access-control problem first, and a model-risk problem second.

Shadow AI is an NHI governance problem with direct financial impact. Unsanctioned AI use behaves like unmanaged NHI sprawl because it introduces identities, secrets, and access paths that never entered governance processes. That creates a hidden inventory problem, then a containment problem, then a cost problem when incidents hit. The practical conclusion is that discovery and lifecycle control for machine identities now needs to cover AI-adjacent tools as well as traditional service accounts.

Short-lived access must replace static trust assumptions across AI, NHI, and human programmes. The article’s emphasis on misused credentials is a reminder that standing privilege is still the common failure mode. If AI systems inherit broad access from the same patterns used for humans and service accounts, the organisation simply accelerates old IAM mistakes. The field needs to move from possession-based trust to request-scoped authorisation, or every new AI integration becomes another standing privilege path.

Fine-grained authorization for AI agents is becoming the new Zero Trust test. This is where agentic access changes the governance conversation. If a system can choose tools, sequence actions, and execute without human approval, least privilege cannot remain a provisioning-time decision. The practitioner implication is that identity programmes must be able to prove not just who or what authenticated, but what the actor was allowed to do at each point in the workflow.

AI oversight gaps are compressing the distinction between breach prevention and containment. IBM’s data suggests that organisations with stronger identity controls and automation reduce breach costs and containment time, which means the governance line is moving into response outcomes. That matters because identity teams are now being judged on how much damage access control prevents, not just on whether access was formally approved. The practical conclusion is that identity, security operations, and AI governance have become one control surface.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• The governance gap is broad enough that organisations are already planning for dedicated NHI security capabilities, according to The State of Non-Human Identity Security.

What this signals

Shadow AI should now be treated as an identity inventory problem, not an innovation problem. Once unsanctioned AI use enters the environment, it behaves like unmanaged NHI sprawl and creates access paths that security teams cannot review, certify, or revoke cleanly. The most practical response is to extend discovery, entitlement mapping, and lifecycle governance to every AI-connected tool chain, including plugins and internal copilots.

Identity teams need a control model that can survive machine-speed decision loops. A once-per-login approval model is too slow for systems that can call tools and move data autonomously across services. The governance signal to watch is whether your programme can prove per-request authorisation for machine identities, not whether it can issue credentials quickly.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, the same visibility failure that has long affected NHI governance is now surfacing in AI integrations. That is why AI access reviews need to be built on the same discovery and lifecycle principles already used for workload and service-account governance.

For practitioners

• Inventory every AI-connected identity path Map copilots, plugins, agents, internal APIs, and model endpoints to the credentials and entitlements they use. Include sanctioned and unsanctioned tools so shadow AI does not remain outside the access review process.
• Replace long-lived secrets with request-scoped access Eliminate embedded API keys and shared tokens where AI systems touch internal data or tools. Use short-lived, identity-derived access so each request is evaluated in context instead of inheriting standing privilege.
• Apply continuous authorization to AI workloads Reassess access before each tool call or data request rather than trusting the original login event. This is especially important where agents can chain actions across services without human intervention.
• Unify human, NHI, and AI access governance Bring AI systems into the same governance model used for service accounts and privileged users. Access reviews, credential lifecycle control, and exception handling should all cover the full identity surface.

Key takeaways

• AI raises breach risk primarily through identity and access gaps, not just through model behaviour.
• The data point that matters most is control coverage, because 97% of AI-related breaches lacked proper AI access controls.
• Practitioners should unify AI, NHI, and human governance around short-lived, per-request authorization and full lifecycle visibility.

Key terms

• Shadow AI: Shadow AI is any AI system, assistant, or agent that is used without formal visibility or governance. It creates unmanaged identity, data, and access paths that security teams cannot easily review, certify, or revoke, which makes it a lifecycle and access-control problem as much as a policy issue.
• Per-request authorization: Per-request authorization means every action is checked at the moment it is made, not just when a session begins. For AI and workload identities, this is the difference between a one-time grant and a continuously evaluated control that can stop tool misuse, scope drift, or overreach.
• Non-human identity: A non-human identity is any credentialed machine actor such as a service account, token, certificate, workload, bot, or AI agent. The governance question is not whether it can log in, but whether its access is discoverable, limited, monitored, and removed on time.
• Standing privilege: Standing privilege is access that remains available by default instead of being issued only when needed. In AI and NHI environments, standing privilege increases blast radius because a leaked credential or overbroad grant can be reused immediately across tools, APIs, or internal systems.

Deepen your knowledge

AI access governance and non-human identity lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is starting to govern copilots, plugins, or autonomous agents alongside service accounts, this is a relevant place to build the baseline.

This post draws on content published by Pomerium: AI Is Your Biggest Security Risk. Read the original.