eBPF for Runtime Security Monitoring in Sandboxed Environments

eBPF matters for AI agent security because of one fact: an agent running inside a sandbox cannot do anything real without passing through the kernel. This piece explains why approval logic, prompt filtering, and harness permissions cannot substitute for eBPF, and what current tools do and don't close in practice.

Sandboxed AI agents need a security layer that approval logic cannot reach

Most teams running AI coding agents today build their trust model around the harness: the prompt loop, the tool-routing logic, the permission gates that ask a user to approve a risky action before it runs. The harness is frequently not something the platform team wrote. It is a third-party product, bolted onto a sandbox the platform team may not even control end to end, and it is being asked to serve as the security boundary for everything the agent does. That is a lot of weight for a component built mainly for usability.

The eunomia project's framing of agent security helps make this concrete. It splits the problem into three layers: intent authorization, which is harness-owned and decides whether an action should be attempted; execution isolation, where ownership is genuinely contested between the harness and the platform; and side-effect verification, which has to be owned by the platform because nothing else is positioned to own it. Most agent platforms today are missing that third layer. They have a harness that asks permission and a sandbox that contains the blast radius, but nothing independently watching what actually happened once permission was granted.

Approval fatigue is the symptom anyone building these systems eventually runs into. Users get asked to approve so many actions that they turn the gates off, and products respond by adding bypass modes to keep the workflow usable. The deeper issue sits one level down: even when the approval gate is left on, nothing below the harness is checking that what was approved is what actually executed. A permission dialog states intent at the moment it is granted, before the action it authorizes has actually happened.

Scale turns this from an inconvenience into a real exposure. A security model built around a human clicking "approve" assumes a short decision window measured in seconds. An agent operating autonomously for hours changes that window into something a harness alone cannot watch continuously, and that is the gap the rest of this piece is about closing.

Every meaningful action an AI agent takes resolves to a syscall

Strip away the prompt engineering and the orchestration layers, and an AI agent's actual behavior in a sandbox is narrow in a useful way: it reads files, it writes files, it opens network connections, it spawns processes, and it does all of this inside a container or VM that shares a kernel with the host. Containers and VMs interact with that underlying kernel through system calls, through I/O, and through networking, and the shared-kernel model means this boundary is the one place no workload, however it was built or by whomever, can get around. An agent cannot read a secret, exfiltrate data, or escalate privilege without eventually asking the kernel to do something on its behalf.

That single fact draws a sharp line between two kinds of visibility. Kernel-level monitoring sees what the agent actually does, independent of what it says. Those two views line up most of the time. They diverge exactly when something has gone wrong, whether that's the agent behaving unexpectedly or a compromised dependency acting on the agent's behalf, and that divergence is precisely the moment application-layer logs stop being trustworthy.

It's tempting to think seccomp already solves this, since it operates at the syscall layer too. But seccomp filters by syscall number, not by what the syscall is actually doing. Research on eBPF-PATROL documents how this blindness becomes an attack surface in itself, letting an attacker reach privileged resources through a syscall the policy never meant to expose. The same research traces two real-world vulnerabilities back to syscalls that default seccomp profiles permitted, each one enabling a container breakout.

Why does kernel-level visibility matter more than a preference for thoroughness? A user-space check can be true at the moment it runs and false a few milliseconds later, when the syscall it was meant to gate actually fires. The kernel boundary earns its position at that timing gap: it is the only point in the stack positioned to watch and intervene at the moment the action actually happens, when someone asked for permission to take it.

How eBPF attaches beneath the workload

eBPF's whole case rests on where it sits. It runs small, verified programs directly inside the Linux kernel, attached to the specific hooks where syscalls, network events, and process lifecycle events actually occur. It observes those events as they happen rather than reconstructing them after the fact from logs an agent chose to write. That position is structurally prior to anything a user-space agent decides to do or suppress, because the agent never gets a chance to act before the kernel already has.

A policy attached to these points can see, in real time, what an agent reads, what it writes, and whether it is reaching for a path like /var/run/secrets that has no business being touched by a routine task.

What keeps this from being as dangerous as it sounds, letting arbitrary code run inside the kernel, is the verifier. Before an eBPF program is allowed to load, the kernel's verifier statically proves it cannot crash the system, cannot loop forever, and cannot touch memory outside its own space. That's a meaningfully different model from older-style kernel modules, which run with full kernel privilege and no such proof requirement. A compiled eBPF program also runs at near-native machine code speed, so the overhead that would normally come from kernel-userspace round trips largely disappears, and research cited in this space measures that overhead at consistently under 1% of CPU.

The previous section's timing gap gets a specific, partial answer here. Not all eBPF hook types are equally resistant to timing races. LSM-hooked eBPF programs, by contrast, execute their checks after argument copying is complete, which gives them meaningfully stronger resistance to TOCTOU races than the other three eBPF program types. eBPF does not solve TOCTOU categorically. It solves it well specifically where LSM hooks are used, and that distinction matters for anyone designing an actual policy rather than just citing eBPF as a buzzword.

Granularity is the other place position pays off. Because eBPF watches at the syscall level, it can enforce policy below the level of the whole process, down to the level of a single library call. GoLeash demonstrates this for Go supply-chain attacks: its 2025 analysis found that package-level policy granularity, watching what an individual dependency does rather than what the process as a whole does, detects malicious packages in 98% of cases, a result that coarser process- or container-level monitoring simply can't match, because by the time bad behavior shows up at the process level, it's already mixed in with everything legitimate the process is doing too.

AI agents create coverage problems eBPF tools built for deterministic workloads do not automatically solve

None of this means an off-the-shelf eBPF deployment is ready for an AI agent the day it's installed. Tools like Falco and Tetragon were built for deterministic workloads: a web server, a database, a batch job, something whose syscall pattern is knowable in advance and stable across runs. A policy written for that kind of workload defines what's normal once and expects the running system to match it indefinitely.

AI agents break that assumption at the root. An agent's execution pattern is novel on every prompt, because what it reads, what it connects to, and what processes it spawns are functions of the task it was just given rather than some fixed role it plays in the architecture, which is a mismatch between a monitoring approach designed around stable baselines and a workload that doesn't have one.

The harness itself compounds the problem. Writing a policy requires knowing what "normal" looks like. For a harness nobody on the platform team wrote, that's not always available information.

Computer-use agents push the surface further still. Once an agent is operating a full virtual desktop rather than a narrow sandboxed shell, the isolation boundary extends to that whole desktop environment, and eBPF has to run inside the same isolated environment the agent occupies rather than observing it from outside. Freestyle's choice to offer eBPF support inside every VM it provisions is one concrete example of infrastructure built with this requirement in mind, rather than retrofitted onto it later.

The institutional signal here matters as much as the technical one. The eBPF Foundation's re-platforming thesis names GPU scaling, real-time inference, supply chain security, zero-day exploits, semantic and intent analysis, and agent identities as requirements the legacy infrastructure stack was never built to address. This is framed as a genuine architectural need for the AI era. And at ASPLOS 2026, the AgenticOS Workshop, the first workshop specifically on operating system design for AI agents, took on isolation, scheduling, and observability through eBPF as open topics. An open workshop track is a tell: this is acknowledged as unsolved, not a checkbox a vendor has already filled in.

The tools that currently implement eBPF-based runtime security for sandboxed workloads

The tool landscape has already converged on eBPF as the shared kernel substrate, even though the individual products built on it differ a fair amount in scope and enforcement model.

CoreWeave runs Cilium with an eBPF CNI for workload isolation across its GPU infrastructure, and supports customers who deploy Cilium Tetragon themselves for auditability and real-time detection at that scale.

Busted, also open source, takes yet another angle. It's a compiled, eBPF-based tool that intercepts decrypted LLM API traffic, covering OpenAI, Anthropic, Google, and a structured agent-communication protocol, by attaching uprobes to OpenSSL and enforcing policy in-kernel through LSM hooks and policy rules. That addresses a surface generic container security tools simply don't look at: the actual API calls an agent makes to language model providers.

Meta's BpfJailer applies eBPF-based mandatory access control to jail untrusted AI training workloads and untrusted prompt execution. It was presented at Linux Plumbers 2025, with an open-source release planned for 2026.

The hard limit: what eBPF cannot guarantee when the kernel itself is compromised

All of this runs inside the kernel. All of it depends on the kernel being trustworthy. If the kernel itself is compromised, eBPF's view of the system is compromised along with it, because eBPF has no vantage point outside the kernel to check its own observations against.

There's a documented evasion path for exactly this scenario. Falco's eBPF programs attach correctly to syscall tracepoints and execute exactly as designed. But every event they generate still has to travel from kernel space to userspace through a ring buffer or perf buffer, and that delivery path can be disrupted by hooking the kernel functions responsible for it. An attacker who reaches that level of control can filter out events from hidden processes before they ever reach Falco's userspace agent. From Falco's own perspective, nothing is wrong, because the attacker edited what Falco gets to see rather than fighting it directly.

Once an attacker can load kernel modules, they control the kernel's view of reality, and any eBPF tool running inside that kernel only sees what the kernel chooses to show it, which is the structural ceiling of running security logic inside the thing it's meant to police rather than a flaw specific to any one vendor's implementation.

A systematic literature review spanning 54 primary studies from 2018 to 2026 found that eBPF-based monitoring performs well at detection, with host-based syscall-sequence detection reaching 98.39% accuracy in a 2026 hybrid monitoring study that combined syscall traces with network flow data. But the same review found it cannot prevent every kernel-level exploit without accepting overhead costs too high for production use. Detection and prevention are not the same guarantee, and the gap between them is exactly where a sufficiently capable kernel-level attacker still has room to operate.

Meta's own architecture reflects this limit rather than denying it. Sentinel's eBPF enforcement protects the kernel from the agent, watching and restricting what the agent is permitted to do. A separate project, Muse Confidential VM, is planned to protect the agent's runtime from the host OS itself, addressing the reverse direction: a compromised OS or a hypervisor-level attacker intercepting the agent's data regardless of what the agent does. As of October 2026, Muse Confidential VM has not shipped, which makes it the clearest evidence available that the industry treats this as the frontier still being built toward, not a problem already closed.

Operational reality adds friction on top of the structural limit. Loading eBPF programs requires CAP_BPF or CAP_SYS_ADMIN, capabilities that strict security environments are often unwilling to hand out without additional review. Adopting eBPF-based monitoring is itself a permissions decision, not just a technical one.

None of this undercuts the case for eBPF as the layer approval logic cannot reach. It sharpens what that case actually is. eBPF is the necessary independent layer beneath the harness, positioned to see what an agent actually did rather than what it reported doing. But it is not sufficient by itself. It has to be paired with kernel integrity enforcement, and at the highest levels of assurance, with hardware-backed confidential computing that assumes the kernel itself might one day be the thing that needs watching.