IBM’s 2026 Breach Report Flags a 92% AI Access-Control Gap

IBM’s 2026 breach report reached Google News with a stark conflict: 92% of organizations hit through AI systems reportedly lacked proper access controls.

That figure matters because enterprises are no longer using AI only to draft text or summarize documents. Models and agents increasingly connect to company data, cloud services, software tools, and production workflows. Access mistakes can therefore expose information or authorize actions across several systems.

The headline also captures a wider reversal in enterprise AI. Companies adopted AI to improve productivity and strengthen security, yet many deployed it without the identity safeguards routinely required for employees and conventional applications. IBM’s findings suggest that attackers have noticed the gap.

IBM’s Google News Headline Points to a Wider AI Security Shift

The access-control statistic is alarming, but IBM’s broader findings show that AI now affects both sides of a data breach.

IBM released its 2026 Cost of a Data Breach Report on July 29. The research was conducted by Ponemon Institute, then sponsored and analyzed by IBM. It examined breaches experienced by 602 organizations across 17 industries between March 2025 and February 2026.

The reported 92% figure concerns organizations that experienced attacks involving their AI models or applications. In practical terms, those organizations lacked controls that could reliably limit who or what accessed the affected AI systems.

Access control determines whether a person, application, or machine identity can reach a resource. It also defines which actions that identity can perform. For an AI agent, those permissions might include reading customer records, calling an application programming interface, modifying a ticket, or triggering an automated workflow.

The statistic should not be interpreted as proof that 92% of all enterprises lack AI access controls. IBM studied organizations that had experienced breaches, and the figure applies to a narrower group with AI-related incidents. That distinction is important when assessing the prevalence of the problem.

Even within that narrower group, the finding describes a serious control failure. More than 20% of organizations in IBM’s sample reported a breach targeting AI models or applications. Compromised APIs, applications, or plug-ins accounted for 27% of the cited causes. Cloud misconfigurations affecting AI workloads accounted for another 27%.

Those findings shift attention away from dramatic scenarios involving a model spontaneously defeating security. The more immediate weaknesses often sit around the model. Attackers can exploit exposed interfaces, overprivileged service accounts, vulnerable plug-ins, and poorly configured cloud resources.

IBM’s 2026 breach report also puts the financial stakes into context. The global average breach cost reached $4.99 million, representing a 12% annual increase. IBM described that figure as a record high.

AI-related incidents changed the economics further. IBM reported that one in four malicious breaches was AI-enabled, up 56% from the previous year. These incidents cost organizations an average of $6 million, about $1 million above the global average.

That does not mean every AI-enabled attack directly targeted an AI model. IBM uses the category to include attacks in which threat actors employed AI, including deepfake impersonation and AI-assisted malware. The distinction separates attacks using AI from attacks against AI systems.

Together, the categories describe a two-sided risk. Attackers can use AI to increase the speed or scale of established tactics. They can also target the models, agents, data stores, and interfaces that businesses are rapidly adding to their infrastructure.

This is why the Google News framing should not be reduced to one sensational percentage. The underlying event is a change in the enterprise attack surface, with AI becoming both an attacker’s tool and a target.

The Real Weak Point Sits Around the Model

IBM’s numbers indicate that ordinary identity, API, and cloud failures remain central to supposedly new AI breaches.

AI security discussions often focus on model behavior, such as hallucinations, harmful outputs, or prompt injection. Those risks remain relevant, but IBM’s data points toward a less exotic problem. Organizations are connecting AI to valuable resources without consistently applying established security controls.

A model by itself usually cannot access a customer database or deploy software. It gains that reach through surrounding components. These include plug-ins, API credentials, retrieval systems, cloud roles, service accounts, and agent orchestration layers.

Every connection expands the number of decisions an organization must govern. Which documents can the system retrieve? Can it see records belonging to every customer? Can it call an external service? Can it write data, or only read it? Does its access expire when a task ends?

An agentic identity is the digital identity assigned to an AI agent that acts across connected systems. Traditional identity programs usually focus on employees, contractors, devices, and software workloads. Agents introduce another category that can make decisions and invoke tools with limited human involvement.

IBM recommends dynamic, identity-based controls for these agents. It also calls for tightly scoped permissions, runtime enforcement, human attribution, and auditable activity. Runtime enforcement means checking permissions while an agent operates, rather than approving broad access once during deployment.

That approach addresses a key mismatch. An employee typically authenticates through a known account, while an agent may act through several shared credentials. If logs record only the shared service account, investigators may struggle to identify which agent initiated an action or which employee requested it.

The result is an accountability gap. A company might know that an API token accessed sensitive data without knowing which model, workflow, or user caused the request. That makes inappropriate activity harder to stop and a later breach harder to reconstruct.

Least privilege offers a familiar response. The principle gives each identity only the access needed for a defined task. Yet applying it to AI can be difficult because agents often perform changing, multi-step work.

Broad permissions make an agent more useful across more situations. They also increase the potential damage from a manipulated prompt, stolen credential, faulty decision, or compromised integration. The same access that enables automation can enlarge the breach’s blast radius.

Consider an internal research assistant connected to documents, email, customer records, and project systems. A narrow configuration might let it retrieve approved files for one team. A broad configuration could expose information across legal, finance, engineering, and sales repositories.

The security difference is not the model’s writing ability. It is the quality of the identity boundary surrounding its data and tools.

Knowledge access also deserves particular attention. Organizations want assistants to find relevant context without exposing every source to every user. A carefully designed AI knowledge base should preserve source permissions instead of creating a new path around them.

The same issue appears in autonomous workflows. An agent handling support requests might need to read a customer profile and propose a response. It does not automatically need permission to export the customer database, change billing details, or disable security settings.

AI can blur those boundaries because useful context is often treated as a single pool. When permissions disappear during indexing, retrieval, or agent execution, the system can reveal information that the requesting user could not access directly.

Context poisoning creates another risk. This occurs when misleading or malicious information enters the material an AI uses to make decisions. An attacker might place instructions inside a document that an agent later retrieves.

Traditional output filtering does not fully address that scenario. The organization must control which sources the agent trusts, what tools it can invoke, and whether sensitive actions require approval. Logs must also preserve enough context to explain the decision.

A model’s guardrails and an enterprise’s access controls serve different purposes. Guardrails can influence the content a model produces. Access controls decide whether it can reach a payroll system, source-code repository, or production console.

Confusing the two can create false confidence. A well-behaved model with excessive permissions remains dangerous if its credentials are stolen or its inputs are manipulated. Conversely, tightly scoped access can limit damage even when a model behaves unexpectedly.

IBM’s report therefore challenges the idea that AI security requires an entirely separate security universe. Many failures still involve asset discovery, credential management, cloud configuration, monitoring, and incident response. The new difficulty lies in applying those controls to systems that act with greater autonomy.

AI Adoption Promised Speed, but Security Teams Inherited the Risk

The primary conflict is between rapid AI deployment and the slower work of defining identities, permissions, ownership, and evidence.

Enterprise teams face strong incentives to deploy AI quickly. Employees already use consumer assistants, browser extensions, transcription services, and AI features embedded in business software. Business units can often activate these services before security teams have inventoried them.

That behavior produces shadow AI, meaning AI tools or models used without formal approval or governance. It resembles shadow IT, but the exposure can extend beyond storage or software procurement. An unsanctioned model can process sensitive data, retain prompts, call tools, or influence business decisions.

IBM’s 2025 research established an important baseline. At that time, 13% of studied organizations reported breaches involving AI models or applications. Among those organizations, 97% said they lacked proper AI access controls.

The 2025 findings also found that 63% of breached organizations lacked an AI governance policy or were still developing one. Only 34% of organizations with a policy regularly audited for unsanctioned AI.

One in five organizations in that study reported a breach involving shadow AI. Organizations with high shadow AI usage experienced average breach costs $670,000 above those with low or no shadow AI usage.

The movement from 97% in the 2025 breached subgroup to the reported 92% in 2026 suggests limited improvement, not a solved problem. The samples and precise incident definitions may differ, so the percentages should not be treated as a clean year-over-year measurement.

Still, both figures point in the same direction. Nearly all affected organizations in the relevant groups lacked adequate controls around AI access. That consistency is more meaningful than the five-point difference.

Security teams are pressured from several directions at once. They must discover sanctioned and unsanctioned AI use, assign owners, classify connected data, govern nonhuman identities, inspect plug-ins, and monitor actions at runtime.

Meanwhile, product teams are expanding what agents can do. An assistant that only drafts text carries limited operational authority. An agent that updates customer records, merges code, schedules payments, or changes cloud resources crosses into a different risk category.

This creates a governance lag. Procurement might approve the software, while identity teams remain unaware of its service accounts. A developer might connect an agent to production data before the privacy team evaluates the flow.

The organization can end up with several incomplete views. Security sees API traffic, IT sees licenses, legal sees vendor contracts, and business teams see productivity. Nobody holds a complete inventory of the agent, its data, its credentials, and its permitted actions.

Policies alone cannot close that gap. A document might prohibit employees from uploading confidential information to public models. It cannot stop the activity unless the company can detect the tool, classify the data, and enforce the restriction.

Technical controls alone also fall short without ownership. A security platform can flag unusual access, but someone must decide what normal activity looks like for each agent. The owner must know which tools it needs and which actions should require a person’s approval.

The tension becomes sharper when executives demand measurable AI adoption. Teams may count enabled licenses, automated tasks, or employee usage as progress. Those metrics reward reach and speed, while permission reviews and audit preparation appear to slow deployment.

IBM’s research suggests that the hidden cost emerges after deployment. Missing ownership makes incidents harder to contain. Shared credentials make actions harder to attribute. Excessive access allows a single compromised component to reach more data.

The organizations under the greatest pressure include financial services and energy companies. IBM found that critical infrastructure sectors accounted for 62% of reported AI-driven attacks. Financial services breaches averaged $6.3 million, while energy breaches averaged $5.2 million.

These sectors operate interconnected systems where disruption can affect customers, supply chains, or essential services. They also hold valuable financial, identity, operational, and intellectual property data. AI integrations can create new routes into those environments.

Developers also inherit practical consequences. Security reviews increasingly need architecture diagrams, data-flow inventories, model documentation, credential ownership, and test evidence. A team that cannot explain an agent’s access will struggle to prove that the deployment is contained.

Enterprise buyers should therefore look beyond whether a product offers single sign-on. They need to know whether it preserves source-level permissions, supports granular roles, separates tenants, records tool calls, and permits rapid credential revocation.

A procurement checkbox can confirm that a control exists. It cannot establish that every agent uses the control correctly. The real test is whether an organization can trace one sensitive action from the requesting person through the model and into the target system.

AI Is Raising Breach Costs and Reducing Them

IBM’s central reversal is that AI amplifies attacks while security automation can substantially lower the resulting cost.

The 2026 report does not present AI as uniformly harmful. Organizations that used AI and automation extensively in security operations saved an average of $1.93 million compared with organizations using none.

That finding creates the report’s most important tradeoff. Refusing to use AI does not eliminate AI-assisted attackers or vulnerable third-party services. Deploying it carelessly, however, can add unmanaged identities and data paths.

IBM says AI-enabled attacks rose 56% year over year. Deepfake impersonation represented the most common category in secondary reporting, cited by 45% of respondents. AI-enabled malware and phishing also contributed to the increase.

These tools lower the cost of producing tailored messages, impersonating trusted people, and modifying malicious code. They do not remove the need for an entry point. Stolen credentials, exposed services, vulnerable software, and human deception remain essential parts of many attacks.

AI can also help defenders sort alerts, detect unusual behavior, correlate events, and contain incidents. Automation matters because breach costs increase when organizations take longer to discover and remediate compromised systems.

IBM security executive Suja Viswesan framed the issue as an economic imbalance. Attackers can launch operations more quickly and cheaply, while victims spend millions finding, containing, and recovering from a breach.

Her recommendation focuses on closing the delay between discovery and remediation. That includes integrating fixes into development workflows, securing identities during operation, and addressing weaknesses at the speed attackers exploit them.

Adoption remains uneven. One in four organizations in IBM’s study had not introduced AI and automation into security operations. More than half used agents for threat detection and containment, yet only 18% applied them to vulnerability management.

That gap matters because detection occurs after suspicious activity appears. Vulnerability management addresses known weaknesses before an attacker exploits them. Fast detection cannot compensate for exposed systems that remain unpatched or misconfigured.

The IBM study also found that 85% of respondents in follow-on research planned to increase security spending after learning about advanced frontier-model capabilities. Only 64% had planned increased spending after experiencing a breach in the initial research.

This result suggests that organizations are beginning to respond to anticipated capabilities, not only completed incidents. However, spending intent does not establish whether investments will improve identity controls or merely add more detection products.

The report’s methodology also deserves scrutiny. IBM and Ponemon studied organizations that experienced breaches, not a representative sample of every business. Cost estimates combine several categories, including detection, escalation, lost business, notification, and post-breach response.

The report can identify patterns within its sample. It cannot prove that adding one security product will produce the average savings cited across every organization. Larger enterprises, regulated sectors, and complex incidents can have very different cost structures.

Vendor incentives should remain visible as well. IBM sells security software and services related to identity, data protection, cloud management, and incident response. Its report can contain valuable research while also supporting a commercial narrative.

That does not invalidate the data. It means readers should separate measured findings from prescriptive claims. The sample shows associations between extensive security automation and lower average costs, but organizational maturity may contribute to both.

A mature security program is more likely to adopt automation effectively. It may also have better inventories, trained staff, tested response plans, and executive support. Those factors can reduce breach costs independently of the tools.

The 92% access-control finding requires similar care. The percentage does not show that missing controls caused every incident. It demonstrates a strong overlap between AI-related breaches and inadequate controls in the affected group.

Compromised APIs and cloud misconfigurations provide a plausible mechanism connecting weak controls to incidents. Yet causation can vary. An attacker might exploit a software vulnerability even when identity policies exist, or steal a legitimately privileged credential.

Independent coverage has highlighted the same dual threat. An industry analysis noted that criminals are both targeting AI systems and using AI to accelerate established attacks. That framing better reflects the report than a simple claim that models are causing breaches.

The practical conclusion is not to choose AI or security. Enterprises must govern AI deployments while also using automation where it improves defense. The outcome depends on whether organizations connect capability to narrowly defined authority.

What the 92% Figure Does Not Prove

The headline identifies a control crisis, but it does not reveal the quality of each organization’s controls or establish a universal incident rate.

Percentages can travel through Google News faster than their definitions. Readers may encounter the 92% number without seeing the sample boundaries, research period, or distinction between AI-enabled attacks and attacks targeting AI.

The first uncertainty concerns terminology. “Proper AI access controls” can cover several practices, including authentication, role design, credential rotation, source permissions, runtime policy, and audit logging. A binary measure can hide large differences in maturity.

One organization might have no dedicated controls. Another might use established identity systems but fail to apply them to one plug-in. Both could appear in the same inadequate-control category even though their security posture differs.

The second uncertainty concerns detection. Organizations cannot report incidents they never discover. Companies with stronger monitoring might identify more AI-related activity than organizations with limited visibility, creating an apparent increase that partly reflects better observation.

Eight percent of organizations in IBM’s 2025 study said they did not know whether AI models or applications had been compromised. That uncertainty illustrates the inventory problem. A company cannot assess a model it does not know exists.

The third uncertainty concerns the meaning of an AI-related breach. An attacker might target a model endpoint, steal training data, exploit an associated API, or use AI-generated phishing against an employee. Those events have different mechanisms and require different defenses.

Model inversion, for example, attempts to infer sensitive information from a model’s outputs. IBM reported a $6 million global average cost for breaches involving this type of attack. That scenario differs from a cloud storage bucket exposed through a misconfigured AI application.

Deepfake impersonation differs again. It uses synthetic media to imitate a trusted person, often to manipulate an employee or business process. Access controls can limit the resulting damage, but identity verification and process controls also matter.

The fourth uncertainty concerns trend comparisons. IBM’s 2025 report studied 600 organizations with breaches from March 2024 through February 2025. The 2026 report studied 602 organizations during the following 12 months.

Those similarly sized samples support broad comparison, but the participating organizations and incident mix can change. Readers should not treat every movement as a precise measure of the global breach rate.

The fifth uncertainty involves cost averages. A small number of expensive incidents can raise an average. Industry, company size, regulation, operational disruption, and recovery time all affect the final amount.

IBM’s global average rose from $4.44 million in 2025 to $4.99 million in 2026. The increase is notable, but it does not mean every company should expect an incident to cost exactly that amount.

A more useful approach is to interpret the findings as directional evidence. AI systems are becoming material parts of enterprise infrastructure. Attackers are interacting with those systems, and many affected organizations have not extended basic controls to them.

Security leaders should test whether the headline maps to their own environment. Can they list every model and agent? Can they identify the owner? Can they see which data sources each system reaches? Can they revoke its credentials without disabling an entire platform?

They should also ask whether logs preserve human attribution. If an employee directs an agent to update a customer record, the audit trail should connect the employee, agent, credential, tool call, and final change.

Continuous monitoring matters because an agent’s behavior can change with its context. New tools, prompts, data sources, and model versions can alter what it does even when its formal permissions remain constant.

External analysis of agent security has emphasized identities, tightly controlled access, auditable actions, escalation paths, and kill switches. These measures treat autonomy as an operational risk, not merely a model-quality problem.

A kill switch is a mechanism that stops an agent or revokes its ability to act. It should work quickly and predictably, especially when an agent can access financial, production, or customer systems.

Human approval also remains useful for high-impact actions. An agent can prepare a payment, code change, or account modification without receiving authority to finalize it. This separation preserves automation while limiting irreversible outcomes.

The controls should match the risk. An assistant summarizing public documents needs fewer restrictions than an agent accessing patient information or production infrastructure. Applying the same policy to both can create either excessive friction or inadequate protection.

The headline’s value therefore lies in prompting concrete questions. Its limitation is that it cannot answer those questions for every organization.

Three Signals to Watch After IBM’s 2026 Report

The next test is whether enterprises convert concern into measurable identity controls, vulnerability remediation, and independently verifiable results.

The first signal is the adoption of agent-specific identity controls. Organizations should move beyond shared API keys and assign distinct identities to agents, workloads, and workflows.

Evidence of progress would include short-lived credentials, task-level permissions, human attribution, and logs covering every tool call. Security vendors will likely expand products in this area, but adoption metrics matter more than feature announcements.

If organizations can inventory agentic identities and revoke them individually, IBM’s central warning will begin to weaken. If agents continue to inherit broad service accounts, the 92% headline will remain relevant.

The second signal is whether security teams apply automation to vulnerability management. IBM found that more than half of organizations used agents for threat detection and containment, while only 18% used them for vulnerability management.

That imbalance favors reaction over prevention. Progress would mean connecting asset inventories, exposure data, code ownership, and remediation workflows so known weaknesses reach the responsible team quickly.

The metric to watch is not the number of AI alerts. It is the time between discovering an exploitable weakness and deploying a verified fix. Shorter remediation times would support IBM’s argument that defenders can counter faster attacks with automation.

The third signal is independent evidence about breach frequency and costs. IBM’s annual report provides a widely cited benchmark, but buyers should compare it with regulatory disclosures, insurance data, incident-response findings, and peer-reviewed research.

Consistent results across those sources would strengthen the conclusion that weak AI access controls are driving material losses. Large discrepancies would suggest that definitions, sampling, or detection practices explain part of the trend.

Companies should also watch how the reported 92% figure changes in IBM’s next study. A meaningful decline, paired with stronger inventory and audit results, would indicate that governance is catching up.

A lower percentage alone would not be enough. Organizations might simply detect fewer incidents or redefine what qualifies as an AI system. Credible improvement requires evidence that controls are deployed, tested, and enforced during operation.

The broader question is whether enterprise AI can mature from experimentation into accountable infrastructure. Models and agents now touch documents, customer data, code, communications, and business processes. Security must follow those connections.

Google News can amplify the statistic, but boards and technical teams must translate it into system-level questions. Which identities exist, what can they access, and who remains accountable when an agent acts?

IBM’s findings offer a warning, not a final verdict. The next three months should show whether enterprises treat AI access as a core identity problem or another policy document awaiting implementation.

Review every AI agent that can reach sensitive data or trigger an external action. Give it a named owner, a distinct identity, narrowly scoped permissions, and an auditable path back to the requesting person. Then test whether the organization can stop it quickly.

That work is less dramatic than a Google News headline. It is also where the next expensive AI incident is most likely to be prevented.