IBM: у 92% компаний с AI-инцидентами не было базового контроля доступа

IBM studied corporate security incidents in AI systems and recorded a pattern that is shifting priorities in the field of AI protection: 92% of companies that experienced such an incident had no basic access controls for their AI tools. Meanwhile, the model itself — its architecture, weights, or algorithm — was not the root cause of the problem in the majority of documented cases.

Where the Vulnerability Actually Arises

92% of companies with AI incidents did not restrict who could access their AI systems and with what permissions — this is the key figure from IBM's research. Access control, rights auditing, and monitoring of model requests were absent precisely where they should have been the first line of defense.

At the same time, attackers generally did not target the model directly. They exploited simpler vectors: they compromised an account with excessive permissions, gained access to the AI interface — and the system itself then provided them with the information they needed.

• 92% of victim companies in AI incidents lacked sufficient access control for AI systems
• The AI model was rarely the root cause of the security breach
• Main attack vectors: excessive permissions for user and service accounts
• The absence of anomalous request monitoring for AI systems exacerbated the scale of incidents

Access control for an AI system is not just a login and password. In a corporate context, this means granular permissions: what data and knowledge bases the model can access, which employees and contractors have the right to submit queries and in what volume.

Why AI Systems Have Become an Attractive Target

Corporate AI tools are increasingly gaining broad access to critical business data: customer databases, financial documents, internal correspondence, and strategic materials. This is precisely what makes them a valuable target — not because of vulnerabilities in the model itself, but because of what data can be reached through it using ordinary queries.

A typical corporate AI setup connects the model to documents, CRM data, work chats, and knowledge bases. If there are no restrictions on what the system can "see" and deliver in response to queries, the scale of a potential data breach is determined only by how broad access to data the compromised account had.

"The model itself is rarely the problem,"

IBM's research concludes, pointing to organizational and configuration factors as the key cause of most documented AI incidents.

Why Basic Measures Remain Unimplemented

The accelerated adoption of AI in corporate environments has created a situation where AI systems are connected to production data before the necessary security perimeter is established around them. Tools are often perceived as "just another SaaS" rather than as infrastructure with access to critical corporate resources.

The principle of least privilege, regular access auditing, anomalous request monitoring, and segregation of test and production environments — these are not new concepts. IT security has been applying them to CRM, ERP, and databases for decades. According to IBM, this step is systematically skipped when deploying AI systems.

What This Means

IBM's research shifts the conversation about AI security from the domain of algorithmic risks to the domain of organizational maturity. Public discussions about AI threats often focus on vulnerabilities in the models themselves: prompt injection, hallucinations, unpredictable behavior. But the real picture of incidents, according to IBM, is different: nine out of ten companies that faced an AI breach could have avoided it with measures that information security professionals have been applying for decades. For CISOs and IT teams, this is the key takeaway: before scaling AI infrastructure, it is essential to ensure that the same access control standards that apply to any other critical corporate tool are also in place around it.