Notifications
Clear all
Topic starter
18/08/2026 2:48 pm
TL;DR: Kubernetes runtime security splits between detect-and-gate and observe-and-generate, with behavior-derived controls stopping the next attack before it runs, according to ARMO. For teams running Kubernetes and AI workloads at scale, the governance question is whether prevention should be learned from workload behavior or written in advance.
NHIMG editorial — based on content published by ARMO: ARMO vs Microsoft Defender for Cloud: Why Generated Prevention Beats Detect-and-Gate
By the numbers:
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems.
- Only 44% of organisations have implemented any policies to manage their AI agents.
Questions worth separating out
Q: What fails when Kubernetes security relies only on detect-and-gate controls?
A: Detect-and-gate can stop known bad activity, but it still depends on policies written before the workload’s real behavior is understood.
Q: Why do AI agents make least privilege harder to enforce?
A: AI agents can move across multiple services, make autonomous decisions, and trigger several machine-to-machine actions in one task.
Q: How do you know if runtime enforcement is actually reducing risk?
A: You know it is working when the control changes the expected loss curve rather than just generating logs.
Practitioner guidance
- Define runtime ownership for workload identities Assign a named owner for each Kubernetes workload, service account, and AI agent that can approve or reject generated policies.
- Pilot generated NetworkPolicies and seccomp profiles Start in observe mode, compare generated policies with current entitlements, then move to audit mode before enforcement.
- Map container detections to identity and privilege paths When a runtime alert fires, trace which service account, token, or API key allowed the workload to expand beyond its expected boundary.
What's in the full article
ARMO's full blog covers the operational detail this post intentionally leaves for the source:
- How generated NetworkPolicies and seccomp profiles are created from observed workload behavior
- The stepwise observe, audit, enforce workflow used to operationalise runtime prevention
- The concrete comparison between ARMO and Microsoft Defender for Cloud across Kubernetes depth, Azure integration, and compliance coverage
- Examples of attack-story correlation across application, cloud, Kubernetes API, and host layers
👉 Read ARMO's comparison of generated prevention versus Microsoft Defender for Cloud →
Kubernetes runtime prevention: are detect-and-gate controls enough?
Explore further
18/08/2026 3:30 pm
Generated prevention is a governance model, not just a detection model. The architectural break is that runtime data is used to create least-privilege policy rather than only to confirm violations after the fact. That changes the control conversation for Kubernetes, AI workloads, and NHI governance because the policy boundary becomes evidence-based. Practitioners should view this as a move from static intent to living enforcement.
A question worth separating out:
Q: Who should own enforcement when workload behaviour and identity both matter?
A: Platform, cloud security, and identity teams should share the operating model, but a single accountable owner must approve policy changes. That is necessary because runtime enforcement affects both application function and identity privilege. Without clear ownership, teams will either over-permit to avoid outages or under-enforce to avoid disputes.
👉 Read our full editorial: Generated prevention versus detect-and-gate for Kubernetes runtime
