Kubernetes runtime security is decided by where enforcement sits

At a glance

What this is: This comparison argues that Kubernetes runtime security is determined by enforcement placement, with in-cluster controls able to constrain actual workload behaviour more directly than gateway-based models.

Why it matters: For IAM, PAM, and platform security teams, the key issue is whether runtime control can actually limit workload action, reduce standing privilege, and generate enforceable policy from observed behaviour.

By the numbers:

• 45% of organisations

👉 Read ARMO's comparison of Kubernetes runtime enforcement models

Context

Kubernetes runtime security depends on whether controls can constrain what workloads actually do, not just what they are asked to do. In AI agent and cloud-native environments, the enforcement point matters because prompt filtering, traffic inspection, and workload restraint are not interchangeable control functions.

ARMO's comparison with Sweet Security is really a comparison between gateway-centric visibility and in-cluster enforcement. That distinction matters for identity-adjacent controls because workloads, service accounts, and agentic systems create blast radius through runtime action, not through detection alone.

Key questions

Q: How should security teams enforce least privilege for Kubernetes workloads?

A: Security teams should enforce least privilege at the point where the workload actually runs, not only at a gateway or perimeter checkpoint. That means watching real system calls, file access, and network connections, then converting observed behaviour into enforceable policy. The practical test is whether the control can block the action itself, not just detect it afterward.

Q: Why does gateway-based control fall short for runtime security?

A: Gateway-based control is useful for inspecting traffic, prompts, and routed operations, but it cannot fully govern actions that occur inside the cluster after the request is accepted. Once the workload executes, the meaningful security boundary is the runtime environment. That is why workload restraint needs kernel-level enforcement, not only traffic inspection.

Q: What breaks when runtime policies are guessed instead of observed?

A: Guessed policies often block legitimate periodic jobs, miss unusual but valid service flows, or leave overbroad permissions in place because they were written without behavioural evidence. Observed policies are more accurate because they reflect what the workload actually does. Without that evidence, least privilege becomes theoretical and brittle in production.

Q: Who is accountable when Kubernetes runtime controls fail to contain a workload?

A: Accountability sits with the team that owns both the workload identity and the enforcement boundary. If service accounts, runtime permissions, or agent workflows are not reviewed together, blast radius grows even when detection is present. Compliance and audit teams should expect evidence of control design, policy validation, and ownership for the runtime layer.

Technical breakdown

Gateway enforcement versus in-cluster enforcement

A gateway control point sits in front of traffic and can inspect prompts, API calls, or routed operations before they reach a destination. In-cluster enforcement sits where the workload executes, usually through kernel-level telemetry such as eBPF, so it can observe system calls, file access, process creation, and network connections. That placement gives the control a view of real runtime behaviour rather than inferred intent. For Kubernetes and AI workloads, that difference decides whether a security tool can stop the action itself or only the traffic that happens to pass through a perimeter checkpoint.

Practical implication: place enforcement where the workload executes if you need to restrict actual system behaviour, not just inspect traffic.

Observe-to-enforce policy generation

Observe-to-enforce models begin in monitoring mode, learning normal workload behaviour before converting that behaviour into policy. In Kubernetes, that can produce artefacts such as NetworkPolicies for allowed connections and seccomp profiles for system call restrictions. The technical value is that the resulting policy reflects evidence from the cluster rather than assumptions from a human reviewer. Audit mode matters because it reveals low-frequency but legitimate behaviours before blocking begins, reducing the risk of breaking periodic jobs, reconciliation tasks, or unusual service flows.

Practical implication: validate generated policies in audit mode before turning them on, especially for workloads with sporadic or seasonal behaviour.

Why kernel-level restrictions change least privilege

Kernel-level restrictions matter because they are enforced outside the workload's own logic. If an AI agent, container, or service account is manipulated at runtime, the attacker may alter behaviour, but the workload still cannot exceed the kernel controls that have been applied. This is especially relevant in Kubernetes because least privilege is not just an access review problem. It is also a runtime containment problem involving what the workload can open, execute, or connect to once code is running. The mechanism converts policy from documentation into a live execution boundary.

Practical implication: treat kernel-enforced policy as a blast-radius control, not just a compliance artefact.

Threat narrative

Attacker objective: The attacker wants to make the workload execute actions that runtime governance never meant to allow, while staying inside legitimate application flow.

1. Entry begins when an attacker or malicious prompt reaches an AI workload or Kubernetes service through normal application inputs or routed operations.
2. Escalation occurs if the workload can use standing runtime permissions to open files, spawn processes, or make network connections beyond its intended scope.
3. Impact follows when the workload performs unauthorised actions inside the cluster, expanding blast radius or exposing data despite upstream detection.

NHI Mgmt Group analysis

Gateway visibility is not the same as workload restraint. The article's central lesson is architectural: a control point in front of traffic can only govern what crosses it, while in-cluster enforcement can constrain what the workload itself does. That distinction matters more as Kubernetes becomes the runtime for AI agents and service workloads. For practitioners, the governance question is where enforcement can actually reduce blast radius, not where it can merely inspect activity.

Observed behaviour is a stronger basis for least privilege than guessed policy. A runtime platform that learns workload behaviour and converts it into NetworkPolicies or seccomp profiles has a more defensible control model than one that only classifies requests. This aligns with NIST CSF, NIST SP 800-53, and Kubernetes-native policy management because the policy is tied to real execution paths. Practitioners should treat generated hardening as evidence-backed access reduction, not just another alert source.

Kernel-level control is becoming the practical boundary for agentic systems. AI agents do not need full autonomy to create risk; they only need enough runtime permission to read, write, connect, or spawn processes outside intended scope. That is an NHI governance problem as much as a cloud runtime problem, because service accounts and agent workflows can turn ordinary permissions into large blast radius. Teams should expect identity governance to extend into runtime containment.

Cluster-native hardening is the next stage after detection. Detection tells you what happened, but Kubernetes control generation changes what can happen next. The named concept here is evidence-based least privilege: policy derived from real workload behaviour instead of manual assumptions. That is where the market is moving, and practitioners should re-evaluate whether their security stack can produce enforceable controls, not only correlation.

Open foundations change trust economics. The article also points to a broader governance pattern: auditability and inspectability matter when runtime controls influence production behaviour. For teams under compliance scrutiny, the ability to review generated policy logic and the underlying control foundation is not a nice-to-have. It is a prerequisite for operational trust and repeatable change management.

What this signals

The practical signal for platform teams is that runtime security is moving toward evidence-backed enforcement rather than broad detection coverage. When policy is derived from observed workload behaviour, security teams can justify narrower permissions and prove why specific connections, system calls, or file actions are blocked.

Evidence-based least privilege: this is the control pattern that will matter most as AI workloads and Kubernetes services accumulate more runtime permissions than reviewers can manually track. Teams that cannot connect identity governance to runtime containment will continue to manage blast radius after the fact rather than reducing it before execution.

As AI and Kubernetes estates grow, the boundary between identity governance and workload security becomes operational, not theoretical. The organisations that can tie service accounts, agent permissions, and kernel-level controls together will be better positioned to satisfy audit, resilience, and containment requirements.

For practitioners

• Map enforcement to the workload runtime Decide whether your control point must constrain prompt flow, network flow, or the kernel-level actions of the workload. For Kubernetes and agentic workloads, prioritise the layer that can block file access, process creation, and outbound connections inside the cluster.
• Validate generated policy in audit mode first Run observe-to-enforce tooling in a non-blocking mode long enough to capture low-frequency jobs, batch tasks, and reconciliation workflows. Promote only after the audit log shows that the proposed NetworkPolicies and seccomp rules match real behaviour.
• Reduce standing runtime permissions Review service accounts and application identities that have access they do not exercise during normal operation. Replace broad cluster-wide permissions with behaviour-based scope and retire privileges that are present only because the workload once needed them.
• Tie Kubernetes hardening to identity governance Include service accounts, workload identities, and AI agent permissions in the same governance review used for human access. The goal is to connect runtime restraint with identity lifecycle controls so that access does not outlive the workload's actual need.

Key takeaways

• The main issue is control placement, because gateway inspection and in-cluster restraint solve different problems.
• The article's strongest operational point is that observed workload behaviour can become enforceable Kubernetes policy.
• Practitioners should treat runtime enforcement as part of identity governance when service accounts and AI agents can expand blast radius.

Key terms

• Gateway Enforcement: Gateway enforcement is the use of the API gateway as the place where policy is applied before traffic reaches backend services. It combines authentication, rate limiting, quotas, segmentation, and logging so the organisation can control both access and consumption in one place.
• In-Cluster Enforcement: A security model that applies controls inside the Kubernetes environment where the workload runs. It can observe system calls, file access, and network activity, which allows policy to constrain the workload's real runtime behaviour instead of only its input traffic.
• 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.
• eBPF: eBPF is a Linux kernel technology that lets security tools observe selected system events without modifying the kernel itself. In runtime protection, it is used to watch syscalls, process activity, and host behaviour, which helps detect post-exploitation actions and policy violations.

What's in the full article

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

• A side-by-side breakdown of in-cluster eBPF enforcement versus gateway-based AI enforcement, including where each control point sees workload behaviour.
• Detailed runtime comparison data on 250+ Kubernetes controls, generated NetworkPolicies, and seccomp profile creation from observed behaviour.
• Implementation notes on the observe-to-enforce workflow, including audit mode validation before active blocking.
• How the open-source Kubescape foundation and admission controls fit into production Kubernetes hardening.

👉 ARMO's full blog explains the workload behaviour evidence, generated hardening, and enforcement trade-offs in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners connect lifecycle control to operational containment.