Agentless CNAPP vs Runtime Protection Explained

01

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.

02

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.

03

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.

04

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.

05

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.

06

Runtime security without Kubernetes

Runtime security does not inherently require Kubernetes. A host-level sensor can observe supported Linux processes and containers, including Docker workloads, through the host kernel. Kubernetes adds workload metadata and deployment orchestration; it is not what makes kernel-event collection possible.

For standalone containers or Linux hosts, review the sensor's kernel requirements, runtime support, host access, and required privileges. Also decide how to associate events with the container image and owning service. A containerized sensor still needs the host access described by its installation guide, and running on one host does not establish coverage of another.

Primod supports evaluation on Linux environments in Kubernetes or host mode. Review its deployment and coverage guidance for your Docker or Linux-host environment, including the current release's supported runtime, privileges, and detection coverage.

07

Choosing and combining

The decision is rarely either-or. Keep agentless scanning where you need cloud posture and inventory coverage, and add runtime sensing where you need execution evidence and detection. Sidecars are another option when the requirement is inline layer-seven policy enforcement rather than observation.

A practical sequence for teams running containers, Kubernetes, or Linux hosts is to retain static inventory, deploy a runtime sensor on supported hosts, and use observed activity as an input to remediation decisions and incident investigation. Primod's vulnerability prioritization workflow shows how package inventory and runtime evidence contribute to that review.