TL;DR: IBM and the Ponemon Institute’s 2025 Cost of a Data Breach report, cited by Vorlon, shows that 97% of organisations with an AI-related security incident lacked proper AI access controls, while 63% still had no formal AI governance framework, underscoring how quickly AI adoption is outrunning identity oversight. The governance gap is now an access-control problem, not a future policy exercise.
At a glance
What this is: This analysis argues that IBM’s 2025 breach findings expose AI governance as an access-control and visibility problem inside enterprise IAM, not just a policy gap.
Why it matters: IAM, IGA, and security teams need to govern AI tools, agents, tokens, and connected SaaS flows with the same rigor they already expect for human and machine identities.
By the numbers:
- 97% of organizations that experienced an AI-related security incident lacked proper AI access controls.
- 63% of breached organizations either don't have AI governance policies or are still developing them.
- Only 37% have established governance frameworks, and even among that group, implementation varies widely.
Context
AI governance here means the controls that define who or what can use AI systems, what data they can reach, and how that access is monitored over time. IBM’s 2025 breach findings show that organisations are adopting AI faster than they can extend identity and access governance to those deployments.
The gap is not only theoretical policy drift. In practice, AI tools, copilots, service accounts, tokens, and SaaS integrations create new access paths that many IAM programmes do not inventory or review well enough, especially when the identities are non-human and the data moves across multiple applications.
That makes enterprise IAM the enforcement layer for AI governance. If teams cannot see the AI-connected identity graph, they cannot reliably control entitlements, detect shadow AI, or prove where regulated data is flowing.
Key questions
Q: What breaks when GenAI tools are embedded in SaaS without IAM oversight?
A: The control that breaks is identity governance over the integration itself. Once a business user can connect a GenAI tool directly into SaaS, the organisation may lose sight of who approved it, what data it can reach, and whether it should still exist. That leaves access sprawl, shadow AI, and dormant permissions outside normal review cycles.
Q: Why does weak AI governance increase breach risk when AI expands identity access?
A: Because AI often inherits existing permissions instead of creating new ones, so any oversharing is instantly amplified. When governance lags adoption, teams can lose track of what data AI can reach, who approved it, and whether access is logged. That combination raises exposure, weakens accountability, and makes incidents harder to contain before sensitive information is accessed or exfiltrated.
Q: What are the warning signs that shadow AI is becoming a security problem?
A: Look for AI tools connected outside approved procurement, unexplained API or token usage, and data leaving normal SaaS boundaries. Those signals show that access has expanded beyond governance, even if the user-facing application still appears legitimate.
Q: Should organisations treat AI access reviews differently from standard IAM reviews?
A: Yes. Standard reviews are usually centred on users and applications, while AI access reviews must also examine the connected identity, the data it can traverse, and the downstream SaaS integrations. Otherwise the review approves a label, not the actual control surface.
Technical breakdown
Why AI access controls fail in enterprise IAM
AI systems do not fit neatly into human-centric IAM models because they often act through service accounts, API keys, tokens, and delegated SaaS connections. Those identities can inherit broad permissions, move data across tools, and operate faster than review cycles designed for people. When governance is written only for named users, the control boundary stops at the wrong place. The practical issue is not just authentication, but entitlement scope, revocation, and auditability across connected systems.
Practical implication: Map AI tools to the non-human identities they use and govern the actual entitlement path, not the user-facing application alone.
Shadow AI and hidden SaaS integrations
Shadow AI emerges when employees connect unsanctioned AI tools to approved SaaS platforms without central oversight. The security problem is not merely unsanctioned software use. It is uncontrolled data sharing, where legitimate app permissions extend into an AI workflow that security teams never inventoried. This breaks discovery assumptions in both IAM and IGA because the identity may be authorised, while the integration chain is not. Visibility must therefore include connected tools, linked tokens, and downstream data access.
Practical implication: Inventory every AI-connected SaaS integration and revoke any connection that cannot be tied to an approved business need.
Why AI-related breaches become data-flow problems
Many AI incidents begin as access problems but end as data-flow problems because the AI tool can reach several applications at once. That makes compromise or misuse harder to contain than a single-account incident. Once an agent, copilot, or integration can traverse multiple systems, security teams lose the simple boundary that traditional IAM once assumed. The result is a wider blast radius, especially where customer PII or intellectual property is shared across environments without granular monitoring.
Practical implication: Apply data-centric access reviews to AI-connected workflows so you can restrict movement before sensitive data crosses trust boundaries.
Threat narrative
Attacker objective: The attacker or misused AI workflow seeks broad access to sensitive data and connected applications through one trusted integration path.
- Entry occurs when users connect AI tools, copilots, or third-party integrations to SaaS platforms without approval or complete visibility.
- Credential access follows through over-permissioned tokens, service accounts, or delegated access that let the AI path reach multiple applications.
- Escalation and lateral movement happen when the AI-connected workflow inherits broader data reach than the original business purpose required.
- Impact is unauthorized access to sensitive data, data integrity loss, operational disruption, and longer containment times across multiple environments.
Breaches seen in the wild
- DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
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 has become an identity governance problem. The IBM findings show that the failure point is not abstract policy intent but the access path itself. If AI tools can connect to SaaS, APIs, and data stores without enforced identity boundaries, governance never reaches the control plane that matters. The practical conclusion is that AI governance and IAM can no longer be managed as separate programmes.
Shadow AI creates governance drift faster than human review cycles can absorb. The article makes clear that organisations are still discovering AI tools after they are already connected to business systems. That means the control assumption is wrong at design time, because the environment changes faster than recertification and manual inventory can follow. The implication is that discovery and revocation must operate continuously, not quarterly.
Non-human identity visibility is now a prerequisite for enterprise accountability. AI agents, service accounts, and tokens can all hold access that no human user can explain after the fact. Once those identities are chained to SaaS integrations, accountability becomes distributed across teams that do not own the full workflow. Practitioners need a unified identity graph that shows who or what actually moves data.
Enterprise IAM is being stretched beyond authentication into data-path control. Traditional IAM assumed identity would authorize access once and then the application would do the rest. AI breaks that assumption because the tool itself can decide when and how to use reach across multiple systems. This is where the old model loses precision, and where access governance must shift toward continuous entitlement and flow control.
Access controls must be evaluated by what they allow AI to reach, not just by who can log in. The most material risk in the report is not the presence of AI, but the breadth of connected permissions that follow it into production. That makes the security question architectural: what can an AI-connected identity traverse, persist, and expose once it is live? The answer should determine governance priority.
From our research library:
- 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
- Read next: Ultimate Guide to NHIs — Key Challenges and Risks
What this signals
AI governance is now enforced at the identity layer, not the policy layer. If security teams cannot map AI tools to the non-human identities they use, governance remains declarative rather than operational. The practical shift is toward continuous entitlement visibility across SaaS, APIs, and AI-connected workflows.
Shadow AI should be treated as a discovery problem before it becomes a breach problem. Unknown AI connections are not simply an acceptable risk register item; they are ungoverned access paths that can move data outside intended controls. That makes automated inventory and revocation part of identity operations, not a separate monitoring task.
For practitioners
- Define the AI identity perimeter Inventory every AI tool, copilot, service account, token, and API path that can reach business data, then assign ownership for each connection.
- Tighten permissions for AI-connected identities Reduce inherited access on AI-linked accounts to the minimum scope required for the workflow, and remove broad SaaS entitlements that are not essential.
- Automate shadow AI discovery Continuously scan SaaS and application integrations for unsanctioned AI connections, then revoke risky tokens or permissions before they spread across systems.
- Add data-flow monitoring to governance reviews Track where AI tools move customer PII, intellectual property, and regulated data so access reviews can evaluate actual data paths, not just account lists.
Key takeaways
- IBM’s breach data shows that AI risk is concentrated at the point where access, governance, and visibility fail to meet in production.
- The recurring pattern is not sophisticated exploitation but unmanaged AI-connected identities reaching data and applications they should not traverse.
- Teams that want lower breach exposure need continuous discovery, tighter entitlement scope, and data-flow oversight for every AI-connected identity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | AI tools and SaaS integrations create third-party identity paths the article says are poorly governed. |
| NHI-05 — Overprivileged NHI | The article centres on AI tools holding broader access than their workflow requires. | |
| NHI-10 — Human Use of NHI | Employees are adopting AI tools that then operate through non-human identities across SaaS environments. | |
| Recommendation — Review third-party AI and SaaS access paths and remove any connection that lacks clear ownership and approval. Reduce AI-linked account scope to the minimum access needed for the approved business task. Separate human approval from machine execution and govern the non-human identity independently. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about controlling AI access boundaries and entitlement scope. |
| Recommendation — Apply entitlement reviews to every AI-connected identity and revoke permissions that exceed business need. | ||
| CIS Controls v8 | CIS-5 — Account Management | AI tools rely on accounts, tokens, and linked identities that need lifecycle control. |
| Recommendation — Maintain inventory and lifecycle control for AI-linked accounts, tokens, and service identities. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes credential use and cross-application movement through AI-connected identities. |
| Recommendation — Map AI-connected identity abuse to credential access and lateral movement to prioritise detection. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article repeatedly cites tokens, keys, and access controls as the weak point. |
| Recommendation — Enforce authenticator lifecycle controls for AI tokens and service credentials. | ||
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.
- 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.
- 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.
- Identity Graph: An identity graph is a relationship map that connects identities, assets, data, and permissions so teams can see how access actually flows. In NHI programmes, it helps explain which agent is related to which owner, which system, and which policy boundary.
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.
Published by the NHIMG editorial team on September 6, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org