Topic starter
20/08/2026 6:07 pm
TL;DR: AI agents on EKS can satisfy IAM, network, and syscall rules at deploy time while still behaving dangerously at runtime, because static controls cannot judge whether permitted actions are normal or exfiltration, according to ARMO. That gap makes behavioural baselines and runtime enforcement the decisive controls for AI agent governance.
Editorial analysis by NHI Mgmt Group, based on content published by ARMO: “How to Sandbox AI Agents on EKS: Where Each AWS Control Stops and What Fills the Gap”.
Key questions
Q: What breaks when AI agents on EKS are governed only by IAM and Kubernetes roles?
A: Static roles define what an agent may do, but they do not show what it actually did after the API call returned.
Q: Why do AI agents need runtime behavioural enforcement instead of only least privilege?
A: Because least privilege sets the boundary of what may happen, but not whether what is happening is normal for the current task.
Q: How do security teams know if an AI agent sandbox is actually working?
A: A working sandbox should stop execution, block privilege expansion, and prevent the agent from touching sensitive context even when the model is manipulated.
Practitioner guidance
- Define a runtime baseline for each AI agent Measure API calls, destinations, and syscall patterns over a representative observation window before narrowing access.
- Split identity scoping from behaviour validation Keep IRSA or EKS Pod Identity for credential issuance, but add runtime detection that correlates role use, network destinations, and prompt-driven tool calls.
- Apply task-scoped session constraints Use short-lived STS session policies for specific invocations when an agent’s permissions vary by task.
Bottom line: AI agents on EKS can remain inside policy while still behaving in ways that static IAM, network, and syscall controls cannot distinguish from abuse.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:42 pm
Runtime governance, not deploy-time approval, is the real control boundary for AI agents on EKS. IRSA, SecurityGroupPolicy, NetworkPolicy, and seccomp all assume the workload will behave in a stable way after it is approved. That assumption fails when prompts can change the agent’s action sequence, tool use, and network behaviour on demand. The implication is that identity governance for AI agents has to move from static authorisation to observed runtime behaviour.
A few things that frame the scale:
- 62% of organisations are at least experimenting with AI agents, but only 23% have scaled one into a single business function, according to McKinsey's 2025 State of AI survey.
A question worth separating out:
Q: What is the difference between destination controls and runtime attribution for AI agents?
A: Destination controls decide where traffic may go, while runtime attribution explains which prompt, tool call, or process initiated that traffic. For AI agents, both are needed because an approved destination can still carry malicious or unintended content. Without attribution, teams can see a connection but not the reason behind it.
👉 Read our full editorial: AI agent sandboxing on EKS exposes the runtime governance gap