Agentless versus agent-based Kubernetes scanning: governance trade-offs

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Palo Alto Networks's blog post: Agentless and agent-based Kubernetes scanning each cover a different part of the risk picture.

Why it matters: It matters because IAM, platform, and security teams need to decide whether their Kubernetes controls are optimised for build-time posture, runtime defence, or both.

Context

Kubernetes scanning is the practice of checking container images, manifests, clusters, and running workloads for vulnerabilities, misconfigurations, and suspicious behaviour. The governance gap is that short-lived containers can be safe at scan time and dangerous minutes later, so the control question is not just what is present, but when it can be observed.

Agentless and agent-based models answer different governance needs. Agentless approaches favour broad, low-touch coverage before deployment, while agent-based approaches add runtime visibility inside the cluster. For security programmes, the decision is really about whether pre-execution assurance is enough, or whether workload identity and runtime behaviour need continuous observation.

In practice, most environments need both forms of visibility because Kubernetes is dynamic and workload exposure changes after admission. That makes the scanning model a control-design choice, not just a tooling preference.

Key questions

Q: What breaks when Kubernetes security relies only on agentless scanning?

A: Agentless scanning breaks down once the container is live, because it cannot reliably observe execution, file changes, or network activity inside a running pod. That leaves a gap between admission approval and actual runtime behaviour, which is where many container attacks occur. Security teams need a separate runtime control when workloads are short-lived or highly exposed.

Q: Why do ephemeral Kubernetes workloads need runtime detection as well as pre-deployment checks?

A: Ephemeral workloads can be deployed, exploited, and terminated before a periodic or external scan sees them. Pre-deployment checks still matter for known vulnerabilities and misconfigurations, but they do not replace live monitoring when the threat unfolds after admission. For short-lived pods, runtime detection is the only way to catch behaviour that happens between scans.

Q: What are the signs that Kubernetes scanning is too focused on posture and not enough on behaviour?

A: Common signs include good image hygiene but no visibility into suspicious process execution, reverse shells, or unexpected outbound connections once pods start running. Another warning sign is a programme that can explain what was deployed but not what the workload actually did after scheduling. That indicates posture controls are outrunning runtime controls.

Q: How should security teams combine agentless and agent-based Kubernetes scanning?

A: Use agentless scanning for broad pre-deployment coverage and agent-based scanning for runtime visibility. The first catches vulnerable images and misconfigurations before release. The second detects behaviour after deployment, including exploitation, lateral movement, and suspicious process activity. Most Kubernetes environments need both if they want meaningful coverage of short-lived workloads.

Technical breakdown

How agentless Kubernetes scanning works across APIs and registries

Agentless scanning inspects Kubernetes and container assets without installing software on nodes or pods. It typically works through the Kubernetes API, cloud provider APIs, registry inspection, or remote analysis of manifests and volumes. That makes it useful for broad posture review, CI/CD gating, and compliance checks because the scanner can see what is built and what is configured before the workload runs. The trade-off is timing: once a pod is live, agentless scanning may no longer have enough context to detect exploitation, in-memory execution, or post-deployment drift.

Practical implication: Use agentless scanning to block known-bad images and misconfigurations before deployment, but do not treat it as runtime protection.

Why agent-based scanning changes the runtime control model

Agent-based scanning installs sensors on cluster nodes so the control plane can observe what containers are actually doing. That means process execution, file changes, network connections, and syscalls can be monitored while a workload is alive. This is materially different from pre-deployment scanning because it captures behaviour, not just posture. It is especially relevant for ephemeral pods, zero-day exploitation, and attacks that only become visible after code is running. The cost is operational overhead: agents must be deployed, updated, and kept compatible across environments.

Practical implication: Use agent-based scanning where runtime behaviour, short-lived workloads, or active attack detection matter more than low-friction rollout.

Why hybrid Kubernetes scanning is often the defensible governance choice

A hybrid model combines pre-deployment scanning for breadth with runtime sensors for depth. That pairing closes the gap between what was approved in CI/CD and what the container actually does once scheduled. In governance terms, it aligns preventive controls with detective controls, which is important because Kubernetes workloads can change state faster than a single scan cycle can follow. The article’s core point is that neither model is complete on its own: agentless methods reduce exposure before launch, while agents catch behaviour that only appears after launch.

Practical implication: Treat the two models as complementary controls and define which risks are owned at image-build time versus at runtime.

Threat narrative

Attacker objective: The attacker aims to exploit a running Kubernetes workload after it has passed build-time checks, gaining execution or persistence inside the container.

1. Entry occurs when a vulnerable or noncompliant container image reaches deployment because only pre-deployment scanning was applied.
2. Escalation occurs after the pod is live, when a runtime exploit or suspicious process begins inside the container.
3. Impact follows when the malicious behaviour is only visible at runtime, allowing malware execution, reverse shells, or other post-launch abuse to continue before detection.

Breaches seen in the wild

• TeamTNT worm 2020: A TeamTNT cryptomining worm spread through exposed Docker APIs and stole AWS credential files from every host it infected, Cado Security found.
• Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentless versus agent-based scanning is really a question of control timing, not control quality. Agentless inspection is strongest before the workload is admitted, while agent-based telemetry is strongest after the workload starts behaving. That distinction matters because Kubernetes exposure is temporal: what is safe at build time may not stay safe at runtime. Practitioners should design scanning around when risk emerges, not around a single universal control.

Ephemeral workload visibility is the named governance gap in this model. Short-lived pods can complete an entire malicious action path before a periodic or external scan sees them. The limitation is not simply that agentless tools lack depth, but that they cannot continuously observe an identity that may exist for only minutes. The implication is that runtime observability becomes a separate control requirement, not an enhancement.

Runtime assurance should be treated as a governance boundary for Kubernetes, not a tuning parameter. When a team relies only on registry or API-based inspection, it is assuming that admission equals safety. That assumption does not hold once a pod can execute code, change state, or open network connections after deployment. Practitioners should separate approval controls from behavioural controls in the operating model.

Hybrid scanning reflects the broader direction of cloud security programmes. Breadth without depth leaves active threats invisible, while depth without breadth creates operational drag and incomplete posture coverage. The category is moving toward layered control models that distinguish build-time compliance from runtime defence. Security leaders should expect Kubernetes governance to converge with broader cloud runtime security patterns.

Kubernetes scanning is also a workload identity problem when runtime controls are weak. Once a container is live, the relevant question is not only what image was deployed, but what that workload is allowed to do in the cluster and across connected services. That is where runtime telemetry, least privilege, and workload identity controls meet. Practitioners should align scanning with the identity and authorization model of the workload, not treat it as a standalone hygiene task.

From our research library:

• Kubernetes production adoption has surged from 66% in CNCF's 2023 survey to 82% in 2025.

What this signals

Ephemeral workload visibility: Kubernetes programmes increasingly fail at the moment a pod starts behaving rather than at the moment it is deployed. That means the operational gap is not just missing software agents, but missing continuous visibility into workload execution, which is where abuse becomes observable.

The practical governance question for platform teams is how to split responsibility between admission controls and runtime controls. If a programme can only explain what entered the cluster, it is only governing half of the lifecycle and will miss the phase where behaviour changes.

Agentless scanning remains valuable for speed and breadth, but it should be treated as one layer in a control stack rather than the control stack itself. Runtime telemetry, policy enforcement, and workload identity need to be designed together if Kubernetes risk is going to be managed credibly.

For practitioners

• Separate build-time and runtime control objectives Define agentless scanning as the control for images, manifests, and registry posture, then assign runtime detection to agent-based sensors where live behaviour matters. Do not let one tool own both decisions by default.
• Prioritise agent-based coverage for short-lived workloads Give ephemeral pods, serverless Kubernetes patterns, and high-risk namespaces runtime monitoring first, because they can vanish before the next external scan cycle completes.
• Map CI/CD checks to admission gates Use agentless scanning in pipelines to stop vulnerable or noncompliant images before they reach the registry or cluster, and document which findings must block deployment versus warn only.
• Review runtime telemetry for behavioural indicators Look for reverse shells, unusual process spawning, unexpected file writes, and outbound connections inside containers, because those signals only appear once the workload is executing.

Key takeaways

• Kubernetes scanning is split between pre-deployment posture control and runtime behavioural detection, and each covers a different stage of risk.
• Ephemeral workloads create a visibility gap because they can disappear before external scanning sees malicious activity.
• Mature Kubernetes governance separates admission checks from runtime protection so build-time approval does not get mistaken for operational safety.

Key terms

• Agentless Scanning: A scanning method that inspects workloads from outside the target environment rather than by installing software inside it. In Kubernetes, this usually means using APIs, registries, or snapshots to assess images and configurations before or around deployment.
• Agent-Based Scanning: A scanning method that installs software on nodes or workloads to observe live behaviour. It can collect process, file, network, and syscall data, which makes it useful for runtime detection and for catching attacks that only appear after deployment.
• Ephemeral Cloud Workload: A workload that exists for a short time, often created and destroyed automatically as demand changes. Ephemeral systems are difficult for traditional security tools to track because they may appear, scale, and disappear before manual onboarding or agent deployment can keep pace.
• Runtime Security: Runtime security is the practice of detecting and constraining malicious behavior while software is executing. It focuses on live workload activity, not just code quality or pre-deployment checks, so teams can contain abuse after a system is already running.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.