AI agent security on EKS needs runtime behavior, not just IAM

At a glance

What this is: This is an implementation guide for AI agent security on AWS EKS, with the key finding that AWS primitives alone do not understand agent behavior at runtime.

Why it matters: It matters because IAM, Kubernetes, and cloud security teams need to govern AI agents as runtime actors, not just as roles or pods, if they want least privilege to reflect actual tool use.

By the numbers:

• NHIs outnumber human identities by 25x to 50x in modern enterprises.

👉 Read ARMO's implementation guide for AI agent security on AWS EKS

Context

AI agent security on EKS starts with a simple constraint: control-plane telemetry is not enough to explain runtime behaviour. IRSA, EKS Pod Identity, CloudTrail, GuardDuty, and VPC Flow Logs each cover part of the picture, but none of them can tell you whether an agent’s tool use is normal for that workload or abnormal for that session.

That gap matters for NHI governance because AI agents behave like non-human identities with dynamic runtime decisions, but their access still has to be governed through identity, policy, and observation. When the platform can only see permissions and not behaviour, least privilege becomes a guess instead of an evidence-based control.

The article is a practical example of a broader shift in EKS and cloud security: teams are moving from static entitlement management to behavioural control loops. For AI agent workloads, the question is no longer just who or what is allowed to call AWS services, but what the workload actually does once those calls begin.

Key questions

Q: How should security teams govern AI agent access on EKS?

A: Start with runtime observation, not final privilege design. Security teams should correlate CloudTrail, pod-level telemetry, and network activity to see what each agent actually does, then reduce identity permissions, seccomp allowances, and egress scope to match that observed behaviour. Without that loop, least privilege is based on assumptions rather than evidence.

Q: Why do AI agents create a governance gap in Kubernetes environments?

A: Because Kubernetes and cloud controls usually see the workload boundary, not the agent’s runtime decision-making. An AI agent can stay inside approved identity and network rules while still behaving in risky ways through tool choice, request volume, or data access patterns. That makes the gap behavioural, not just infrastructural.

Q: What breaks when IAM only reviews permissions and not data reachability?

A: Teams can approve a role or service account while still missing the sensitive data it can reach through pipelines, inheritance, or downstream systems. That creates false confidence, because the entitlement looks legitimate even when the actual exposure is broader than the business use case. Reachability, not permission alone, is the governance boundary that matters.

Q: How do you know if AI agent monitoring is actually working?

A: It is working when you can explain why a sequence of actions was allowed, blocked, or escalated, using evidence from the full chain rather than a single request. If monitoring only shows isolated inputs, it is not capturing agent intent, which is where misuse usually appears.

Technical breakdown

Why AWS-native EKS controls stop at the workload boundary

AWS-native identity and monitoring controls are designed around roles, API calls, network flows, and known threat signatures. IRSA and EKS Pod Identity scope credentials to pods, CloudTrail records service calls, VPC Flow Logs record egress, and GuardDuty EKS Runtime Monitoring detects known bad activity such as reverse shells or credential exfiltration. The limitation is structural: these controls observe infrastructure events, not application intent. An AI agent can make a legitimate bedrock call, then misuse the response in ways the control plane cannot interpret.

Practical implication: treat AWS-native telemetry as the baseline, not the full control model, for AI agent workloads.

How runtime behavioural baselines make AI agent security operational

Runtime behavioural intelligence fills the gap between permitted access and actual use. By correlating kernel events, process trees, file access, network connections, and CloudTrail API activity, teams can profile what a given agent workload normally does. That profile becomes the reference point for posture and detection, allowing security teams to distinguish routine tool invocation from suspicious drift. In EKS, this is especially important because the same workload may call Bedrock, S3, DynamoDB, and internal data sources in a pattern that looks normal at the API layer but still represents unacceptable risk at the behavioural layer.

Practical implication: build behavioural baselines per AI agent workload before tightening permissions or enforcing deny rules.

Observe, posture, detect, and enforce on EKS

The article’s phased model maps well to identity governance. Observe captures what the agent actually does. Posture measures the gap between declared permissions and observed behaviour. Detect looks for deviations from the baseline. Enforce then narrows IAM, seccomp, and network policy to match reality. This sequence matters because AI agent access is often broader during initial rollout than it should remain in production. On EKS, the right control is not a single guardrail but a loop that converts evidence into progressively tighter identity boundaries.

Practical implication: adopt phased enforcement so production permissions are derived from evidence rather than from application design assumptions.

Threat narrative

Attacker objective: The attacker objective is to abuse a trusted AI agent workload so permitted cloud and data access can be turned into unauthorized collection or exfiltration.

1. Entry occurs through a legitimate AI agent workload running on EKS with access to AWS services through IRSA or Pod Identity. Escalation happens when the agent uses allowed tools in an unexpected sequence or volume that the control plane still treats as normal. Impact follows when those legitimate calls are used to access or exfiltrate data, because the surrounding controls cannot interpret agent intent at runtime.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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

NHI Mgmt Group analysis

Runtime AI agent behaviour is the governance boundary that EKS controls do not see. IRSA, Pod Identity, CloudTrail, and GuardDuty each govern a slice of the problem, but they do not establish what normal tool use looks like for a specific agent workload. That leaves IAM teams relying on permission sets that may be technically valid and operationally wrong. The practitioner conclusion is that identity governance for AI agents starts with observed behaviour, not with the role definition.

Least privilege cannot be safely inferred from manifest-level permissions for AI agents. The article shows a 47-to-3 style gap between what an agent can do and what it actually does, which is exactly why static entitlement reviews miss the real risk. For AI agent governance, the decisive question is not whether access exists, but whether access is being exercised in ways that match the workload’s true function. Practitioners should treat behavioural drift as an identity issue, not only a detection issue.

Observe, posture, detect, and enforce is a governance loop, not just a technical workflow. That matters because EKS security teams often split runtime monitoring, IAM, and container policy into separate ownership silos. The article’s model connects those layers into one control chain, which is the right direction for NHI and agentic AI programmes. The practitioner implication is that policy enforcement should be the end of the evidence cycle, not the starting assumption.

Agentic workloads make control-plane confidence look higher than it really is. The current identity model assumes that permission, logging, and enforcement are enough if the actor is already authenticated. That assumption fails when the actor can choose tool sequences at runtime, because the security question moves from access approval to behavioural trust. The implication is that AI agent identity must be governed as a runtime discipline, not as a static authorisation exercise.

EKS AI agent security will converge on workload-specific identity policies, not generic Kubernetes rules. The article points toward a future where the same pod type may need different seccomp, network, and IAM constraints depending on observed behaviour. That is a meaningful shift for platform and IAM teams because governance becomes evidence-led and workload-specific. Practitioners should expect identity policy to fragment by function, not remain uniform across all agent workloads.

From our research:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to Ultimate Guide to NHIs.
• From our research: Only 20% have formal processes for offboarding and revoking API keys, which is why runtime governance cannot stop at provisioning, according to Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.
• From our research: See how the Ultimate Guide to NHIs , 2025 Outlook and Predictions frames AI agents as part of the next NHI governance wave.

What this signals

Runtime agent governance will become a standard requirement for EKS security programmes. The practical shift is away from static permission checks and toward evidence-led control loops that connect identity, runtime telemetry, and enforcement. Teams that already treat non-human identities as a governed population will adapt faster than those still separating IAM, platform security, and detection into isolated workflows.

Behavioural baselining is the named concept that matters here. It means defining normal tool use, access patterns, and egress behaviour for each agent workload, then using that baseline to drive policy. The more autonomous the workload becomes, the more the baseline needs to be maintained as a living control rather than a one-time profile.

With 92% of organisations exposing NHIs to third parties, per Ultimate Guide to NHIs, agent security has already become a supply-chain and runtime-governance problem at the same time. That combination means platform teams should prepare for more scrutiny of how AI agents authenticate, call tools, and hand off data across internal and external boundaries.

For practitioners

• Instrument runtime behaviour before tightening access Deploy runtime sensors and CloudTrail correlation first so you can see which tools, APIs, and destinations each agent actually uses before changing permissions.
• Build per-agent behavioural baselines Create a normal-use profile for every agent workload, including API frequency, network destinations, file access, and process activity, then review deviations as governance events.
• Move from broad roles to evidence-derived IAM policies Use observed API usage to reduce IRSA or Pod Identity permissions to the smallest stable set, then revalidate when the workload changes.
• Separate known-bad detection from behavioural anomaly detection Keep GuardDuty or similar signature-based tooling for hostile process activity, but add behavioural analytics for agent-specific misuse that signatures will not catch.
• Progressively enforce seccomp and network policy in audit mode first Roll out seccomp profiles and network restrictions in audit mode, compare blocked events against real workload behaviour, and only then move to enforcement.

Key takeaways

• AI agent security on EKS fails when teams stop at identity issuance and logging, because runtime behaviour is where the real risk appears.
• The article’s strongest operational signal is the gap between permitted access and observed use, which is why behavioural baselining has to precede enforcement.
• IAM, container policy, and network controls need to be tied together into one evidence loop if AI agents are going to be governed as non-human identities.

Key terms

• 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.
• Observe, Posture, Detect, Enforce: Observe, Posture, Detect, Enforce is a phased control model that starts with visibility, measures the gap between permission and use, identifies deviations, and only then applies restrictions. For AI agents, it turns runtime evidence into progressively tighter identity and workload controls.
• Runtime-Derived AI-BOM: An inventory of the models, tools, adapters, and components that actually loaded and ran in an AI workload. Unlike a declared bill of materials, it reflects live system state, which is essential when components appear only at runtime or are pulled dynamically from external sources.
• Security Groups for Pods: Security Groups for Pods is an AWS networking feature that applies VPC security groups directly to individual pods through the VPC CNI. In AI agent environments, it provides pod-level network isolation, but it still needs behavioural evidence to avoid locking down legitimate dynamic egress patterns.

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 implementation guidance for IRSA, Pod Identity, CloudTrail, GuardDuty, and runtime telemetry.
• Concrete examples of how ARMO maps AI agent runtime behaviour to seccomp, network policy, and IAM tightening.
• Performance and deployment notes for EKS managed node groups versus Fargate, including DaemonSet constraints.
• The full Observe, Posture, Detect, and Enforce workflow with AWS-specific examples and operational sequencing.

👉 ARMO's full post covers the EKS control mapping, runtime baselines, and enforcement workflow in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.