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.
Where Agentless Scanning Stops Being Enough
agentless scanning is strongest before a workload runs. It can inspect images, manifests, and admission-time configuration, but it cannot see what a live pod actually does after scheduling. Once the container starts, runtime state can diverge from what was approved, so the security question shifts from static posture to runtime container security and continuous observation.
That is why short-lived jobs, elastic pods, and internet-facing workloads are the hardest cases for agentless-only models. The control plane may still say the workload is compliant, while the process tree, file system, and outbound connections are behaving very differently from the original scan result.
In Kubernetes, that gap matters because many attack paths only appear after execution begins. A benign-looking image can pull payloads, spawn shells, tamper with files, or reach unexpected services once it is live, which is why Kubernetes runtime risk is distinct from image risk. NHIMG’s Kubernetes NHI Security Guide covers the workload access paths that become material once pods are running, while Kubeflow cryptomining attacks 2020 shows how exposed control surfaces and workload credentials can be abused after deployment.
What Runtime Blind Spots Leave Uncovered
Agentless tools generally rely on external signals such as API data, metadata, or periodic host queries. That means they can miss short-lived execution, transient file writes, process injection, memory-only activity, and east-west traffic that exists only for seconds. If the detection logic cannot observe the workload from inside or alongside the runtime path, the attacker benefits from the blind spot.
The practical consequence is that admission approval and runtime trust are not the same decision. A pod can pass policy checks and still become harmful minutes later through command execution, credential use, or unexpected network egress. For that reason, runtime controls need to watch behaviour, not just object state.
That behaviour gap is also why container-image hygiene and runtime telemetry complement each other instead of replacing one another. The presence of embedded credentials, for example, remains a separate exposure path even if the image itself was accepted by policy. NHIMG’s Secrets in Docker Hub images (RWTH Aachen study) is a useful reminder that image-layer inspection and live-process monitoring solve different problems.
What Security Teams Need Next
Agentless scanning is still useful for shift-left checks, inventory, and admission gating, but it should be treated as one layer in a broader Kubernetes control stack. When workloads are ephemeral, privileged, or exposed to the internet, a separate runtime control is needed to detect execution changes, suspicious file activity, and anomalous network behaviour while the pod is live.
When the platform also uses workload credentials or service account tokens, the access layer becomes part of the runtime problem. NHIMG’s NHI Lifecycle Management Guide is relevant because rotation, offboarding, and visibility decisions affect how much damage a live container can do if it is compromised. For teams comparing controls, the key question is not whether scanning exists, but whether anything is watching the workload after the approval point.
In practice, the best runtime layer is the one that can answer three questions fast: what changed, what the pod touched, and what it reached. If a control cannot attribute those events at pod speed, it is not closing the gap that agentless scanning leaves open.
Risk and Threat Considerations
Agentless-only coverage creates a false sense of closure because the highest-risk actions often happen after the image has passed review. Attackers can wait for execution, then abuse the container’s live privileges, filesystem, or network reach before the next scan cycle or policy refresh.
Failure mechanism: The control cannot observe runtime behaviour inside the pod, so process launches, file tampering, in-memory payloads, and unexpected outbound traffic go undetected until after impact.
Impact: A compromised workload can mine, exfiltrate, pivot, or abuse credentials while still appearing clean at admission time, which increases blast radius on short-lived and exposed workloads.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, OWASP ASVS, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Runtime pod behaviour needs active monitoring beyond admission checks. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Runtime events must be reviewed to close the gap left by agentless scans. | |
| Recommendation — Monitor live workload events to detect suspicious container execution and network activity. Review pod and node telemetry to spot behaviour that diverges from approved state. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | Live workload monitoring depends on logs and alerts that capture runtime changes. |
| Recommendation — Instrument applications so runtime actions and failures are logged for investigation. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Kubernetes runtime detection depends on collected logs and preserved evidence. |
| Recommendation — Centralise and retain container and cluster logs to support detection and response. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | Agentless scanning misses live anomalies, so continuous monitoring becomes central. |
| Recommendation — Continuously monitor workloads for anomalous execution, file, and network behaviour. | ||
Practitioner Guidance
What to prioritise: Treat runtime visibility as mandatory for any cluster that runs internet-facing services, batch jobs with external inputs, or pods that mount credentials. Those are the environments where admission-only assurance fails fastest.
What to verify: Confirm that the runtime control can see process creation, file-system change, and outbound connection events at pod scope, and that those events are retained long enough to support incident triage.
Common mistake: Do not equate “image scanned” with “workload safe”. That shortcut is especially weak when containers are short-lived, autoscaled, or capable of reaching secrets and internal services.
Practitioner takeaway: Agentless scanning is a useful gate, not a complete kubernetes security model; the control that matters next is the one that can still observe the workload after it starts behaving.
Related resources from NHI Mgmt Group
- How should security teams combine agentless and agent-based Kubernetes scanning?
- What breaks when Kubernetes security only focuses on scanning images and manifests?
- What breaks when CI/CD security relies only on artifact scanning?
- What breaks when software supply chain security relies only on SCA scanning?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org