Kubernetes runtime enforcement beats validation-first detection

At a glance

What this is: This is an analyst-style comparison of ARMO and Upwind that concludes detection parity matters less than whether runtime signals can be converted into enforced prevention.

Why it matters: It matters to IAM and security teams because workload behaviour, Kubernetes policy, and agentic runtime controls increasingly define who or what can act in production.

By the numbers:

• 69% of organisations now have more machine identities than human ones.
• Only 38% have automated certificate lifecycle management in place.

👉 Read ARMO's comparison of runtime enforcement versus validation-first detection

Context

Kubernetes runtime security is moving from exposure validation toward enforceable controls that can change what a workload is allowed to do after it starts. For identity teams, the relevant question is whether runtime observability is being used only to generate findings, or whether it is being translated into policy for service accounts, workload identities, and agentic systems that operate inside production clusters.

In this article, ARMO is presented as an observe-to-enforce model, while Upwind is framed as validation-first. The distinction matters because runtime detection by itself does not reduce privilege, constrain outbound behaviour, or stop a malicious chain once it has begun; those outcomes depend on policy enforcement tied to live workload behaviour.

That starting point is typical for teams that have strong detection but uneven runtime governance, especially where Kubernetes, secrets, and workload identity controls have developed separately.

Key questions

Q: How should security teams tell whether a runtime platform really blocks attacks?

A: Ask the vendor to generate a least-privilege policy from a live workload’s observed behaviour and then enforce it in production with rollback available. If the platform only validates exposure or prioritises alerts, it is helping with triage, not prevention. The control should be concrete, workload-specific, and reversible.

Q: When does runtime detection fail to reduce Kubernetes risk?

A: It fails when alerts do not change policy, execution rights, or network reach. If a platform can only describe a container escape, reverse shell, or privilege escalation after the fact, then the risk remains intact. Teams should treat detection as useful evidence, but not as a substitute for prevention or least privilege.

Q: What do organisations get wrong about behavioural security baselines?

A: They often treat baselines as a detection feature instead of a governance model. A useful baseline must reflect identity relationships, context, and normal sequences across the enterprise. If it only scores isolated anomalies, it will miss coordinated activity that looks normal in each individual system.

Q: Who should be accountable when runtime policy blocks a workload unexpectedly?

A: Accountability should sit with the owner of the workload or service account, not with the security tool alone. Teams need an approval path for policy promotion, a rollback process, and clear ownership for exceptions. That keeps enforcement from becoming an unmanaged operational surprise.

Technical breakdown

Observe-to-enforce in runtime security

Runtime platforms built around eBPF can observe system calls, process starts, file access, and network destinations without modifying application code. The key architectural difference is what happens next. A validation-first model uses that telemetry to confirm exposure and prioritise work. An enforce-first model uses the same telemetry to generate policy, such as seccomp rules and NetworkPolicies, then applies them back to the workload. That turns observation into a control loop rather than a reporting loop.

Practical implication: test whether runtime telemetry becomes enforceable policy, not just a ranked alert queue.

Application profile baselines and least-privilege generation

A behavioural baseline captures what a workload actually does during a representative window. In this case, the baseline is used to derive least-privilege controls from observed runtime behaviour rather than from static assumptions about what the workload might need. That approach is especially relevant for Kubernetes services and AI agents, where access patterns can be narrow but dynamic. If the baseline is accurate, generated controls can reduce privilege without requiring manual rule writing for every service or container.

Practical implication: validate whether baseline windows are representative before trusting generated least-privilege policy.

Correlating cloud, Kubernetes, container, and application events

Many tools surface isolated alerts from different layers, which forces analysts to reconstruct the chain manually. A correlated attack story links signals across cloud, cluster, container, and application layers into one sequence, making runtime investigation and response faster. This matters because a useful security narrative is not just about proving something happened. It is about identifying the exact point where behaviour shifted from normal to unsafe, and whether policy could have blocked the next step.

Practical implication: favour tooling that preserves an end-to-end attack sequence across layers you already operate.

Threat narrative

Attacker objective: The attacker aims to use a live workload’s runtime permissions and trusted execution context to move further inside the environment without being stopped at the policy layer.

1. Entry occurs when a workload or agent begins behaving outside its normal baseline, such as reaching an unapproved destination or invoking an unlisted process path inside the cluster.
2. Escalation follows when that deviation is not constrained by generated least-privilege policy, allowing the workload to continue into lateral or outbound activity that should have been blocked.
3. Impact is the successful continuation of the malicious chain, including container abuse, credential theft, lateral movement, or data movement that alert-only tooling would merely report.

NHI Mgmt Group analysis

Detection parity is not the decision point when runtime policy can be enforced. If two platforms see the same workload behaviour, the differentiator is whether that signal becomes a blocking control or remains an investigation aid. That distinction matters most in Kubernetes, where workloads can move quickly and alerts age faster than remediation cycles. For identity programmes, the same principle applies to workload identities and service accounts: visibility without enforceability does not reduce standing risk.

Runtime security is increasingly a governance problem, not just a detection problem. Teams do not need more evidence that workloads behave dynamically. They need proof that dynamic behaviour can be bound to least privilege, rollback, and auditable change control. In practice, that brings Kubernetes runtime policy into the same governance conversation as IAM, PAM, and secrets management, because all of them decide what can act in production.

Application Profile DNA is a useful name for an older control idea: behaviour-derived least privilege. The concept is not that workloads become predictable, but that policy should be based on observed production behaviour rather than assumed entitlement. That is especially relevant for agentic systems and service accounts that accumulate access over time. The practitioner takeaway is to treat behavioural baselines as control inputs, not just observability artefacts.

Open, auditable enforcement changes trust evaluation in platform security. When a runtime tool can be run, inspected, and validated by the customer, trust moves from vendor assertion to operational verification. That is important in cloud-native environments where the control plane itself becomes part of the risk surface. Practitioners should prefer platforms that can show their work in the cluster, not only in marketing material.

For agentic workloads, enforcement must follow the agent’s own behaviour, not just the cluster’s baseline. An AI agent can inherit permissions, invoke tools, and change actions within a single runtime session, which makes post-hoc validation less useful than active constraint. The governance implication is clear: agent identity, workload identity, and runtime policy now intersect, and teams need controls that can limit the agent before misuse expands.

What this signals

Runtime enforcement is becoming part of identity governance because Kubernetes workloads, service accounts, and agents now behave like durable access subjects. The programme signal is to stop treating runtime telemetry and identity policy as separate workstreams, especially where short-lived workload activity can still cause long-lived impact if it is not constrained at execution time.

Behaviour-derived least privilege: this is the emerging control pattern where observed workload behaviour becomes the basis for runtime policy. That means teams should expect pressure to connect observability, IAM, PAM, and secrets governance into a single operational loop. The strongest next move is to align policy generation with ownership, rollback, and audit evidence rather than standalone detection dashboards.

For practitioners

• Separate detection from enforcement in your POC criteria Require the vendor to show a workload-specific policy generated from observed runtime behaviour, then prove it can be enforced with rollback enabled. If the product only validates exposures and does not change runtime permissions, it is not solving the prevention problem.
• Test least-privilege generation against a real Kubernetes workload Use one service with known dependencies and ask the platform to derive seccomp and network controls from its production behaviour. Reject outputs that cannot be explained back to the workload’s actual process and network profile.
• Map runtime signals to identity ownership Tie each workload, service account, and agent to a clear owner so generated controls and exceptions have accountable approval paths. This reduces the chance that runtime policy becomes another unmanaged security layer.
• Correlate runtime enforcement with audit evidence Keep a record of what changed, when a policy moved from observe to enforce, and which workload baseline justified it. That evidence matters for incident review, compliance, and rollback decisions.

Key takeaways

• Detection parity does not settle the comparison when one platform can turn runtime evidence into enforced prevention.
• Behaviour-derived least privilege is the more durable control model for Kubernetes workloads, service accounts, and agents.
• Identity teams should treat runtime policy, ownership, and rollback as part of the same governance boundary.

Key terms

• Observe-to-Enforce: A runtime security pattern where telemetry from a live workload is used to generate and apply controls back to the same environment. It moves beyond detection by turning observed behaviour into enforceable policy, usually for network, syscall, or identity boundaries.
• Application Profile DNA: A behavioural baseline built from what a workload actually does in production, including processes, network destinations, and system calls. It is used to derive least-privilege controls from evidence rather than from guessed or static entitlement models.
• Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.
• Behaviour-Derived Least Privilege: A control approach that sets access boundaries from observed workload behaviour instead of broad pre-approved permissions. It is especially relevant for Kubernetes services, service accounts, and AI agents that can act quickly and autonomously once deployed.

What's in the full article

ARMO's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step observe-to-enforce workflow for generating seccomp and NetworkPolicy controls from live workload behaviour
• Concrete proof-of-concept criteria for deciding whether a platform only validates or truly blocks runtime behaviour
• Details on ARMO's attack-story correlation across cloud, Kubernetes, container, and application layers
• Practical guidance on using runtime policy rollback without breaking production workloads

👉 ARMO's full post covers the enforcement loop, attack-story correlation, and proof-of-concept guidance in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It helps practitioners connect runtime enforcement decisions to broader identity governance and access control programmes.