Notifications
Clear all
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.
NHIMG editorial — based on content published by ARMO: How to Sandbox AI Agents on EKS: Where Each AWS Control Stops and What Fills the Gap
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when AI agents rely only on static EKS sandboxing controls?
A: Static controls still approve permitted APIs, ports, and syscalls even when an agent’s runtime behaviour becomes unsafe.
Q: Why do AI agents complicate Kubernetes least privilege?
A: Because their effective privilege is not fixed at deployment.
Q: How can security teams tell normal AI agent activity from misuse?
A: By building per-agent baselines for API frequency, payload size, destination patterns, and process behaviour, then comparing live activity against those baselines.
Practitioner guidance
- Define behaviour baselines before tightening agent policy Observe agent API calls, network destinations, and syscall patterns over a representative period, then use those observations to distinguish normal task variation from suspicious drift.
- Separate AWS service boundaries from cluster boundaries Use SecurityGroupPolicy for AWS service reachability and NetworkPolicy for pod-to-pod or non-AWS egress, then validate that both layers still allow only the destinations the agent actually needs.
- Add runtime attribution to authorised activity Ensure the security stack can tie an outbound connection or API call back to the exact agent action that triggered it, so authorised behaviour can still be judged against its business purpose.
What's in the full article
ARMO's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step EKS configuration patterns for IRSA, Pod Identity, SecurityGroupPolicy, NetworkPolicy, and seccomp in AI agent workloads.
- Behavioural profiling workflow showing how CloudTrail, runtime telemetry, and kernel signals are combined into enforceable policy.
- Progressive deployment sequence for moving from observe mode to selective enforcement without breaking production agents.
- Agent-specific troubleshooting guidance for mismatched permissions, drifting prompts, and changing tool integrations.
👉 Read ARMO's analysis of how to sandbox AI agents on EKS →
AI agent sandboxing on EKS: are your controls keeping up?
Explore further
20/08/2026 6:42 pm
Static least privilege is not a sufficient governance model for AI agents on EKS. The article shows that deploy-time controls can only describe intended access, while agent behaviour is determined at runtime by prompts and tool selection. That means the real governance problem is not permission assignment alone, but the mismatch between declared scope and actual execution. Practitioners should treat runtime observability as a governance requirement, not a monitoring extra.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface.
- A separate finding from the same research shows that 98% of companies plan to deploy even more AI agents within the next 12 months, which means behavioural governance pressure is likely to increase rather than ease.
A question worth separating out:
Q: Should organisations use both network and identity controls for AI agents?
A: Yes, but only as layered enforcement, not as a complete answer. Identity controls restrict what the agent may access, while network controls restrict where traffic may go. Neither one can determine whether a permitted action is actually safe, so runtime behavioural enforcement still has to fill the gap.
👉 Read our full editorial: AI agent sandboxing on EKS exposes the runtime governance gap
