AI agent sandboxing on EKS exposes the runtime governance gap

At a glance

What this is: This is an analysis of how EKS-native controls scope AI agent workloads and where those controls fail when agent behaviour changes at runtime.

Why it matters: It matters because IAM, PAM, and security architecture teams need controls that govern AI agent intent, not just declared permissions, as agents can misuse legitimate access without tripping static policy.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 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.

👉 Read ARMO's analysis of how to sandbox AI agents on EKS

Context

AI agent sandboxing on EKS is fundamentally a runtime governance problem, not just a Kubernetes hardening exercise. The primary issue is that controls such as IRSA, SecurityGroupPolicy, NetworkPolicy, and seccomp assume the workload behaves consistently after deployment, while AI agents change actions based on prompts and tool use.

For IAM and identity teams, that means the security question is not simply whether an agent has access to a resource. The harder question is whether a permitted action is legitimate in the current runtime context, especially when an agent can use authorised credentials in a way that looks normal to CloudTrail but abnormal to the business.

ARMO’s article uses EKS as the example platform, but the governance gap is broader: static entitlements are not the same as runtime trust. That distinction matters for NHI governance, workload identity, and any programme trying to apply least privilege to systems that decide at execution time.

Key questions

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. The failure is not lack of policy, but lack of behavioural context. AI agents can remain formally authorised while exfiltrating data, overusing allowed endpoints, or changing their access pattern in ways traditional Kubernetes controls cannot detect.

Q: Why do AI agents complicate Kubernetes least privilege?

A: Because their effective privilege is not fixed at deployment. An agent can load different tools, call different endpoints, and exercise identity in ways the manifest did not predict. Least privilege therefore has to be derived from observed runtime behavior, otherwise entitlement reviews overstate or understate the access the agent actually needs.

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. A single authorised action is not enough to prove safety. The signal comes from the sequence, volume, and context of actions over time.

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.

Technical breakdown

Why static EKS controls miss AI agent intent

IRSA, EKS Pod Identity, SecurityGroupPolicy, NetworkPolicy, and seccomp all enforce what a workload may do based on policy defined before execution. That works for deterministic services, where behaviour is stable and permission boundaries are predictable. AI agents break that model because the same identity can issue different API calls, network requests, and syscalls depending on the prompt, tool chain, or retrieved context. The result is a control stack that can approve every individual action while missing the behavioural pattern that makes the sequence unsafe.

Practical implication: treat deploy-time policy as a baseline, not as proof of safe runtime behaviour.

Why authorised API calls can still represent exfiltration

IAM answers whether an identity may call an API on a resource. It does not judge whether the pattern of calls reflects normal agent behaviour. An AI agent can use valid credentials to make thousands of allowed S3 reads, send oversized model prompts, or access permitted endpoints in a sequence that indicates data exfiltration. CloudTrail and similar logs will show authorised activity, which is why cross-layer correlation is required. The missing layer is behavioural context, not just more permission checks.

Practical implication: establish per-agent baselines for call frequency, payload size, and destination patterns before tightening access.

How kernel-level enforcement closes the runtime gap

Kernel-level telemetry gives security teams a way to connect the prompt, tool invocation, process activity, and outbound connection into one story. That matters because the security event is not the syscall or the API call alone, but the combination of runtime signals that shows whether the agent is behaving within its intended boundary. In AI agent environments, that is the difference between static allow lists and enforceable runtime trust. The architectural shift is from declared access to observed behaviour.

Practical implication: pair static Kubernetes controls with runtime detection that can attribute activity to the specific agent action that caused it.

Threat narrative

Attacker objective: The attacker seeks to convert valid AI agent access into controlled data theft or misuse without triggering conventional allow or deny controls.

1. Entry occurs when an AI agent uses legitimately granted cloud credentials, pod identity, or service-account-based access to reach allowed AWS services or internal endpoints.
2. Escalation occurs when the agent is influenced by a prompt, tool chain, or runtime context to use those permissions in a sequence that exceeds its intended operational scope.
3. Impact occurs when the permitted activity becomes data exfiltration, sensitive context leakage, or unauthorized interaction with downstream systems while still appearing authorised in standard logs.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Behavioural drift is the specific failure mode that EKS-native controls cannot see. An AI agent may be compliant at provisioning and still become risky the moment its prompt path changes. That is why policy based on resource lists or syscall allowlists remains incomplete for agent workloads. The practical conclusion is that governance must be tied to observed action patterns, not just identity configuration.

Runtime trust debt is the right name for the gap this article exposes. The longer teams rely on static identity and network controls alone, the more they accumulate unmeasured exposure between allowed access and safe use. This is not a tooling nuance, it is an architectural blind spot in how identity governance is currently applied to AI agents. Security teams should recognise this as a boundary problem, not a tuning problem.

AI agent governance now sits at the intersection of IAM, workload identity, and autonomous decision paths. Even when an agent is not fully autonomous, its runtime variability makes it behave differently from ordinary NHI workloads. That means identity teams can no longer separate access control from behaviour control when the same actor can change its request pattern with each prompt. The field needs governance models that combine entitlement, context, and execution evidence.

From our research:

• 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.
• That makes runtime enforcement the next control plane to examine, and the practical implications of agent identity risk are covered further in OWASP Agentic AI Top 10.

What this signals

Runtime trust debt: the longer teams rely on deploy-time policy alone for AI agents, the more exposure accumulates between allowed access and safe execution. With 80% of organisations already reporting agent actions beyond intended scope, the governance gap is operational, not theoretical.

Security teams should expect more demand for policy that is learned from observed behaviour rather than declared intentions. That shifts programme priorities toward runtime telemetry, identity attribution, and controls that can explain why an allowed action was nevertheless unsafe.

For teams mapping this to standards, the architectural context aligns closely with the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10, because both treat context, misuse, and runtime behaviour as first-class governance concerns.

For practitioners

• 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. This prevents policy from being built on assumptions that do not match runtime reality.
• 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.
• Scope sessions to task-level intent Where the workflow allows it, issue short-lived session policies that narrow permissions to the current task instead of the broadest possible agent role. That reduces the usefulness of stolen or misused credentials.

Key takeaways

• AI agent sandboxing on EKS fails when teams mistake static permission checks for runtime trust.
• The evidence points to behavioural drift as the real gap, since authorised actions can still represent exfiltration or misuse.
• Practitioners need layered identity, network, and kernel-level enforcement tied to observed behaviour, not just declared access.

Key terms

• Runtime Identity Trust Debt: Runtime identity trust debt is the accumulation of hidden access paths that remain active after a workload, client, or integration changes. It appears when ephemeral design assumptions are not matched by offboarding, revocation, and lifecycle controls, leaving old trust in place.
• Behavior Baseline: A record of normal activity for a non-human identity, including typical consumers, resources, and actions over time. Baselines help security teams detect when an identity is being used in an unusual way and provide the context needed to enforce least privilege safely in dynamic environments.
• SecurityGroupPolicy: An EKS control that attaches AWS security groups to individual pods through label selection and branch ENIs. It is useful for narrowing which AWS services an agent can reach, but it cannot inspect payloads or determine whether a permitted connection is malicious.
• Seccomp Profile: A seccomp profile is a Linux control that restricts which system calls a workload can execute. When generated from observed behaviour, it becomes a workload-specific execution guardrail that reduces kernel attack surface while preserving normal application function.

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.

👉 ARMO's full blog covers the EKS control-by-control configuration and runtime enforcement details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.