Why eBPF Is Useful for Watching and Sandboxing AI Agents

EBPF is useful for observing and sandboxing AI agents because it attaches to the kernel to monitor syscalls—file, process, and network activity—without modifying the agent, according to a technical analysis. It enables a progression from observe to alert to enforce, allowing runtime policies like restricting file reads or blocking shell execution, with low overhead and without requiring redeployment. However, eBPF is not suited for deep content inspection, which is better handled by a TLS-terminating proxy at the model gateway.

Most of our runtime security habits were built for deterministic workloads. A service does what its code says: review the code, sign the image, and its behavior is bounded. Agents are different. An agent’s behavior emerges from a model reasoning over whatever lands in its context window, and some of that context comes from places we don’t fully control — a retrieved document, a tool’s output, a user’s prompt. Meanwhile the agent usually runs with real privileges: a service account, network reach, mounted secrets, a filesystem. When untrusted input shapes behavior, those privileges get exercised less predictably than we’re used to. A lot of good work goes into making agents harder to mislead — prompt hygiene, injection classifiers, guardrail models. It’s worth pairing that with a second question: if an agent does something we didn’t intend, how far can it actually reach? That’s blast radius, and it’s mostly a decision we make at the runtime layer, independent of how the prompt was handled. This is where eBPF is a good fit, for two reasons: it’s an excellent way to see what an agent is doing, and it can enforce limits on what the agent can touch — without changing the agent. Most of what an agent does is a syscall The reason the kernel is a natural place to observe and constrain an agent is that nearly everything an agent does — reading a file, running a command, opening a connection — resolves to a syscall. eBPF attaches to the kernel, beneath the workload, so it can watch those syscalls directly: File activity — via LSM hooks BPF-LSM / KRSI or kprobes on openat, read, write . You can see exactly what an agent reads and writes, including attempts to reach paths like /var/run/secrets . Process activity — via sched process exec and LSM bprm hooks. You can see every binary an agent tries to execute, including an unexpected shell. Network activity — via cgroup connect hooks, tc/XDP, and DNS visibility. You can see where an agent is trying to send traffic, and whether it’s trying to bypass your model gateway. That alone is valuable: a clear, tamper-resistant record of what your agents actually do at runtime, without instrumenting them. From observing to enforcing eBPF can also act inline — overriding a syscall or stopping a process when a policy is violated. That means the same layer supports a natural progression from observe → alert → enforce , and you can move an agent along that path without redeploying it. In practice, that gives you sandbox-like controls expressed as simple rules about what a process may touch: - Allow reads under /workspace but keep writes off for a read-only agent, and keep secrets out of reach entirely. - Pin an agent to an allow-list of binaries, or block exec for agents that should never spawn a shell. - Require egress to flow through your model gateway, and block anything trying to go direct. Two properties make this practical at scale. First, because eBPF sits beneath the workload, it applies to pods that are already running and agents you haven’t modified — no recompile, no sidecar, no new base image. That’s a real advantage when you already have agents in production. Second, it runs in a different trust domain than the workload, so it’s hard for the agent to tamper with, and the overhead is low enough to run fleet-wide. What eBPF is not for eBPF is well suited to blast-radius questions — what a process may touch — rather than deep content inspection. It can see that an agent is opening a connection or writing a path and act on that, but it can’t understand the semantics of a prompt or redact fields inside an encrypted request body. That kind of work belongs at a TLS-terminating proxy at the model gateway that can do semantic checks on the agent’s intent and actions. eBPF helps contain what an agent can do ; a proxy governs what it sends . They’re most useful together, and eBPF is happiest as a uniform floor beneath whatever higher-fidelity, application-aware controls you already run. The short version Agents behave less predictably than the workloads our tooling was designed for, so it’s worth planning for the moments when one does something unintended. eBPF gives you two things that can help: visibility into what agents are actually doing at the syscall level, and a tamper-resistant way to lock them down, across agents you never had to change or redeploy. Want to see what this looks like in practice on Kubernetes? Get the ebook: Securing AI Agents on Kubernetes using Tigera Lynx https://www.tigera.io/lp/whitepaper-securing-ai-agents-on-kubernetes-using-tigera-lynx/ .