--- title: "Why eBPF Is Useful for Watching and Sandboxing AI Agents" source: "https://www.tigera.io/blog/why-ebpf-is-useful-for-watching-and-sandboxing-ai-agents/" --- [Technical Blog](https://www.tigera.io/category/technical-blog/) # Why eBPF Is Useful for Watching and Sandboxing AI Agents By [Peter Kelly](https://www.tigera.io/blog/author/peter-kelly/) on Jul 27, 2026 • 4 min read 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](https://www.tigera.io/learn/guides/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/). [Best Practices](https://www.tigera.io/tags/best-practices/)[AI Agent Security](https://www.tigera.io/tags/ai-agent-security/) ## Related posts [![AI Agents on Kubernetes 101: From Laptop Script to Production Pod](https://www.tigera.io/app/uploads/2026/09/AI-Agents-on-Kubernetes-101-From-Laptop-Script-to-Production-Pod.png)](https://www.tigera.io/blog/ai-agents-on-kubernetes-101-from-laptop-script-to-production-pod/) #### [AI Agents on Kubernetes 101: From Laptop Script to Production Pod](https://www.tigera.io/blog/ai-agents-on-kubernetes-101-from-laptop-script-to-production-pod/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Sep 8, 2026 In short, this is a beginner’s guide to deploying an AI agent on Kubernetes. You will containerize an agent, store its API key as a Kubernetes secret, write a deployment with health probes and resource... [Read more](https://www.tigera.io/blog/ai-agents-on-kubernetes-101-from-laptop-script-to-production-pod/) [![The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It](https://www.tigera.io/app/uploads/2026/08/The-Safest-Place-to-Run-an-AI-Agent-Is-On-a-Cluster-That-Doesnt-Trust-It.png)](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/) #### [The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Aug 27, 2026 Every organization running AI agents has already made a hosting decision. Most made it by accident. The sales team switched on the agent built into their CRM. Engineering is piloting a coding agent in a... [Read more](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/) [![AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.](https://www.tigera.io/app/uploads/2026/08/AI-Red-Team-Agents-Automate-Attacks-on-your-AI-Agents.-Runtime-Policies-Automate-their-Defense.png)](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/) #### [AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Aug 24, 2026 The AI red teaming market grew up fast this year. OpenAI bought Promptfoo, Cisco and Microsoft shipped automated attack suites, and a seed-stage startup publicly compromised 50 of 55 live customer service bots. These platforms... [Read more](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/)