Enter a kernel version - the output of uname -r - and see which eBPF capabilities it has: tracing hooks, CO-RE portability, ring buffer, security hooks, and whether modern eBPF tooling will run on it.
eBPF has existed since kernel 3.18, but 5.8 is the practical waterline for modern tooling: it brought the BPF ring buffer and CAP_BPF, and it is the floor most current security agents and CO-RE-based tools target. Kernels from 5.8 onward with BTF enabled run precompiled eBPF programs with no kernel headers, no compilation on the host, and no kernel module - which is why every mainstream distro since Ubuntu 22.04, Debian 12, and RHEL 9 is comfortably in "just works" territory.
Two caveats the table can't capture. First, BTF is a build option (CONFIG_DEBUG_INFO_BTF): mainstream distro kernels enable it from around 5.4, but custom or minimal kernels may not - on the host itself, ls /sys/kernel/btf/vmlinux is the truth. Second, enterprise kernels backport heavily: RHEL's "4.18" and "5.14" kernels contain many features from much later mainline releases, so for RHEL-family hosts treat mainline-based results as a floor, not a ceiling.
If your kernel is modern, the whole eBPF toolbox is open: start with bpftrace one-liners for ad-hoc questions, and see the open-source eBPF tools guide for the full landscape - tracing, security, and networking. If you're stuck below 5.8, older tooling paths exist (per-kernel compiled probes, kernel modules) but they are exactly the operational pain modern eBPF was invented to end - often the cheapest fix is a distro upgrade.
If your kernel passed, it can watch every process start, file access, and network connection at the source. AlertKick's agent uses exactly that: kernel-level security detections mapped to MITRE ATT&CK, with AI triage so you only hear about the events that matter - from £5/month.
See eBPF security monitoring