You miss the live attack path. Scanning can catch misconfigurations and known vulnerabilities before deployment, but it cannot see privilege escalation, shell access, or abnormal connections after a workload starts running. That leaves a large operational gap between “passed security review” and “safe in production.”
Why This Matters for Security Teams
Container image and manifest scanning are valuable, but they only answer what was present before deployment. They do not show how a running pod behaves after it starts, what it can reach over the network, or whether an attacker can turn a low-risk misstep into live privilege escalation. That gap is especially dangerous for Kubernetes because workloads are ephemeral, highly connected, and often over-permissioned by default.
The practical problem is not a missed CVE alone. It is the false confidence that comes from a clean pipeline while runtime reality remains unobserved. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which helps explain why a workload can pass admission checks and still become an attack pivot once it is live. For a broader control baseline, NIST Cybersecurity Framework 2.0 reinforces the need to manage, monitor, and respond to active risk, not just pre-deployment artifacts.
In practice, many security teams discover lateral movement only after a pod has already talked to something it should never have reached.
How It Works in Practice
Runtime kubernetes security needs to extend beyond image provenance and YAML review into live workload behaviour. Scanning can still catch known package issues, risky privileges, and obvious misconfigurations, but it does not reveal whether a container later opens a shell, mounts sensitive paths, steals a service account token, or initiates unexpected outbound connections. Those are the indicators that matter when the question is not “is this workload clean?” but “what can it do right now?”
Effective programs combine deployment-time checks with runtime controls and telemetry. That usually includes:
- Admission controls for baseline policy, such as restricting privileged pods, host networking, and unsafe capabilities.
- Runtime detection for process execution, file access, unusual syscalls, and abnormal east-west traffic.
- Workload identity tied to the pod or service, so access decisions reflect what the workload is and what it is doing.
- Short-lived credentials and token rotation so a stolen secret has a narrow window of usefulness.
This is where guidance from NIST Cybersecurity Framework 2.0 and NHI-focused guidance such as Ultimate Guide to NHIs becomes operational: both point practitioners toward continuous visibility, protection, and response rather than one-time approval. Current best practice is to treat manifests as input to control selection, not as evidence of runtime safety.
The model breaks down when clusters rely on static service accounts, long-lived tokens, or broad namespace permissions because scanning cannot compensate for live trust that is already too large.
Common Variations and Edge Cases
Tighter runtime enforcement often increases operational overhead, requiring teams to balance faster delivery against deeper inspection and more policy tuning. That tradeoff is real, especially in clusters with many short-lived jobs, noisy service meshes, or development teams that change workloads frequently.
There is no universal standard for exactly how much runtime telemetry is enough. Some organisations use lightweight eBPF-based detection, others rely on network policies and audit logs, and mature environments layer all three. The important distinction is that image scanning remains a hygiene control, not a detection strategy for active compromise.
Edge cases matter most in CI/CD-heavy environments, blue-green deployments, and auto-scaling workloads where the attack path may appear only after startup. This is also where dependency on third-party tooling, shared namespaces, or inherited node permissions can obscure the real blast radius. The State of Non-Human Identity Security shows why this matters: only 1.5 out of 10 organisations are highly confident in securing NHIs, which is consistent with the gap between pipeline assurance and runtime control.
So the practical answer is that scan-only programs miss the live abuse path, and that gap becomes most visible when a workload is already executing with more privilege than the scan ever knew about.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A-03 | Runtime abuse and tool misuse mirror agentic execution risks. |
| CSA MAESTRO | M1 | MAESTRO emphasizes runtime governance beyond static artifact review. |
| NIST AI RMF | GOVERN | Governance must cover operational behaviour, not only pre-release checks. |
Instrument live execution paths and alert on unexpected tool use or privilege escalation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
