What eBPF actually is - and why it's finally practical to run

If you run servers and you’ve shopped for runtime threat detection recently, you’ve seen eBPF on every vendor’s page. The products built on top of it are priced like enterprise software, because they were built for enterprise buyers.

eBPF is the right answer to the runtime-security question. Over the last couple of years, it’s become possible to ship it at a price and complexity level any team can adopt - without a security specialist on staff or a multi-week tuning project. That’s the shift AlertKick is built around.

The one-paragraph explanation

eBPF is a mechanism built into the Linux kernel that lets userspace programs safely run small, sandboxed instructions inside kernel code paths. You can hook a syscall, a network event, a filesystem operation, a scheduler tick. The kernel verifies the program can’t crash or hang, then runs it in-kernel and reports results back up. That means you can observe what your processes genuinely did, down to the system call level, without modifying any of them and without turning on invasive debug logging.

For security, that gives you real-time visibility into behaviour at the layer where behaviour can’t lie.

Why this matters more than log-based monitoring

Logs are a claim. The process tells the log what it did. An attacker can disable, edit, or silence the log. An attacker can write plausible-looking entries. An attacker can replace the binary with one that just doesn’t write logs. Every serious intrusion playbook starts with some version of “silence the telemetry”.

File-integrity and static scanning are late. By the time a malicious binary is on disk, you’re already compromised. You’re just finding out after the fact.

eBPF observes behaviour. Every exec, every connect, every open, every capability change. It watches these from outside the process, from inside the kernel, at a layer the process cannot reach. You can turn off the logs, but you cannot turn off the kernel.

Concretely, that catches patterns like:

• Someone exec-ing a shell inside a container that was supposed to be immutable and long-running.
• A process making a network connection it’s never made before, to an address you don’t recognise.
• A cron job suddenly gaining capabilities (CAP_SYS_ADMIN, CAP_NET_RAW) it never had last week.
• A binary executing from /tmp or /dev/shm - the classic pattern for fileless malware.
• Crypto miners, by the shape of their syscall footprint, independent of the filename they use.

None of those depend on the attacker leaving behind a nice log line or a known-bad file signature.

Why this used to be out of reach

Three reasons.

Running eBPF well used to need specialists. The raw interface is unfriendly: bytecode, kernel verifier semantics, map types, ring buffers. You didn’t write it by hand; you leaned on a framework. The best open-source framework is powerful but ships with thousands of rules and assumes you’ve got the time to tune them to your environment. That tuning is a multi-week project for somebody who knows what they’re doing.

Raw eBPF is noisy. On a typical Linux server, the default detection rulesets produce dozens of events per day. Package managers trigger them. Deploy scripts trigger them. Backup processes trigger them. Unless someone on your team spends a couple of weeks baselining your specific environment, the signal-to-noise ratio is bad enough that the team stops reading the channel within a fortnight. At that point you don’t have security; you have a tool you pay for.

Shipping eBPF events to a backend at scale is expensive. At a thousand hosts, you can be pushing hundreds of gigabytes of event data a day. The products that handle that scale are priced for the buyers who run a thousand hosts - which is not most of us.

Put together, these three meant that for a long time, the realistic options were: pay enterprise prices and staff a specialist to run it, or don’t bother. Most teams didn’t bother.

What’s changed

Managed agents matured. You don’t have to understand verifier semantics any more. A well-built agent ships with production-tuned defaults and a supervisor that keeps the kernel attachments healthy through reboots, kernel upgrades, and container restarts. It installs in a minute and gets out of your way.

AI triage became genuinely useful for this. An eBPF event is a JSON blob describing “process curl executed on host web-03 with args https://...”. A human takes thirty seconds to decide, given context about the host and the deploy schedule. A well-prompted AI triage layer, given the same context, takes a second and gets the easy cases - which are most of them - right. That pre-filtering is the single biggest change in the last two years. It turns a “useful tool” into one people actually use. In AlertKick’s dashboard you see the triage verdict inline with every event, along with the reasoning, so you can spot-check whenever you want.

The event-storage economics shifted. The per-host cost of shipping eBPF events to a managed backend is no longer the pacing bottleneck.

None of these changes are theoretical. They make it possible to include runtime security in the same product as the rest of your monitoring, on one bill - no separate enterprise contract, no specialist to run it. Three years ago, that sentence would have been a lie.

What AlertKick gives you out of the box

Install the AlertKick agent on a Linux host, enable the security module, and the detections are on by default. No configuration. No rule writing.

• Shell-in-container - Interactive shells in containers not designed for one almost always mean something is wrong.
• Privilege escalation - A process gaining capabilities mid-execution, or the classic setuid pattern.
• Reverse shells and unusual bind patterns - Processes listening on sockets they shouldn’t be.
• Memory-resident binaries - Executables launched from /tmp, /dev/shm, or memfd. The fileless-malware pattern.
• Crypto miner signatures - Caught by syscall fingerprint rather than filename, which makes them resistant to renaming.
• Compliance-relevant file writes - Edits to /etc/passwd, /etc/shadow, /etc/sudoers, and the paths that sit inside a PCI DSS cardholder-data environment scope.

Every detection maps to the relevant MITRE ATT&CK technique. You don’t see “rule #4782 triggered” - you see “T1059.004: Unix shell command-line interpreter, inside container payments-api.” You know what that means without a glossary.

Every event passes through the AI triage layer before it lands in your alerting channel. A typical week on a typical fleet produces between zero and a couple of events that actually page someone. The rest are visible in the dashboard for anyone auditing the triage decisions, with the AI’s reasoning attached to each one.

What it isn’t

eBPF runtime security is not endpoint protection for laptops, not an antivirus, not a network firewall, and not a substitute for patching or secret rotation. It won’t stop a phishing attack against an admin’s workstation. It won’t catch a compromised supply chain that ships a well-behaved malicious binary to every customer.

It catches the post-exploitation phase - the moment a successful attacker starts doing things on your servers. That’s the stage at which every other layer of defence has already failed. That’s when you need to know.

Try it

If you’ve been avoiding runtime security because the existing options are priced for someone else, the eBPF feature page is where to start. Get started and the agent installs in about a minute on the test host of your choice.

The next post in this series goes deeper into the AI triage layer - what it actually does to an event, what it gets right, and where we’ve had to tune it.