IBM breach findings expose the AI governance gap in enterprise IAM

At a glance

What this is: IBM’s 2025 breach data shows that AI adoption is outpacing governance, with most AI-related incidents tied to missing access controls and immature AI policy frameworks.

Why it matters: IAM, IGA, PAM, and security architects need to treat AI tools, AI agents, and connected SaaS integrations as governed identities because unmanaged access now expands breach impact across both human and non-human environments.

By the numbers:

• 97% of organisations with an AI-related security incident lacked proper AI access controls.
• 63% of breached organisations either do not have AI governance policies or are still developing them.
• 20% of organisations suffered a breach due to shadow AI, unsanctioned AI tools used without approval or oversight.

👉 Read Vorlon’s analysis of IBM’s 2025 AI breach findings and governance gap

Context

AI governance, in practice, is the set of controls that determine which tools can access which data, under what authority, and with what monitoring. IBM’s 2025 breach findings show that many organisations are deploying AI faster than they can define those boundaries, which leaves both AI tools and the identities connected to them outside normal IAM oversight.

The problem is not limited to model risk or policy language. When AI tools connect to SaaS applications, APIs, and data stores, they inherit access paths that can amplify a small misconfiguration into a cross-environment exposure. That makes AI governance a lifecycle and access problem as much as a security architecture problem.

For NHI and IAM programmes, the important shift is that AI tools are now part of the identity estate. If teams cannot discover, classify, authorise, and review those access paths continuously, they will not have a reliable control plane for shadow AI, delegated access, or machine-to-machine data movement.

Key questions

Q: What breaks when AI tools are allowed broad write access to internal systems?

A: Broad write access turns an AI tool from a helper into an unreviewed operator. It can modify code, create tickets, change records, or move data in ways that expand the attack surface and complicate incident response. The failure is not only overprivilege, but also the loss of clear accountability for actions taken through the AI intermediary.

Q: Should organisations prioritise AI data governance before scaling AI adoption?

A: Yes. Organisations that scale AI before establishing discovery, classification, monitoring, and policy enforcement are effectively expanding the attack surface faster than they can govern it. AI adoption should be matched with controls that follow the data lifecycle, otherwise compliance, exposure, and misuse risks compound as usage grows.

Q: How should security teams discover shadow AI agents in the enterprise?

A: Use endpoint artefacts first. Look for agent directories, service definitions, local ports, and process names that prove the software is installed and active. Network traffic alone is too ambiguous because legitimate browser and API activity can look identical to agent behaviour. Discovery should produce an inventory of where the agent runs, what it can reach, and whether it is sanctioned.

Q: What is the difference between managing human IAM and AI tool access?

A: Human IAM assumes a person authenticates, requests access, and then uses it within known working patterns. AI tool access is different because the tool can move data and act across systems at machine speed, often through delegated credentials. The governance model must therefore focus more on scope, lifecycle, and behavioural monitoring than on login experience.

Technical breakdown

Why AI access controls fail in connected SaaS environments

AI tools rarely operate in isolation. They connect through OAuth grants, API keys, service accounts, plug-ins, and embedded integrations, which means the effective security boundary is not the model itself but the identity and permission chain around it. If those grants are broad or poorly inventoried, the AI tool inherits the reach of the underlying account. That is why an AI-related incident often becomes a data-access incident rather than a pure application issue. Traditional IAM visibility breaks down when connected tools are created faster than their entitlements are reviewed.

Practical implication: treat every AI integration as an identity with explicit scope, review cadence, and revocation path.

Shadow AI discovery and the problem of invisible authorisation

Shadow AI emerges when employees adopt copilots, agents, or AI-enabled plugins without security approval. The technical risk is not just unapproved software, but untracked authorisation chains that bypass normal onboarding, classification, and recertification. Once an unsanctioned tool is connected, it may inherit data access from a legitimate SaaS account and move information across systems without an obvious alert. Discovery therefore has to operate at the integration layer, not only at the endpoint or email layer. Without continuous mapping, teams cannot distinguish legitimate AI use from hidden access pathways.

Practical implication: build discovery around SaaS-to-AI connections, not only asset inventory or endpoint coverage.

Why AI-related breaches become data-flow problems

The report’s incident patterns, including supply chain compromise, prompt injection, model inversion, and data poisoning, show that attackers often exploit the trust placed in connected tools rather than the model alone. In identity terms, that means the exploit path usually targets data reach and delegated authority. Once an AI tool can read, transform, or forward sensitive information, the blast radius depends on what it is allowed to see and do across environments. That is why access governance, token scope, and behavioral monitoring matter more than isolated AI security checks.

Practical implication: monitor data movement, token use, and integration behaviour together so compromise is visible before exfiltration.

Threat narrative

Attacker objective: The attacker wants to turn a single AI-linked identity or integration into repeatable access across multiple SaaS and data environments.

1. Entry occurs through AI-connected credentials, inherited SaaS permissions, or unsanctioned integrations that expose access to attackers or abusive users.
2. Escalation follows when the compromised or shadow AI tool reaches multiple applications, allowing the actor to move from one data source to another through delegated authority.
3. Impact appears as data exfiltration, operational disruption, and integrity loss across several environments because the AI integration already has broad reach.

Breaches seen in the wild

• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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

NHI Mgmt Group analysis

AI governance gaps are now identity governance gaps. IBM’s data shows that the majority of AI-related incidents are not exotic model failures but missing access controls and immature governance. That means the control problem sits in IAM, IGA, and NHI management rather than in AI strategy alone. Practitioners should stop treating AI governance as a parallel programme and start treating it as part of the identity estate.

Shadow AI is a lifecycle failure, not only a discovery failure. Unapproved AI tools become dangerous when they are granted access before anyone classifies, reviews, or retires that access. The underlying assumption was that connected tools would be registered before use and removed when no longer needed. That assumption fails when employees can introduce new AI pathways faster than governance processes can see them. The implication is that lifecycle discipline must extend to AI-connected non-human identities.

Data exposure follows delegated authority, not tool branding. The article’s incident patterns show that once an AI tool inherits broad SaaS permissions, the attack surface becomes the entire connected ecosystem. Identity blast radius: the effective exposure created when one identity can reach multiple systems, datasets, and workflows. This is the right concept for practitioners because it reframes AI security around access scope, not product category.

AI security and NHI governance are converging on the same control set. Tokens, API keys, service accounts, and AI agents all need discovery, review, revocation, and behavioural monitoring. The difference is that AI tools can move data and trigger actions at machine speed, which compresses the time available for manual response. Security teams should align AI governance with NHI governance rather than building separate playbooks for each.

Traditional IAM metrics understate the real risk when AI is involved. Counting assigned permissions is not enough if teams cannot see which AI tools are actively using them or how those tools are chaining access across apps. The report implies that governance maturity should be measured by visibility into actual access paths, not policy existence alone. Practitioners should shift from entitlement counts to control effectiveness and data-flow evidence.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to the 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, which shows how quickly one identity failure can repeat across systems.
• The practical next step is to study 52 NHI Breaches Analysis for the root causes that turn a single access failure into a recurring breach pattern.

What this signals

Identity blast radius: AI adoption is expanding the number of identities that can reach sensitive data, but most governance programmes still measure access at provisioning time rather than at runtime. That gap matters because an AI tool with inherited permissions can traverse SaaS, API, and data boundaries in ways human IAM processes never anticipated. Teams should align discovery and review around actual data movement, not just assigned entitlements.

With 72% of organisations already reporting or suspecting a breach of non-human identities, the control conversation has moved from theory to programme design. The organisations that will cope best are the ones that treat AI-connected tools as governed identities, use continuous discovery, and link access decisions to lifecycle controls. For the wider control model, the most relevant reference point is the NIST Cybersecurity Framework 2.0.

The governance signal is clear: if a team cannot answer which AI tools can reach regulated or sensitive data today, it does not yet have an operational AI security programme. That should push practitioners toward identity-centric controls, token review, and data-flow visibility rather than isolated AI policy statements.

For practitioners

• Map AI-connected identities into the existing identity inventory Include copilots, AI agents, API tokens, service accounts, and plug-ins in the same inventory used for human and machine identities. If a tool can read or move data, it needs a named owner, an access review path, and a clear revocation process.
• Enforce least privilege on every AI integration Scope OAuth grants, API keys, and delegated permissions to the minimum data and action set required. Remove broad workspace access, shared tokens, and standing permissions that let a single compromise reach multiple business systems.
• Continuously discover shadow AI and revoke risky connections Monitor SaaS-to-AI connections for unsanctioned tools, unexpected data flows, and privilege inheritance from legitimate applications. Use automated revocation for high-risk tokens or permissions before they become persistent exposure paths.
• Correlate behavioural monitoring across human and non-human identities Look for access patterns that deviate from normal application use, including unusual data reads, cross-app traversal, and repeated token use. Feed those signals into SIEM and SOAR so identity anomalies trigger containment early.

Key takeaways

• AI-related incidents are exposing a basic governance gap: organisations are deploying AI faster than they can control identity and access.
• The strongest evidence in the report is not model sophistication but missing access controls, immature governance, and hidden AI integrations across SaaS environments.
• Practitioners should treat AI tools as part of the identity estate and manage them with the same lifecycle, visibility, and least-privilege discipline as other non-human identities.

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.
• Frontier AI access control: The policy layer that decides who can use a highly capable AI system, under what conditions, and with what assurance. In practice it combines authentication, eligibility checks, jurisdiction rules, and revocation so access can be granted or removed without treating every user the same.
• 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.
• Delegated Agent Authority: The permission granted to an AI agent to act on behalf of a human user or another agent, inheriting some or all of their access rights. Delegated authority must be explicitly scoped, time-limited, and auditable.

What's in the full article

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

• Detailed breakdown of how the platform maps SaaS-to-AI access paths and token relationships across connected tools
• Examples of automated revocation workflows for risky permissions and unsanctioned AI integrations
• Integration details for SIEM, SOAR, and ITSM workflows that operational teams can use during containment
• Data-flow mapping examples that show how customer PII and intellectual property move through AI-connected environments

👉 Vorlon’s full post covers the breach statistics, SaaS-to-AI exposure patterns, and control recommendations in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance maturity, it is worth exploring.