97% of AI Breaches Lacked Access Controls: What IBM's 2025 Report Means for You
IBM's 2025 Cost of a Data Breach report delivered a finding that should alarm every enterprise security leader: 97% of AI-related breaches investigated lacked proper access controls at the time of the incident. Not weak controls. Not misconfigured controls. In nearly every case, there were effectively no controls governing how AI systems accessed, processed, or transmitted sensitive data. The average cost of these AI-related breaches reached $5.2 million, well above the global average for conventional incidents.
This is not a theoretical risk. It is the documented reality of how most organizations are running AI today.
The Data Leak Problem Is Already Here
IBM's findings are reinforced by Cisco's 2025 AI Security Report, which found that 46% of organizations experienced data leaks through generative AI tools in the prior 12 months. Nearly half of all enterprises surveyed had already suffered the exact scenario that security teams feared: sensitive corporate data, customer records, proprietary code, or regulated information leaving the organization through AI channels.
What makes these numbers especially troubling is that most of these leaks were not the result of sophisticated attacks. They stemmed from applications sending unfiltered data to AI providers — internal tools pasting confidential data into prompts, services uploading documents to third-party AI APIs, or backend applications forwarding sensitive data to external model endpoints without access controls. The breach vector was not a vulnerability to be patched. It was the intended functionality of the AI integration itself.
Why Traditional Network Security Falls Short
Enterprise security stacks were designed for a different era of threats. Firewalls, network segmentation, DLP gateways, and proxy appliances all operate on the assumption that traffic flows through well-defined perimeters and can be inspected at known chokepoints. AI API calls break these assumptions in several fundamental ways.
First, AI API traffic is encrypted HTTPS to endpoints that look identical to any other legitimate SaaS traffic. A call to the OpenAI API, an Anthropic endpoint, or a Hugging Face inference service is indistinguishable from normal cloud traffic at the network layer. Traditional firewalls cannot inspect the content of these requests without complex TLS interception setups that introduce latency, break certificate pinning, and create their own security risks.
Second, AI calls originate from everywhere. They come from developer laptops, from backend microservices, from CI/CD pipelines, from low-code automation tools, and from third-party SaaS platforms that have embedded AI features. There is no single network path to monitor. By the time your proxy sees the traffic, the data has often already been serialized into a prompt and is on its way out.
Third, the threat model is inverted. In traditional security, you are trying to stop bad things from coming in. With AI data leaks, you are trying to stop legitimate users from sending sensitive data out through tools they are authorized to use. This requires content-level awareness that network security was never designed to provide.
Kernel-Level Interception with eBPF: A Different Approach
If you cannot reliably intercept AI traffic at the network perimeter, the logical alternative is to intercept it at the source: the operating system kernel. This is where eBPF (extended Berkeley Packet Filter) changes the equation.
eBPF allows lightweight programs to run directly in the Linux kernel, observing and acting on system events in real time without requiring kernel modifications or custom drivers. When applied to AI security, an eBPF-based probe can hook into network syscalls and identify every outbound API call to an AI service the moment it is initiated, before the data ever leaves the machine. This is not sampling or log analysis after the fact. It is deterministic, real-time interception at the lowest possible level.
Because eBPF operates at the kernel layer, it is invisible to the application making the call. There are no SDKs to integrate, no code changes required, no reliance on developers to adopt a library or route traffic through a specific proxy. Every process on the host, whether it is a Python script, a containerized microservice, a Node.js application, or a third-party binary, is covered automatically. If it makes a network call, the kernel sees it, and the eBPF probe sees it.
This approach eliminates the coverage gaps that plague application-level solutions. You do not need to hope that every team adopted your SDK or that every AI integration was routed through your gateway. The kernel is the universal chokepoint, and eBPF gives you programmable access to it.
Runtime Enforcement vs. After-the-Fact Auditing
The IBM report's 97% statistic reveals another critical gap: most organizations that had any AI monitoring at all were relying on logging and auditing rather than active enforcement. They could tell you what happened after a breach, but they could not prevent it in the moment.
The difference between runtime enforcement and after-the-fact auditing is the difference between a lock on your door and a security camera that records someone walking through it. Audit logs are valuable for compliance and forensics, but they do nothing to stop sensitive data from reaching an external AI model in real time. Once a prompt containing customer PII hits a third-party API, the damage is done. No amount of log review can pull that data back.
Runtime policy enforcement means evaluating every AI API call against your security policies as it happens and blocking or modifying requests that violate those policies before they complete. This includes redacting PII from prompts, blocking unauthorized model access, enforcing rate limits, and ensuring that sensitive data classifications are respected. The policy decision happens inline, in milliseconds, with no human intervention required.
How BlueAspen Addresses This
BlueAspen's architecture was designed specifically around the gaps that the IBM and Cisco reports expose. The platform deploys an eBPF-based agent at the kernel level that captures every AI API call across your infrastructure. Traffic is routed through an inline proxy that performs real-time threat scanning and PII redaction before requests reach external AI providers. Every interaction is logged to a full audit trail that satisfies compliance requirements for SOC 2, HIPAA, and emerging AI-specific regulations.
This is not a bolt-on to existing network infrastructure. It is a purpose-built layer that operates where traditional security tools have no visibility: inside the host, at the syscall level, with full content awareness of what is being sent to AI models and what is being returned.
The deployment requires no application code changes and no SDK integration. If your workloads run on Linux, the agent covers them. Policies are defined centrally and enforced uniformly, regardless of which team, application, or AI provider is involved.
The Window for Proactive Action Is Closing
The IBM and Cisco data make one thing clear: the gap between AI adoption and AI security is not narrowing on its own. Organizations are deploying generative AI faster than security teams can implement controls, and the cost of that gap is being measured in millions of dollars per incident. Waiting for a breach to justify investment in AI access controls is an expensive strategy.
The organizations that avoid becoming part of next year's statistics will be the ones that implement runtime enforcement now, before the inevitable regulatory mandates make it a compliance requirement rather than a competitive advantage.
If your team is evaluating how to close the AI security gap, we would welcome the conversation. Book a demo with BlueAspen to see kernel-level AI access controls in action.