Sandboxing AI agents on AKS: least privilege and workload identity

At a glance

What this is: This is an AKS-specific analysis of AI agent sandboxing that shows how prompt injection can drive runtime credential theft, and why Workload Identity, IMDS blocking, and behavioural baselining matter.

Why it matters: It matters because AI agent pods inherit Kubernetes and Azure identity risk at runtime, so IAM, PAM, and NHI teams need controls that contain token abuse after the agent starts executing.

By the numbers:

• AI agent credential theft can unfold in 47 seconds on AKS when prompt injection reaches the metadata endpoint.
• 57% of organisations lack a complete inventory of their machine identities.
• Only 38% have automated certificate lifecycle management in place.

👉 Read ARMO's full AKS sandboxing guide for AI agent least-privilege controls

Context

AI agent sandboxing on AKS is really a control problem about runtime identity scope. The article shows that once a pod can call tools, reach internal APIs, and query the metadata endpoint, the difference between a normal task and a compromised one becomes invisible to static policy alone.

For identity teams, the key gap is not Kubernetes isolation by itself but how workload identity, service accounts, and network policy are composed. Traditional cluster hardening can reduce exposure, but it does not automatically prevent an agent from using a legitimate identity in an illegitimate way.

The starting posture described here is typical for fast-moving teams adopting AI agents on Kubernetes: enough access to function, not enough behavioural control to contain abuse. That makes the article relevant well beyond AKS because the same pattern appears anywhere runtime identity and tool use intersect.

Key questions

Q: How should security teams sandbox AI agents running on AKS?

A: Start with per-agent identity scoping, then block the metadata endpoint, and finally add behavioural runtime controls. The goal is to stop a prompt-injected agent from turning a legitimate tool path into cloud access. Admission control helps, but runtime containment is what limits the damage once the pod is live.

Q: Why do AI agents on Kubernetes create a different identity risk than normal workloads?

A: Because they can combine tool use, internal connectivity, and credential access in response to a malicious prompt. That makes their behaviour runtime-dependent, not just configuration-dependent. The same service account can be safe in one session and abusive in the next if the agent is allowed to act on untrusted instructions.

Q: What breaks when agent pods can reach the metadata endpoint?

A: A compromised process inside the pod can request cloud tokens without leaving the container or triggering a classic breakout alert. Once that token exists, the attacker can use the agent’s own identity permissions against Key Vault, storage, and other Azure services. The break is in the boundary between pod runtime and cloud identity trust.

Q: What should teams verify before relying on AKS sandboxing controls?

A: Check whether your network policy engine blocks IMDS traffic reliably, whether every agent identity has only the permissions it needs, and whether your runtime detection can tell a bootstrap metadata call from suspicious child-process activity. If those three checks fail, the sandbox is porous even if the cluster looks hardened.

Technical breakdown

How prompt injection turns an AI agent into an internal tool caller

Prompt injection does not need code execution to matter. It changes the agent’s behaviour by steering the model into calling tools, retrieving internal data, or issuing commands that appear legitimate at the orchestration layer. In systems like ReAct or function calling, the dangerous part is that a malicious prompt can produce a tool invocation that looks structurally identical to a valid one. That means the security question is not whether the tool exists, but whether the agent is allowed to combine tool use, internal connectivity, and privileged identity in the same runtime path.

Practical implication: baseline the agent’s real tool-use patterns before you try to enforce policy.

Why Workload Identity Federation changes the blast radius

Azure AD Workload Identity Federation replaces pod-mounted secrets and broad managed identity usage with an OIDC-based token exchange bound to a specific Kubernetes service account. That matters because the identity is no longer a shared cluster-wide convenience object. Each agent can carry its own narrowly scoped Azure RBAC permissions, which makes a stolen token far less useful. The article’s core point is that identity scope, not token existence, determines whether credential theft becomes a local event or a cloud-wide incident.

Practical implication: bind each agent deployment to a dedicated service account and the narrowest Azure RBAC scope possible.

How IMDS blocking and seccomp close different parts of the chain

IMDS blocking stops the agent pod from reaching the Azure metadata endpoint, which is where a compromised process can request a managed identity token. Seccomp addresses a different layer by limiting what system calls the container can make after a shell or tool runner is spawned. Together they illustrate a layered sandbox: network controls prevent token retrieval, while runtime controls reduce what a process can do if it is already running inside the pod. Neither layer replaces the other, because one governs reachability and the other governs execution behaviour.

Practical implication: pair egress controls with observed-behaviour seccomp profiles instead of relying on one control family.

Threat narrative

Attacker objective: The attacker wants to turn a single AI agent prompt into cloud-level identity abuse and lateral access across Azure services.

1. Entry begins with prompt injection, where a crafted prompt or poisoned document pushes the AI agent to invoke internal tools as if the task were legitimate.
2. Escalation occurs when the agent spawns a shell and reaches the Azure metadata endpoint, allowing token theft through a valid identity path rather than a breakout exploit.
3. Impact follows when the stolen token is used against Azure resources, expanding from a single pod to Key Vault, storage, and resource-group level access if RBAC is too broad.

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

Observed-behaviour sandboxing is the right abstraction for AI agents on Kubernetes. The article shows that static admission rules can stop bad pod configurations, but they cannot distinguish a legitimate tool call from a prompt-injection-driven one at runtime. That is why the security model has to move from configuration compliance to behavioural containment. Practitioners should treat agent sandboxing as a runtime identity problem, not a deployment hygiene problem.

Per-agent identity scope is the control that determines whether a stolen token matters. A token with resource-group Contributor access turns a single pod compromise into broad cloud exposure, while a token scoped to one vault or container keeps the incident local. This is the same non-human identity lesson that shows up across service accounts, API keys, and workload identity: blast radius is set by scope, not by the mere presence of credentials. Teams should re-check every agent identity assignment at the resource boundary.

Identity does not stay stable long enough to rely on one-time trust decisions when agent tooling is involved. That assumption was designed for workloads that execute within a predictable request path. It fails when an AI agent can shift from prompt to tool call to shell to metadata request in seconds, because the trust decision is no longer tied to a single action. The implication is that governance models built around static authorisation snapshots need to be rethought for runtime decision chains.

Runtime containment and identity governance now have to be treated as one programme. NetworkPolicy, IMDS blocking, seccomp, and Workload Identity are not separate stories here; they are the control stack that keeps agent behaviour bounded after deployment. Where teams treat these as independent projects, the attack path remains open between the Kubernetes layer and the Azure control plane. Practitioners should align cluster security, cloud IAM, and NHI governance around the same threat model.

AI agent governance increasingly looks like a workload identity discipline with autonomous failure modes. The article’s value is that it ties agent tool use to a familiar identity pattern, but the runtime behaviour is more dynamic than traditional machine identities. That means NHI programmes have to cover both access provisioning and behavioural enforcement. Teams should expect the next governance gap to appear where identity scope meets agent autonomy, not where either control exists in isolation.

From our research:

• 57% of organisations lack a complete inventory of their machine identities, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing how slow remediation extends the blast radius of compromised identity material.
• Top 10 NHI Issues helps teams map visibility gaps to the controls that fail first when workload identity sprawl grows.

What this signals

Identity scope will matter more than container hardening as AI agents move from pilots to production. A cluster can look well controlled and still be one prompt away from token theft if agent identities are broad, shared, or hard to inventory. The practical shift is to treat agent workload identity as part of the security baseline, not as an implementation detail tucked inside the platform team.

Behavioural detection is becoming the missing bridge between NHI governance and runtime security. Static policy can stop obvious misconfigurations, but it cannot tell bootstrap metadata use from malicious process lineage. That gap is where agent sandboxing will either mature into enforceable governance or remain a set of disconnected best practices.

Runtime identity control will increasingly sit alongside Zero Trust and workload identity standards. The operational question is not whether the pod is authenticated, but whether the process path inside the pod is still trustworthy after prompt-driven tool use begins. Teams that can tie behavioural telemetry to identity scope will have the clearest path to enforceable agent controls.

For practitioners

• Assign every agent a dedicated workload identity Create one user-assigned identity per agent deployment and scope it to the narrowest Azure resource possible, such as a single Key Vault or storage container. Do not share identities across agents for convenience, because shared scope destroys blast-radius clarity.
• Block metadata endpoint access from agent pods Use AKS IMDS restriction, a NetworkPolicy egress block, or a default-deny egress model to prevent agent pods from reaching 169.254.169.254. Validate that your chosen network policy engine actually blocks metadata-service traffic in your cluster mode.
• Build behavioural baselines before enforcement Instrument agent node pools, learn normal tool-call and process-spawn patterns, and then derive seccomp and NetworkPolicy rules from observed behaviour. That approach reduces false positives and gives you a defensible sandbox policy instead of a guessed one.
• Review Azure RBAC assignments for agent identities Look for Contributor, subscription-wide, or resource-group-wide assignments attached to agent service accounts and replace them with role scopes tied to the exact workload target. Reassess the blast radius of every managed identity after deployment changes.

Key takeaways

• AI agents on AKS create a runtime identity problem, not just a Kubernetes configuration problem.
• The 47-second attack chain shows that prompt injection, metadata access, and broad RBAC can turn one pod into a cloud incident.
• Per-agent workload identity, IMDS blocking, and observed-behaviour sandboxing are the controls that actually change blast radius.

Key terms

• Workload Identity Federation: A mechanism allowing workloads in one environment to authenticate to another using short-lived tokens rather than stored credentials, based on mutual trust between identity providers.
• Metadata Endpoint Exposure: Metadata endpoint exposure is the risk that a workload can reach a cloud provider’s internal credential service and retrieve temporary identity material. If an attacker can induce a privileged pod to call that endpoint, cloud access can be obtained without stealing a traditional secret.
• Observed-behaviour sandboxing: A control approach that derives enforcement rules from how a workload actually behaves, rather than from assumptions about how it should behave. For AI agents, this matters because tool use and process lineage can change at runtime in response to malicious prompts.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

What's in the full article

ARMO's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step AKS configuration guidance for OIDC issuer enablement and Workload Identity Federation.
• Three IMDS-blocking approaches compared for production trade-offs, including AKS restriction, NetworkPolicy, and default-deny egress.
• Practical seccomp and NetworkPolicy implementation details derived from observed agent behaviour.
• Runtime detection cues for separating normal bootstrap metadata access from suspicious child-process activity.

👉 ARMO's full post covers the 47-second attack chain, control-by-control configuration, and AKS rollout roadmap.

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