eBPF Runtime Security: Visibility vs Enforcement (2026)

Q: What can an eBPF security sensor see that a traditional userspace agent cannot?

Every event that crosses the kernel boundary, attributed to the process, container and pod that caused it, before the process has any opportunity to hide it. eBPF programs attach to tracepoints, kprobes and Linux Security Module hooks inside the kernel, so they observe process execution with full arguments, file opens with the resolved path, socket connects with destination, privilege and namespace changes and kernel module loads. A userspace agent reconstructs a subset of this from application logs, auditd, ptrace or an injected library, and each of those channels can be starved or bypassed: a process that writes no log, a statically linked binary that never calls through libc, a Go runtime making direct syscalls, or a process started before the agent attached all leave the agent blind while the kernel still saw everything. That asymmetry is the genuine reason eBPF has become the default sensor technology for runtime security in 2026.

Q: Does eBPF runtime security actually block attacks, or only detect them?

It depends entirely on where the program is attached and what the kernel allows, and most deployments only detect. A probe on a tracepoint or kprobe observes the event and emits it to a ring buffer; a userspace daemon reads it, matches rules and alerts, all after the syscall has returned. Blocking requires either a BPF-LSM program at a security hook that returns a denial, or a return-value override on an error-injectable kernel function, and both need specific kernel configuration (CONFIG_BPF_LSM with bpf in the active LSM list, or CONFIG_BPF_KPROBE_OVERRIDE). Tetragon's documentation is explicit that its two enforcement mechanisms are override and signals, and that sending SIGKILL during a write() does not guarantee the data is not written; only combining the signal with an override stops the operation. When you evaluate a product that claims runtime protection, audit the kernel configuration of every node pool: if the kernel cannot enforce, every block in the product is an alert with a friendlier name.

Q: Why does eBPF drop events, and how much does it matter for security?

eBPF programs write events into per-CPU ring buffers that a userspace daemon drains. If events arrive faster than the daemon reads them, the buffer fills and new events are dropped; the kernel counts the drops but cannot recover the content. Falco's modern eBPF probe exposes the buffer size as a configuration precisely because it is the operator's trade between memory on every node and loss under burst. It matters a great deal, because attacker tooling produces bursts: a credential dump, a lateral scan or a container escape can generate thousands of events in seconds, which is exactly when the buffer is most likely to overflow. A sensor that dropped 30 percent of events during the incident window has a 30 percent hole in the forensic timeline. The defensible posture is to export the drop counter as a metric, alert on it as an availability failure of the security control, size buffers from observed peaks rather than defaults, and reduce event volume at the rule engine so the daemon keeps up.

Q: What is the difference between Falco, Tetragon and KubeArmor?

Falco is a CNCF graduated project focused on detection: it consumes kernel events through a modern CO-RE eBPF probe or a kernel module, applies a rule language to them and emits alerts; version 0.45.0 shipped on 21 September 2026 with raw-byte rule matching and reload control endpoints. Tetragon is the Cilium project's eBPF observability and enforcement component: it observes process, file and network events with Kubernetes identity and can enforce inline through return-value override or signals, using TracingPolicy resources; version 1.7.1 shipped in August 2026 and it runs from kernel 4.19 with BTF. KubeArmor is a CNCF sandbox project that takes an enforcement-first approach, compiling Kubernetes-native policies down to Linux Security Modules, whether BPF-LSM, AppArmor or SELinux, so that the deny happens at the LSM hook regardless of which LSM the node supports. A common pattern is Falco or Tetragon for detection breadth and Tetragon or KubeArmor for a small, staged enforcement policy set.

Q: Can eBPF security tools run on AWS Fargate, Cloud Run or other managed serverless containers?

No, not as a sensor you load. eBPF programs are loaded into the kernel of the host, and managed serverless container platforms do not give you that kernel; the provider runs it and controls what can be attached. Your runtime visibility on those workloads therefore comes from what the provider exposes, such as audit logs, network flow logs and whatever runtime protection the provider itself offers, plus any instrumentation you compile into the application. The same boundary applies inside microVM sandboxes: within a Firecracker guest you can run an eBPF sensor, but it must be part of the guest image, since the host sensor cannot see inside the guest kernel. The architectural consequence is that sensor coverage is never complete, and an agentless inventory layer that reports exactly which workloads lack the sensor is a required part of the design, not an optional extra, so that the blind spots are known rather than assumed away.

Q: How do agentless cloud security scanning and eBPF runtime sensors fit together?

As complements that answer different questions, despite being marketed as alternatives. Agentless scanning reads disk snapshots and cloud APIs from outside the workload and tells you what is installed, how it is configured, what secrets sit on disk and how the workload is exposed; it sees nothing that happened only in memory or on the network, and a fileless payload leaves no snapshot evidence. An eBPF sensor tells you what actually ran, connected and changed on the nodes it is deployed to, and nothing about the nodes it is not. Combined, a vulnerability found on disk by the scanner becomes a priority when the sensor confirms the vulnerable library was loaded into a running process, and the scanner's inventory becomes the coverage map that shows where the sensor is missing. Vendors have converged on this pairing, which is why platforms that began as agentless now ship an eBPF sensor; the buying mistake is to believe either half is sufficient alone.

Q: What kernel version and configuration does eBPF runtime security require?

It varies by tool and by feature, and the practical requirement is BTF (BPF Type Format) plus the BPF ring buffer for modern CO-RE probes, with additional options for enforcement. Falco's modern eBPF probe documentation says it does not require a specific kernel version but that versions 5.8 and later are usually sufficient, with the two hard requirements being ring-buffer support and a kernel that exposes BTF; capabilities CAP_BPF and CAP_PERFMON, first officially supported in 5.8, allow it to run without full privileges. Tetragon runs from kernel 4.19 with tests on 4.19, 5.4, 5.10 and 5.15 long-term kernels, but its FAQ notes that not all features work on older kernels and lists required configuration including CONFIG_DEBUG_INFO_BTF, CONFIG_BPF_KPROBE_OVERRIDE for override enforcement and cgroup options. The operational lesson is that enforcement capability is a property of the node image; audit each node pool's kernel configuration before assuming the product's advertised features are available.

Q: How should a team roll out eBPF-based enforcement without causing outages?

Start with a policy set that is embarrassingly small and whose false-positive cost is zero because no legitimate production workload performs the action: loading a kernel module from a pod, writing to a binary directory inside an immutable image, a container process acquiring a capability it did not start with. Run each policy in audit mode first, on one namespace, and review every match for a full release cycle. Flip to enforce one namespace at a time, with the ability to revert in seconds through the same policy resource. Scope policies to Kubernetes identity so that a deny for one workload cannot affect another on the same node kernel. Treat every exception request as design feedback: if a team legitimately needs to do the thing, it did not belong in the enforcement layer and should move back to detection. Finally, prove the control on purpose with simulated attacker behaviour, confirming that the sensor sees, the rule fires, the deny holds and the drop counter stays flat under the load the test generates.