MITRE's New Framework: Securing the eBPF Layer Your AI Depends On

AI systems are increasingly making automated decisions on telemetry drawn from the kernel. MITRE's new Framework for Continuous Remote Attestation names the layer where that telemetry can be quietly corrupted, and it is the layer the industry has spent the least time defending.

In cloud-native infrastructure, eBPF (extended Berkeley Packet Filter) has become indispensable. It delivers deep visibility and fine-grained control by running programs directly in kernel space. Security platforms, observability tools, and performance monitors are all leaning into eBPF for real-time telemetry. At the same time, AI and ML models are increasingly consuming that telemetry to make automated decisions.

What happens if the eBPF layer feeding your AI has been compromised?

That is the question we asked ourselves after years of working on kernel security for federal and commercial systems. What we found, and what the industry still had not accounted for, is that eBPF opens a privileged attack surface where runtime memory tampering goes completely unmonitored. Worse, the data coming out of a compromised kernel space is being fed directly into AI systems making enforcement decisions at scale.

This is no longer only our observation. In July 2026, MITRE released a Framework for public review, developed with founding collaborators Fr0ntierX and Invary, that formalizes exactly this problem.

 

Why AI Makes This Urgent Now

The stakes changed the moment machines started acting on kernel telemetry without a human in the loop. Consider the growing list of AI-enhanced systems that rely on it: anomaly detection engines, workload autoscalers, adaptive policy engines, and large-scale threat scoring models. They all depend on accurate, timely data, and that data increasingly originates from eBPF tracing syscalls, monitoring socket activity, and inspecting process behavior.

If the eBPF layer, now doing double duty as your security sensor and your AI’s primary input, is feeding data that has been tampered with, the AI system is basing high-confidence decisions on false signals. The attackers do not need to bypass the AI, they just need to corrupt what it sees. Because this corruption happens inside the kernel, it is often invisible to higher-layer defenses like Endpoint Detection and Response (EDR), Cloud Security Posture Management (CSPM), or Security Information and Event Management (SIEM) tools (if the acronyms are blurring together, you are not alone, the security space has never made that easy).

We have red-teamed systems where a malicious intent activity went undetected simply because the eBPF program tasked with logging syscalls had been silently disabled at runtime. This was possible because it is a failure of the trust chain. If AI was involved, it can turn that failure into automated, high-confidence, high-speed error.

 

The Illusion of Trusted Telemetry

Most organizations implicitly trust the output of eBPF programs. It is understandable. eBPF is powerful, efficient, and deeply woven into the Linux ecosystem. But it is also a black box at runtime. Once loaded, eBPF programs operate in kernel context, and most tools stop observing them the moment they pass the verifier.

That is a problem. An attacker with root access, a kernel-level exploit, or a misused privileged container can modify eBPF programs after verification. We have seen techniques that involve swapping map pointers, redirecting function hooks, or injecting modified bytecode directly into memory. From a logging and monitoring standpoint, everything looks clean, but the actual functionality  underneath has been hijacked. In that moment, your AI is not just blind. It is being misled.

 

Why Static Controls Do Not Close It

This issue is not solved by code signing or CI/CD validation. Signing a BPF object file does nothing to guarantee that it has not been altered in memory, had its logic patched, or been swapped out after the fact. Verifier checks are performed only one time when a program is loaded. Even observability tools that rely on eBPF can be deceived, because the eBPF program delivering the observability data may itself have been compromised.

There has been no runtime verification layer continuously confirming that what is executing in kernel space matches what you intended when you deployed it. That is the gap. It is precisely the gap the MITRE framework was built to address.

 

Where This Fits in the MITRE Framework

The Framework for Continuous Remote Attestation organizes integrity into layers.

• Layer 1 covers the hardware platform, the physical root of trust everything else builds on.
• Layer 2 covers the software and images, what was supposed to be loaded and running.
• Layer 3 covers runtime state, whether the running system, including its kernel components, still matches what was verified at load time.

eBPF integrity lives squarely in Layer 3, the layer the framework identifies as having had the least structure and where the most consequential compromises operate.

The framework also extends this model directly to AI, mapping concerns like model and pipeline integrity into the same continuous evidence structure. That is the recognition this article has been building toward: an AI system is only as trustworthy as the runtime feeding it, and runtime integrity has to be verifiable rather than assumed.

 

A Runtime Integrity Layer for eBPF

This is where Runtime Integrity enters the picture. Instead of inspecting logs or trusting load-time configurations, Runtime Integrity focuses on continuously verifying the execution state of the system, down to the memory and control flow of active kernel components, including eBPF programs.

At Invary, we built a system that applies this principle directly to eBPF. It detects when a running program has diverged from its known good state. It spots injected logic, tampered data structures, and malicious redirection inside the kernel. It does this continuously, without relying on the signals an attacker can suppress. Invary's contribution to the MITRE framework is rooted in exactly this runtime verification work.

 

The Path Forward

We are moving into an era where security and operations decisions are increasingly made by machines. That shift is a reality, but it raises the stakes. The integrity of the data flowing into those systems becomes paramount.

The industry has spent its attention on the power and promise of eBPF, and rightly so. I think we have spent far less time asking whether we can trust what eBPF is actually doing at runtime. That is the blind spot, and it is one attackers are already exploiting. Now there is an open, MITRE-led framework that treats it as a first-class problem, and it is in the right place.

If your systems are powered by AI, and your AI is fed by eBPF, you need to verify the integrity of that chain, not just at deployment but continuously, at runtime. Anything less is operating on assumption. Runtime Integrity verification restores confidence in the data your AI depends on.