TL;DR: Runtime security tools that only validate exposures leave the decisive control gap untouched, because detection alone does not stop a live workload from continuing into harmful activity, according to ARMO. In its comparison with Upwind, the practical distinction is enforceable least-privilege policy generated from observed behavior, not just alerts, which makes runtime prevention the real decision point.
At a glance
What this is: This comparison says Kubernetes runtime tools may detect similarly, but the decisive difference is whether they only validate exposures or actually enforce least-privilege controls that block the next incident.
Why it matters: For IAM and security teams, the practical issue is whether runtime evidence becomes an alert queue or an enforceable control that changes workload behaviour and reduces blast radius.
Context
Kubernetes runtime security is not just about seeing suspicious behaviour. The governance gap appears when a platform can confirm a workload is exposed but cannot translate that signal into a control that stops the next malicious action, which leaves detection detached from prevention.
In this article's framing, runtime observation matters most when it produces least-privilege policy for workloads and agents. That makes the identity question explicit: what each workload, service, or agent is allowed to do at runtime, and whether that permission set can be enforced without breaking production.
The article compares two runtime approaches and argues that validation alone is operationally weaker than observable enforcement. That is typical of modern container environments, where speed, ephemerality, and distributed execution make post-detection remediation too late to be the primary control.
Key questions
Q: What are the signs that Kubernetes runtime protection is actually seeing an attack?
A: Strong indicators include alerts for illegitimate shells, suspicious command execution, and unexpected attempts to read service account tokens or spawn new pods. If the sensor logs those actions in real time, it is observing behavior that defenders need. If those signals are absent during a controlled test, the deployment or policy coverage is incomplete.
Q: Why is validation alone not enough for Kubernetes runtime security?
A: Because validation proves an exposure exists, but it does not stop the running workload from continuing into the next malicious step. In Kubernetes, that means the gap remains live until an enforceable control changes what the workload can do. Prevention has to be runtime-native, not deferred to post-detection cleanup.
Q: What do security teams get wrong about container runtime detection?
A: They often treat runtime detection as a secondary add-on instead of the control that catches threats after build-time and posture checks have already been bypassed. Runtime visibility matters because zero-day abuse, container escapes, and anomalous connections can emerge only after deployment. If runtime is missing, the programme assumes pre-deployment controls will always hold.
Q: What is the difference between runtime validation and runtime enforcement?
A: Validation tells you that a workload's behaviour or exposure matches a suspicious or risky pattern, while enforcement constrains that workload so the same action cannot continue unchecked. The first supports prioritisation and investigation. The second changes the permission boundary and reduces the chance that a live attack progresses.
Technical breakdown
Validation-first detection versus enforceable runtime control
Validation-first runtime security uses live signals to confirm that an exposure or suspicious action is real, then hands the issue to a human or another workflow. That is useful for reducing noise, but it stops short of changing the workload's effective permissions. Enforcing runtime security goes further by turning observed behaviour into controls that can block the same action next time. In Kubernetes, that difference matters because the live container remains active after validation. The security model is not complete until the signal becomes a policy that constrains execution, networking, or privilege.
Practical implication: Treat runtime validation as input to control generation, not as the control itself.
Behaviour baselines, seccomp profiles, and network policy generation
A behaviour baseline captures what a workload normally does, such as system calls, process launches, and outbound connections. From that baseline, a platform can generate a seccomp profile to restrict kernel-level system calls and a NetworkPolicy to limit where the workload can connect. The technical value is that policy is derived from observed evidence rather than guessed in advance. That matters in Kubernetes because least privilege is hard to define manually for dynamic workloads and agents. When the policy is native to the cluster, it can be enforced and rolled back without changing the application code.
Practical implication: Build least-privilege policy from observed workload behaviour, then test enforcement with rollback enabled.
Attack-story correlation across cloud, Kubernetes, container, and application layers
Security tools often produce isolated alerts that describe one symptom at a time. Correlation turns those fragments into an attack story by linking cloud events, Kubernetes activity, container behaviour, and application-layer signals in sequence. That is not merely a reporting improvement. It helps operators understand whether a suspicious action is an isolated anomaly or part of a chain that moved from one layer to another. In runtime environments, the chain is what matters because lateral movement, payload staging, and exfiltration often cross control boundaries before anyone acts.
Practical implication: Prioritise platforms that preserve cross-layer context so response is based on attack progression, not alert volume.
Threat narrative
Attacker objective: The attacker wants to keep a live workload moving from suspicious behaviour into a completed incident without the platform converting detection into prevention.
- Entry occurs through a workload or dependency behaving outside its normal runtime baseline inside the Kubernetes cluster.
- Escalation happens when validation-only tooling observes the deviation but does not prevent the workload from continuing into harmful actions.
- Impact is reduced when enforcement-derived controls block the next malicious network request, system call, or process path before the chain completes.
Breaches seen in the wild
- Kubeflow cryptomining attacks 2020: Exposed Kubeflow dashboards and a notebook's mounted Kubernetes service account let attackers run cryptominers on tens of ML clusters.
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
Runtime validation is not a sufficient control if the workload can still continue. Detection reduces uncertainty, but it does not change the permissions that allowed the action in the first place. In Kubernetes environments, that means the decisive governance question is whether runtime evidence is converted into enforceable least privilege or left as an advisory signal. Practitioners should judge tooling by what it can stop, not just what it can observe.
Behaviour-derived policy is the most defensible way to operationalise least privilege for dynamic workloads. Static policy design struggles with containers, agents, and other ephemeral services because their legitimate behaviour is often discovered only in production. A baseline that translates observed behaviour into seccomp and network controls makes the privilege boundary explainable and auditable. The named concept here is observe-to-enforce runtime governance, where runtime evidence becomes the control plane for the next decision.
Kubernetes runtime security now has an identity dimension, even when the article is not about IAM directly. Every workload, service, and agent is a runtime actor with an allowed action set, and the question is whether that set is enforced or merely inferred. That is why identity security teams should treat workload permissions as living policy, not as a one-time validation outcome. The practitioner conclusion is simple: if the control cannot constrain runtime behaviour, it is not the final control.
Cross-layer correlation is increasingly the difference between containment and investigation theatre. Cloud, cluster, container, and application telemetry become more useful when they tell one story about how an incident unfolds. That improves both operational response and governance evidence because teams can show how a malicious sequence progressed and where enforcement interrupted it. Practitioners should require attack-story correlation, not just more alerts, from any runtime platform they evaluate.
What this signals
Observe-to-enforce is the right mental model for Kubernetes runtime governance. Teams should stop asking whether a tool can detect suspicious behaviour and start asking whether it can turn that behaviour into blocking policy. That shift matters because workload identity in motion is governed at execution time, not after the alert lands.
Runtime security programmes will increasingly be judged by whether they preserve auditability without sacrificing containment. If a platform can generate policy from observed workload behaviour and still give operators rollback, it supports both operational safety and security enforceability.
Kubernetes teams should expect the control conversation to move from visibility metrics to permission boundaries. The practical question is no longer how many alerts a tool creates, but whether the workload can still do the thing that triggered the alert.
For practitioners
- Implement observe-to-enforce workflows for Kubernetes workloads Baseline representative workload behaviour, generate candidate seccomp profiles and NetworkPolicies from that baseline, and promote them only after a rollback path is confirmed.
- Test whether runtime tools can block, not only flag Run a proof of concept that asks the platform to turn observed runtime behaviour into an enforced control inside the cluster, then verify whether the workload is actually constrained.
- Require cross-layer incident narratives Choose tooling that correlates cloud, Kubernetes, container, and application signals into one attack story so response teams do not reconstruct the sequence manually.
- Set policy boundaries for high-confidence deviations first Scope hard blocking to well-understood workload behaviours and use alert-only handling for ambiguous actions until the baseline is mature enough for enforcement.
Key takeaways
- Kubernetes runtime security is only partially solved by detection when the workload keeps running after validation.
- Behaviour-derived controls such as seccomp profiles and NetworkPolicies turn runtime evidence into a real permission boundary.
- Teams should evaluate runtime platforms by whether they can enforce least privilege in the cluster, not just explain exposures.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Runtime enforcement is positioned here as a control against common post-compromise attack movement in clusters. |
| Recommendation — Map runtime deviation to TA0006 and TA0008, then constrain the workload paths those tactics rely on. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on turning observed behaviour into enforced permissions for workloads. |
| Recommendation — Apply PR.AA-05 to keep workload permissions aligned to observed runtime need. | ||
| CIS Controls v8 | CIS-5 — Account Management | The piece argues for governing runtime actor permissions rather than only detecting misuse. |
| Recommendation — Use CIS-5 to review workload and service access paths that still allow harmful runtime actions. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Kubernetes workloads and agents are service actors whose runtime access must be constrained. |
| Recommendation — Apply IA-9 to authenticate service and workload identities before they reach protected runtime actions. | ||
Key terms
- Observe-to-Enforce: A policy generation approach that starts by monitoring workload behaviour and then converts that behaviour into blocking rules. It is useful when teams need evidence-based policy, because audit mode can validate the controls before they are activated.
- Seccomp Profile: A seccomp profile is a Linux control that restricts which system calls a workload can execute. When generated from observed behaviour, it becomes a workload-specific execution guardrail that reduces kernel attack surface while preserving normal application function.
- Network Policy: A Kubernetes Network Policy is a rule that controls which pods can communicate with each other and with external endpoints. It is a policy object, not a complete security boundary, and its effectiveness depends on accurate labels, current topology, and continuous maintenance as the cluster changes.
- Workload Baseline: A behavioural profile built from the combined activity of multiple processes, tasks, or agent instances sharing the same runtime boundary. It is useful for operations, but for security it can hide malicious deviation when one actor’s behaviour is averaged into the group.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. The course helps security practitioners connect workload identity, secrets management, and runtime governance to broader identity programmes.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org