AI access controls lag as breach costs fall in IBM data

At a glance

What this is: Pomerium argues that falling breach costs mask a widening AI access-control gap, where poor governance around AI-related identities and shadow AI drives breach exposure.

Why it matters: For IAM, PAM, and NHI teams, the finding matters because AI security failures increasingly look like identity failures, so access control, lifecycle governance, and continuous authorisation have become core controls.

By the numbers:

• The global average cost of a data breach fell to $4.44M in IBM’s 2025 report.
• 97% of organisations that experienced an AI-related breach lacked proper AI access controls.
• Shadow AI added an additional $670K per breach.

Context

AI access controls are the decision layer that determines who or what can reach internal resources, under what conditions, and for how long. In this article, the governance problem is not model performance but the identity and authorisation model surrounding LLMs, copilots, plugins, and autonomous agents.

Pomerium frames the issue as an overshoot in AI adoption paired with lagging identity governance. The result is a control gap in which shadow AI, compromised credentials, third-party access, and AI-driven impersonation all expand breach exposure faster than traditional IAM and VPN-based controls can contain it.

IBM’s breach data is used here as the trigger for a broader programme question: when AI systems can authenticate, invoke tools, and move across environments, existing access governance assumptions stop holding. That is a current-state NHI and agentic access problem, not a future one.

Key questions

Q: What breaks when AI agents keep standing credentials?

A: The access model breaks because the agent can continue acting after the human has moved on, the workflow has shifted, or the original approval is no longer relevant. Standing credentials turn delegated authority into unattended authority, which is especially risky when agents can retry, chain tools, and move quickly across systems.

Q: Why do AI-related breaches look more like identity failures than model failures?

A: Because the common pattern is misuse of existing access, not exploitation of the model’s reasoning. Attackers, insiders, and shadow AI all benefit when authorisation is weak, credentials are durable, and access checks happen only at login. The model may be the visible surface, but identity is the control plane that fails first.

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

A: They are working only if you can answer three questions consistently: which identity accessed the system, which data it touched, and whether that access matched the intended business use. If audit logs cannot produce that chain, the control is partial and the exposure is still active.

Q: How should teams govern AI assistants, workflows, and autonomous agents differently?

A: Teams should govern them by runtime behaviour, not by model family. Assistants need strong prompt and response controls, triggered workflows need untrusted-input screening and narrow tool scope, and autonomous agents need separate identities, scoped delegation, and traceability across each decision. A single AI policy rarely fits all three.

Technical breakdown

Why AI access controls fail when identity is the perimeter

AI systems do not create a separate security model. They inherit the same trust decisions that IAM already makes for humans and NHIs, but they often execute those decisions at machine speed and across multiple tools. When access is granted through long-lived secrets, embedded credentials, or broad service permissions, the effective control boundary moves from policy to possession. That is why the article repeatedly returns to identity-aware, context-aware, continuous authorisation. The technical failure is not simply that AI exists, but that older network and VPN controls were never designed to decide each request on current identity, context, and purpose.

Practical implication: Treat AI access as a request-by-request authorisation problem, not a network placement problem.

How long-lived secrets and autonomous plugins expand blast radius

The article notes that AI agents authenticate using long-lived secrets and that APIs and plugins can act autonomously across systems. That combination creates a blast radius problem: once a credential is accepted, the system may chain multiple actions without fresh review. In NHI terms, the risk is not just credential exposure, but credential reuse across services, tools, and administrative surfaces. The more autonomy the workflow has, the less useful static perimeter assumptions become. Fine-grained permissions matter only if issuance, scope, and revocation are continuously governed.

Practical implication: Remove durable credentials from AI workflows and constrain each tool path to a narrow, revocable scope.

Why zero trust for AI agents depends on continuous authorisation

Zero Trust for AI agents is not a slogan. It means every request is treated as untrusted until identity, context, and authorisation are checked at the point of use. For autonomous or semi-autonomous systems, this matters because a single approved session can fan out into multiple downstream actions if no per-request policy layer exists. The article’s emphasis on continuous verification aligns with this pattern: access must be evaluated in motion, not just at login. Without that, AI agents become high-speed amplifiers of whatever standing access they already hold.

Practical implication: Enforce per-request policy checks for agents, APIs, and internal admin surfaces instead of relying on session start controls.

Threat narrative

Attacker objective: The attacker’s objective is to exploit trusted access paths inside AI-enabled environments to expand reach, persistence, and breach impact without triggering traditional perimeter defences.

1. Entry typically starts with compromised credentials, phishing, third-party access, or shadow AI usage rather than a zero-day exploit.
2. Credentialed access is then reused by AI systems, APIs, or plugins that already possess long-lived secrets or broad permissions.
3. Escalation occurs as the compromised identity moves laterally at machine speed across internal resources and admin surfaces.
4. Impact follows when attackers or malicious insiders use that access to reach sensitive systems, expand breach scope, and increase recovery cost.

Breaches seen in the wild

• iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI breach exposure is becoming an identity governance problem, not an AI novelty problem. The article’s central point is that AI-related incidents expose weaknesses in access control, authorisation, and lifecycle governance, not just model security. When AI systems authenticate to internal services, the relevant question becomes whether the identity layer can distinguish legitimate use from overbroad, unattended, or shadow access. Practitioners should treat AI security as an IAM and NHI governance discipline first.

Long-lived secrets are now a structural liability in agentic workflows. The article describes AI agents authenticating with durable credentials and plugins acting across systems, which turns static secrets into a cross-system blast-radius multiplier. That pattern is especially dangerous because the same credential can support discovery, execution, and lateral movement without any fresh human checkpoint. The implication is that secrets governance must be rethought around short-lived, tightly scoped access rather than shared persistence.

Identity is the new perimeter, but only if it is enforced continuously. Pomerium’s framing aligns with a broader governance shift: network placement no longer says enough about trust when machines, humans, and AI systems share the same resource layer. Continuous authorisation is the control assumption that survives this environment because it evaluates each request in context. Practitioners who still depend on static trust zones are already behind the operating model the article describes.

Zero Trust for AI agents fails when programme owners assume authorization ends at login. That assumption was designed for human-paced sessions and stable privilege windows. It fails when an AI system can call tools, chain actions, and traverse internal resources within a single session without human approval. The implication is that identity governance must move from session certification to request-time enforcement across humans, NHIs, and autonomous actors.

Identity blast radius: the real unit of AI risk is no longer the account, but the set of systems a credential can reach before it is revoked. That concept is visible throughout the article’s discussion of shadow AI, APIs, plugins, and machine-speed lateral movement. The strongest programmes will measure how far a compromised AI identity can travel, not merely whether the identity exists in a directory. That is the lens practitioners should use when prioritising remediation.

What this signals

Identity blast radius becomes the practical metric for AI security programmes. If an AI credential can authenticate, invoke tools, and move laterally without fresh policy evaluation, the question is not whether access exists but how far it can travel before revocation. Security teams should measure that reachable surface across APIs, plugins, and admin paths, then reduce it by design.

Continuous authorisation is now the differentiator between governed AI and unmanaged AI. Login-time trust is too weak for systems that act, delegate, and recombine access across workflows. The programme implication is straightforward: if your controls cannot evaluate each request in context, you are governing the directory but not the behaviour.

For practitioners

• Define AI access as a governed identity class Inventory LLMs, copilots, plugins, service accounts, and autonomous agents as separate identity subjects with explicit owners, scopes, and review cadences.
• Replace durable credentials with short-lived access Eliminate embedded secrets from AI workflows where possible and issue narrowly scoped, time-bounded credentials that can be revoked without breaking unrelated services.
• Enforce per-request authorisation for internal resources Apply policy checks at every access attempt to APIs, admin surfaces, and model endpoints so an approved session does not become open-ended trust.
• Separate shadow AI from sanctioned AI Require discovery and classification of unsanctioned AI usage so unmanaged tools do not inherit production access through shared infrastructure or credentials.
• Track AI credential lifecycle like any other NHI Tie issuance, use, rotation, and revocation of machine credentials to accountable owners and remove standing access that outlives the task it was granted for.

Key takeaways

• AI-related breach risk is increasingly an access-control problem, with identity governance lagging behind deployment of LLMs, copilots, plugins, and autonomous agents.
• Durable credentials, shadow AI, and machine-speed lateral movement expand breach impact even when the original compromise is ordinary credential misuse.
• Practitioners need per-request authorisation, short-lived credentials, and explicit lifecycle ownership for every AI identity that can reach internal systems.

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.
• Continuous authorization: Continuous authorization is the practice of rechecking access as a session unfolds instead of trusting a single login decision. It matters for AI workflows because the request, context, retrieved data, and downstream action can all change between prompt and execution, making static approval too blunt.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.