Skip to main content
eBPF lets a program run inside the Linux kernel, attached to a specific event, without a kernel module and without patching the kernel. It is the facility that makes zero-code instrumentation possible: the agent can observe what your processes do because it is executing at the point where they do it. This page is the amount of kernel detail needed to answer a security question. It is not a tutorial.
Availability. The zero-code agent is an early-access distribution. It is installable, upgradable and tested, and it is not yet an integrated part of the product: there is no dashboard page for it, no in-product installer and no self-service download. Ask your account contact for access.Its telemetry, once flowing, is ordinary OTLP and needs nothing special — it appears in Services, Traces and Metrics exactly like SDK telemetry does. That is the design rather than a shortcut.

​
The model

1

A program is compiled to eBPF bytecode

A restricted instruction set. No unbounded loops, no arbitrary memory access, no calling into anything it likes.
2

The kernel verifier checks it before loading

Every possible execution path is analysed. A program that could loop forever, read out of bounds, or dereference an unchecked pointer is rejected — it never runs.
3

It attaches to an event

A kernel function entry, a userspace library call, a network socket, a tracepoint.
4

It runs on that event and writes to a map

Bounded work, then a result into a shared memory region.
5

The agent reads the maps from userspace

Aggregates, converts to OTLP, and exports.
The verifier is the reason this is safe to run in production. A kernel module can do anything and a bug in one panics the machine. An eBPF program is proven terminating and memory-safe before it is allowed to load. Loading failures are loud and non-fatal — the program is refused, and the kernel carries on.This is the whole difference between eBPF-based agents and the kernel-module agents that earned the category its reputation.

​
What the agent attaches to

The TLS hooks are the important one, and they are the source of the sharpest question in any security review.
The agent’s position lets it see plaintext. It hooks SSL_read and SSL_write, so at that boundary it observes decrypted traffic: headers including Authorization, cookies, request and response bodies, SQL statement text.What stops that becoming data anyone holds is configuration, not incapability: payload capture is off, URL paths are reduced to route patterns before export, and only metadata leaves the host. The full statement of what is sent is in Security model — read that page before you sign anything.

​
Why it needs privilege

Loading an eBPF program and attaching probes are privileged kernel operations. This is not incidental — it is why the agent can see what it sees, and why the decision about how much privilege deserves to be explicit. The requirement is expressed as Linux capabilities, not as root:
CAP_SYS_ADMIN is not in any profile. It is near-equivalent to root. It is refused outright for the lower two profiles, and reachable only through an explicit opt-in flag on the highest. See Capability profiles.

​
Why the kernel version matters

The agent reads kernel data structures whose layout changes between versions. Rather than compiling a build per kernel, it uses CO-RE — compile once, run everywhere — which relocates field offsets at load time using type information the kernel publishes about itself, called BTF. That gives you two hard requirements:
  • Kernel 5.8 or newer (RHEL-family 4.18 excepted, where the features are backported).
  • /sys/kernel/btf/vmlinux must exist. Without it there is no type information to relocate against.
Both are checked by the preflight tool before anything is installed. See Compatibility.

​
The setting that catches everyone

kernel.perf_event_paranoid must be 1 or lower.Above that, the kernel denies perf-event access even when CAP_PERFMON is granted. The failure is the worst possible shape: the agent starts, holds every capability it asked for, passes its own internal checks, reports healthy — and collects nothing at all. There is no error to find.
Preflight treats this as a blocking failure rather than a warning, precisely because nothing downstream would tell you.

​
What is left behind

Nothing in the kernel. eBPF programs and their maps are released when the process that loaded them exits. Stopping the agent stops the observation; there is no module to unload and no reboot to schedule.

​
Next

OpenTelemetry OBI

The upstream project, what is pinned, and what this distribution changes.

Security model

Written for a security team: what it sees, sends and never does.

Capability profiles

Three privilege levels, measured rather than quoted.