Runtime sensors and agents: what they add after agentless coverage

What a sensor sees

A sensor sees events, not snapshots. A process launches, a binary that was never on the image appears, a container opens a connection to an unfamiliar address. Each is visible only while it happens. A sensor can also show which installed packages are actually loaded and executed, which helps rank vulnerabilities: a flaw in a package that never runs is less urgent than one in a package that does.

What eBPF is

Most cloud workload sensors on this site use eBPF, a Linux kernel technology that lets small, verified programs observe kernel events without changing the kernel itself. In practice it gives a sensor a low-overhead view of system calls, processes and network activity. Orca, Wiz and Upwind all describe eBPF-based sensors.

How the vendors here describe their runtime layer

• Orca Security: the Orca Sensor is eBPF-based, covers Linux, Kubernetes and Windows, can be configured to terminate processes, and shows which vulnerable packages are executed. It is optional.
• Wiz: the Wiz Sensor is eBPF-based and blocks threats on VMs, containers and serverless containers.
• Upwind: eBPF sensors with baselines of cloud activity and network flows, and forensic event timelines.
• CrowdStrike: the Falcon sensor, the same agent CrowdStrike uses on endpoints.
• Sysdig: detection built on Falco, the open-source runtime project Sysdig created, now a CNCF graduated project.
• Aqua Security: kernel-layer enforcement that blocks attacks without killing the container.

Where runtime scores sit on this site

On our runtime criterion, CrowdStrike and Sysdig score highest at 9.6, with Upwind at 9.4. Orca scores 7.6, the lowest in the set, because its sensor is an optional layer and less proven than runtime-first platforms on the pages reviewed. Runtime carries 10% of our total because this site ranks coverage first; a runtime-first buyer should weight it higher in the coverage calculator.

What a sensor costs you

Not money only. A sensor needs:

• A deployment path for each workload type: a DaemonSet in Kubernetes, an install on each VM image, a different approach for serverless.
• Approval from the teams that own those workloads.
• Upgrades, kept in step with kernel versions.
• A plan for workloads where a sensor cannot run.

That is why many teams connect agentless first, get the inventory and the fix list, and then roll a sensor out to the workloads where runtime detection matters most.

The short version

Agentless shows you what you have. A sensor shows you what it is doing. Most platforms here offer both; they differ in which one they started with and which one is deeper.