Cloud-native security for AI workloads needs runtime controls

At a glance

What this is: This article says AI workloads in Kubernetes have outgrown posture-only cloud-native security because agents behave non-deterministically at runtime.

Why it matters: IAM, PAM, and cloud security teams need runtime visibility into AI agent behaviour, not just entitlements, because granted access does not reveal how an autonomous workload will use it.

Context

AI workloads change the security problem because they do not behave like fixed application code. In Kubernetes, that means existing posture and runtime tools may still see containers, permissions, and network events, but they miss the decision-making layer that defines what an agent will actually do.

The governance gap is between declared access and observed behaviour. For identity and cloud teams, that creates a control boundary issue: permissions, tokens, and tool connections may be technically valid while the workload using them behaves outside the assumptions those controls were built for.

Key questions

Q: Where do posture tools fail for AI workloads in Kubernetes?

A: They fail when the question moves from access to behaviour. Posture tools can identify exposed permissions, vulnerable frameworks, and policy drift, but they cannot tell whether an AI agent is using those permissions in a way that is safe, expected, or aligned to its task. The missing control is runtime context that interprets agentic actions, not just infrastructure state.

Q: Why do AI agents create risk even when they stay within approved permissions?

A: AI agents can be authorised correctly and still produce harmful outcomes because permission is not the same as intent or behavioural appropriateness. If an attacker manipulates the session mid-flight, the agent may keep acting inside scope while exfiltrating data, taking destructive steps, or chaining actions that no human would have approved.

Q: What signals show that an AI workload identity is operating beyond its intended scope?

A: Look for unexpected job creation, unusual container image sources, metadata reads from training environments, and access to storage or analytics services that the workload does not normally use. A workload identity that starts touching adjacent resources is usually the earliest sign that scope has drifted.

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.

Technical breakdown

Why deterministic workload assumptions fail for AI agents

Traditional cloud-native security was designed around deterministic workloads, where the container image and the running process are expected to match the developer’s intent. AI agents break that model because they can generate code, choose tools, and vary their actions based on prompts and context. That means the security question is no longer only whether the workload is trusted to run, but whether its runtime decisions stay inside acceptable boundaries. Generic container policies can still identify a vulnerable image or a broad permission set, but they cannot interpret agentic intent or distinguish planned autonomy from misuse.

Practical implication: Treat AI workloads as behavior-governed systems, not static containers, when defining control boundaries.

Why posture tools stop at access and miss agent behaviour

CNAPP and CSPM remain useful for finding misconfigurations, overbroad permissions, and framework vulnerabilities. Their limit is that they model what an AI workload could reach, not what it actually does after deployment. For an agent with production credentials, that difference matters because a valid permission set may still be exercised in unsafe or unexpected ways. Runtime tools that only look for anomalous processes or unusual connections also struggle, because agentic systems naturally invoke tools and external services as part of normal operation. Without prompt and tool context, the detection layer becomes noisy or blind.

Practical implication: Add runtime controls that understand prompts, tool calls, and agent context instead of relying on posture findings alone.

Why runtime enforcement must account for autonomy drift

AI workloads introduce autonomy drift, which is the gap between the permissions the system was given and the actions it starts taking once deployed. A workload may begin with one intended use case, then expand through connected tools, retained credentials, or changing prompts. In cloud-native environments, that drift can unfold quickly across namespaces, APIs, and data stores. Security architecture therefore needs observation, behavioural baselining, and enforcement that can adapt to non-deterministic execution. Static allowlists and rigid baselines are not enough when legitimate behaviour itself changes with each task.

Practical implication: Baseline the agent’s normal tool use and constrain escalation paths before autonomy drift becomes operationally normal.

Threat narrative

Attacker objective: The objective is to exploit an AI workload’s legitimate access and autonomous behaviour to reach data, tools, or actions beyond the intended operational scope.

1. Entry occurs when an AI agent is deployed into a Kubernetes environment with production credentials and connected tools.
2. Credential and access abuse follows as the agent exercises permissions against internal databases, APIs, or external services that were never intended to be broadly available.
3. Impact emerges when autonomous behaviour expands the workload’s effective attack surface, creating data exposure, unintended code execution, or unauthorised outbound activity.

Breaches seen in the wild

• Carbonato botnet 2026: A botnet puts a Hermes AI agent on exposed Docker hosts to steal AI API keys, SSH keys and tokens, powering the operators' own LLM gateway.
• ShadowRay 2024: Attackers took over internet-exposed Ray AI clusters via the disputed CVE-2023-48022, exposing cloud keys, AI API tokens and GPU compute.

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

Cloud-native security has entered an autonomy era, not just a runtime era. The industry’s earlier model assumed containers execute known code paths, then assumed runtime anomalies indicate compromise. AI agents invalidate both assumptions because making novel decisions is part of expected behaviour. That means the control problem shifts from spotting deviations to governing acceptable autonomy, especially in Kubernetes environments where agents can spread across tools and data paths quickly.

Posture-only coverage is now a governance gap, not a visibility gap. CNAPP and CSPM still matter for misconfigurations, vulnerable frameworks, and permission review, but they do not answer the operational question that matters most: what did the agent actually do with those entitlements. This is where AI workloads intersect with identity governance, because the workload’s identity, credentials, and delegated tool access are part of the security decision surface. Practitioners should treat that as a runtime governance issue, not a scanning problem.

Autonomy drift is the named concept security teams need to track. An AI agent can begin within approved scope and then expand behaviour through tool chains, prompts, and retained credentials until the original approval no longer reflects reality. That is a governance failure because the control model still assumes fixed intent after deployment. The practitioner response is to define controls around observed behaviour and allowed delegation paths, not around the original manifest alone.

Runtime context is becoming the deciding control plane for AI workloads. The article’s central lesson is that cloud-native security for AI cannot rely on generic alerting for process or network anomalies. Security teams need context that links prompts, tools, identities, and data access into one view so that legitimate agent activity can be distinguished from abuse. The broader field implication is clear: AI workload security is converging with identity and privilege governance at runtime.

The market is moving from detection of workloads to governance of workload agency. That is a material shift for cloud security architecture because the thing being governed is no longer only a container instance or a service account. It is a system that can choose actions on its own. Teams that do not update their control model will keep collecting posture findings while missing the behavioural risk that determines real exposure.

What this signals

Autonomy drift is now a practical control problem. Once an AI agent can choose tools and adapt its own execution path, the original security approval becomes an incomplete record of real risk. Security teams should expect runtime governance to move closer to identity and privilege controls, because behaviour is now part of the access decision.

CNAPP remains necessary but no longer sufficient for AI workloads. The article’s most important signal for practitioners is that posture management still catches misconfiguration, yet the decisive exposure sits in observed behaviour. That means teams need runtime controls that understand prompts, tools, and delegated access, especially in Kubernetes estates where shadow AI can appear quickly.

For practitioners

• Define runtime guardrails for AI agents Set explicit boundaries for tool use, outbound calls, data access, and code execution so the agent’s allowed behaviour is written down before deployment.
• Correlate prompts, tools, and identities Link agent prompts, tool invocations, workload identity, and accessed data so security teams can reconstruct why a behaviour occurred instead of only seeing the event.
• Separate posture findings from behavioural risk Keep CNAPP and CSPM for configuration issues, but add runtime detection that understands agentic context and can distinguish expected autonomy from misuse.
• Review production credentials on AI workloads Check every agent, sidecar, and integration for credentials that let it reach internal systems, external APIs, or administrative functions beyond its core task.

Key takeaways

• AI workloads break the deterministic assumptions that made container-era cloud-native security effective.
• The main gap is not configuration visibility but runtime governance of what an agent actually does with valid access.
• Practitioners need runtime context, behavioural baselines, and workload identity controls that can distinguish legitimate autonomy from misuse.

Key terms

• Autonomy Drift: The gradual movement of an AI system outside the decision boundary it was originally given. It can happen through recursive prompting, memory, or overly broad tooling, and it becomes a security issue when the system keeps acting beyond the task that justified its access.
• Runtime Behavioural Gap: The runtime behavioural gap is the difference between what a workload is allowed to do and what it actually does once it starts operating. In AI systems, that gap expands because prompts, tools, and model outputs can change execution in ways static posture tools cannot predict.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Agentic AI Workload: An agentic AI workload is an AI system that can reason, choose tools, and execute multi-step actions against enterprise systems. Unlike a simple model call, it may read data, invoke APIs, and trigger workflows. That autonomy creates higher governance requirements for permissions, logging, and containment.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners align identity control with the broader security programme that AI workloads now depend on.