Runtime Security vs Agentless Scanning: What Each Can and Cannot See

Three approaches, three questions

Cloud-native security tooling has converged on three collection models. They are often marketed as alternatives, but they observe different layers of the system and are better understood as answers to different questions.

• Agentless scanning answers: what is deployed and how is it configured? It reads cloud APIs and disk snapshots from outside the workload.
• Host or sidecar agents answer: what is happening on this node or next to this container? They run as privileged processes or proxies alongside the workload.
• eBPF runtime sensors answer: what did this process actually execute, load, open, and connect to? They observe from inside the kernel without modifying the workload.

Agentless scanning: how it works and what it misses

Agentless platforms, often labelled CSPM or the posture half of a CNAPP, connect to the cloud provider with read permissions. They enumerate resources, evaluate configuration against policy, and periodically snapshot block storage volumes to inspect installed packages, secrets on disk, and file permissions without touching the running instance. Kubernetes support usually comes from the API server: workloads, RBAC, network policies, and admission configuration are read as objects.

The strengths are real. There is nothing to deploy inside the workload, coverage across accounts is fast, and the approach cannot degrade application performance because it never runs on the application's node. For inventory, misconfiguration, identity exposure, and image vulnerability lists, it is often sufficient.

The blind spot is execution. A snapshot shows that a vulnerable library exists on disk. It cannot show whether any process loaded it, whether a shell was spawned inside a container ten minutes ago, whether an interpreter parsed untrusted input, or what a workload connected to. Snapshot cadence also means that short-lived containers and in-memory activity are never captured. Agentless scanning describes the system at rest.

Host agents and sidecars

Traditional agents run as a daemon on each node, or as a sidecar proxy in each pod. They can watch file integrity, intercept network traffic, and enforce policy inline. Service-mesh sidecars in particular give rich layer-seven network visibility because every request passes through them.

The costs are operational. Sidecars add a container to every pod, consume CPU and memory proportional to pod count, and require injection into deployments, which touches the application delivery path. Userspace agents that hook system calls through ptrace or LD_PRELOAD can impose measurable latency and are fragile across language runtimes. Both models see the workload from the outside, at the network or filesystem boundary, rather than from the kernel's view of what a process did.

eBPF runtime sensors

eBPF lets a sensor attach small, verified programs to kernel hooks: tracepoints for syscalls and scheduler events, kprobes for kernel functions, uprobes for functions in userspace binaries, and socket hooks for network flows. One sensor per node observes every container on that node because containers share the host kernel. No sidecar, no code change, and no restart of the workload is needed.

The visibility is what makes runtime reachability possible: library loads, executed functions, process lineage, file access, and network connections are observed as they happen, with the process and container identity attached. The same stream supports detection of behaviour that snapshots never capture, such as an unexpected shell in a production container or a connection to an unfamiliar destination.

The trade-offs are also real. The sensor runs in production, so its event selection and buffering have to be engineered carefully to keep overhead low and predictable. It requires a kernel that supports the needed eBPF features, which excludes some legacy distributions. It observes only what runs, so it must be combined with static inventory to reason about paths that have not yet executed. And because it is evidence-rich, the platform consuming the events has to correlate and summarise them, or teams drown in telemetry.

Side-by-side comparison

The table below summarises the visibility each model provides. Read it as a coverage map rather than a scorecard: most organisations need the first column for posture and inventory and the last column for execution evidence and detection.

Choosing and combining

The decision is rarely either-or. Agentless posture scanning is the cheapest way to get complete inventory and configuration coverage across every account, and it should stay in place. Runtime sensing is what turns that inventory into a prioritised queue and gives incident responders ground truth. Sidecars remain the right tool when the requirement is inline layer-seven policy enforcement rather than observation.

A practical sequence for a Kubernetes-heavy organisation is to keep agentless scanning for posture and image inventory, deploy an eBPF sensor to production clusters to establish which findings are reachable and what workloads actually do, and use the runtime evidence both to rank remediation and to document accepted risk. Primod's platform is built around that second step: the sensor, the correlation of runtime evidence with CVE and cloud data, and the call-stack view behind each reachable finding.