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

At a glance

What this is: ARMO argues that securing AI agents on EKS requires runtime behavioural visibility, because AWS-native identity, logging and detection tools stop at the workload boundary.

Why it matters: IAM and Kubernetes controls can define permissions ceilings, but IAM, IGA and cloud security teams need runtime evidence to govern what AI agents actually do inside the container.

Context

AI agent security on EKS is a runtime governance problem, not just an IAM configuration problem. AWS primitives such as IRSA, CloudTrail, GuardDuty EKS Runtime Monitoring and VPC Flow Logs give useful control-plane and infrastructure signals, but they do not explain the application-layer choices made by an AI agent during execution.

That matters because an agent can stay within its authorised AWS role and still behave in ways that were never intended at provisioning time. The article’s central claim is that EKS security for AI agents needs observation, posture, detection and enforcement tied to what the workload actually does, not to static assumptions about Kubernetes or cloud identity alone.

For identity and access teams, the operational question is no longer whether the workload has a role. It is whether that role, plus the runtime telemetry around it, is enough to prove the agent is acting within a governable boundary.

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. On EKS, that means prompt-driven tool use, abnormal egress and unsafe data access can stay invisible unless runtime behaviour is correlated with identity and network telemetry.

Q: Why do control-plane logs fail to explain AI agent risk on EKS?

A: Because logs record the request, not the consequence. CloudTrail can show that an agent called Bedrock or S3, but it cannot show which tool path the agent followed, what data it touched next, or whether the sequence was normal for that workload.

Q: How can security teams tell whether agent permissions are too broad?

A: The clearest signal is whether the agent can still complete its job after permissions are reduced in a sandbox. If the task keeps working after you remove broad access, the original entitlement was inflated. A second signal is the presence of unused permissions that persist across reviews and deployments.

Q: Should organisations rely on GuardDuty for AI agent runtime detection on EKS?

A: They should use it as one layer, not the whole answer. GuardDuty is useful for known threat signatures, but AI agent governance also needs behavioural baselines that can spot abnormal tool invocation, unusual egress and prompt-driven shifts that are not inherently malicious in isolation.

Technical breakdown

Why control-plane logs are not enough for AI agent security on EKS

CloudTrail, IRSA and EKS Pod Identity tell you which role called which AWS service, but they do not explain the agent’s decision path. That is a fundamental gap when the workload can choose tools at runtime. GuardDuty EKS Runtime Monitoring adds container-level threat signatures, but it still looks for known bad patterns such as reverse shells or credential exfiltration rather than establishing what is normal for a specific AI agent. Runtime behavioural intelligence fills that gap by correlating kernel events, API calls and network activity into a workload-specific picture of intent and action.

Practical implication: treat cloud audit logs as necessary evidence, not as sufficient proof of safe agent behaviour.

How runtime baselines change AI agent governance on EKS

A behavioural baseline is not a generic policy template. It is a record of what a specific agent actually calls, reaches and loads during normal operation, including AWS APIs, data sources and egress destinations. On EKS, that baseline can be built from CloudTrail, VPC Flow Logs and sensor data from the container runtime. Once you know the observed pattern, posture gaps become measurable, such as a role that allows dozens of APIs but a workload that only uses a small subset. That difference is what makes least privilege enforceable without guessing.

Practical implication: derive permissions from observed runtime use, then tighten the role to the minimum behaviour actually required.

Where runtime detection differs from known-threat detection

GuardDuty-style detection and behavioural detection answer different questions. Known-threat tools identify suspicious binaries, malicious process execution or recognised exfiltration patterns. Behavioural tools ask whether a tool call, network destination or data access volume is abnormal for this agent even if it looks valid in isolation. That distinction matters for AI agents because prompt-driven actions can look legitimate at the API layer while still representing unsafe behaviour at the workload layer. The governance failure is not only missed malware, but the inability to distinguish normal tool invocation from policy drift inside a live session.

Practical implication: layer signature-based runtime security with per-agent anomaly baselining so legitimate-looking misuse is still visible.

Threat narrative

Attacker objective: The objective is to use legitimate agent permissions and runtime decisions to move data or trigger actions that the control plane records as authorised.

1. Entry begins with a prompt-driven agent running under a legitimate AWS role and using authorised AWS services from inside an EKS workload.
2. Credential and permission use stays inside the declared boundary, but runtime behaviour expands as the agent selects tools and data paths that were not visible in static IAM review.
3. Escalation occurs when the agent combines API calls, network access and data movement into a workflow that appears normal to control-plane logs but abnormal at runtime.
4. Impact is data exfiltration, unintended model or service invocation, or unsafe autonomous action that existing IAM and Kubernetes controls did not distinguish in time.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime behaviour, not provisioning-time identity, is the real control boundary for AI agents on EKS: the article shows that IAM and Kubernetes controls stop at the workload boundary, while the agent’s meaningful security posture emerges only when its runtime choices are observed. That breaks the common assumption that a correctly assigned role is enough to govern an AI workload. The implication is that AI agent governance must be built around behaviour evidence, not just entitlement evidence.

Control-plane telemetry is necessary but insufficient for agent governance: CloudTrail, IRSA and VPC Flow Logs each answer a different question, yet none of them can explain why an agent made a given tool call or whether that call was normal for the workload. This is a visibility problem, not a logging problem. Practitioners should treat the absence of runtime correlation as a governance gap, because auditability without behavioural context leaves autonomy effectively unreviewed.

Observed behaviour should define the enforcement baseline, not the manifest: the article’s observe, posture, detect and enforce sequence is strongest where it converts live runtime data into least-privilege controls. That is a material shift for identity governance because the permissions ceiling and the actual operating footprint are often far apart. Teams should treat the gap between allowed APIs and used APIs as a first-class policy signal.

Per-agent behavioural profiles are becoming the new unit of identity control: the article effectively defines a runtime AI-BOM and an Application Profile DNA for each workload, which is more granular than traditional workload inventory. This matters because two agents in the same cluster can have very different risk shapes even when they share cloud primitives. Practitioners need to govern the agent, not just the cluster.

Runtime observability is now an identity security prerequisite for autonomous tool use: once an agent can select tools and data paths during execution, the trust model shifts from static authorisation to continuous behavioural verification. That collapses the usefulness of one-time access review as a primary control. The practical conclusion is that agent identity programmes must make runtime evidence the basis for enforceable scope, not an afterthought.

From our research library:

• Gartner predicts that more than 50% of successful cyberattacks against AI agents through 2029 will exploit access control weaknesses.

What this signals

Runtime observability is now part of identity governance for autonomous tool use: AI agents can remain inside their assigned cloud permissions while still acting outside the intended security posture, so the useful control point shifts from provisioning to execution. Teams that still treat workload identity as a static entitlement problem will miss the runtime decisions that create risk.

The practical consequence for EKS programmes is that baseline-building becomes a governance function, not just a detection function. Once an agent’s normal tool use, API mix and egress pattern are known, access scope can be adjusted against evidence rather than assumption.

For practitioners

• Build runtime observability before tightening policy Instrument AI agent workloads on EKS with telemetry that correlates API calls, network flows and container events so behaviour can be profiled before enforcement starts.
• Derive least privilege from observed agent behaviour Use the agent’s real Bedrock, SageMaker, S3 and DynamoDB usage to replace broad role permissions with a narrower runtime-derived IAM policy.
• Separate known-threat detection from behavioural anomaly detection Keep GuardDuty-style signature detection in place, but add a per-agent baseline that can flag legitimate-looking tool use when it deviates from normal.
• Move high-risk agents to node groups that support kernel visibility If runtime security matters, avoid workloads that cannot expose DaemonSet-based monitoring and accept that Fargate limits kernel-level observation.

Key takeaways

• AI agent security on EKS depends on runtime behavioural evidence because identity and audit controls alone do not explain what the workload does after authorisation.
• The article’s central pattern is a gap between permitted access and observed use, which makes least privilege a runtime outcome rather than a provisioning-time assumption.
• Practitioners should pair cloud telemetry with behavioural baselines so enforcement reflects the agent’s actual tool use, not just its declared role.

Key terms

• Runtime Behavioural Intelligence: Telemetry and analytics that explain what a workload actually does during execution rather than what it was configured to do. For AI agents, this means correlating identity, process, network and API activity so security teams can govern behaviour instead of relying only on static permissions.
• 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.
• Control-Plane Telemetry: Logs and events generated by the cloud or orchestration layer that show requests, roles and infrastructure actions. It is useful for audit and investigation, but it does not explain the agent’s post-authorisation behaviour, which is why it must be combined with runtime data.
• Runtime AI-BOM: Runtime AI-BOM is a live inventory of the AI components actually active in a system at a given moment. It records models, prompts, tools, agents, connectors, policies, and dependencies in execution, so security teams can see what is really running, trace data flows, and detect unauthorized or risky AI behavior.

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 building or maturing an IAM programme, it is worth exploring.