Notifications
Clear all
Topic starter
20/08/2026 5:29 pm
TL;DR: AI agents on AKS can be driven by prompt injection into tool use, shell execution, and metadata-service token theft in under a minute, according to ARMO. The core issue is that admission controls alone do not stop runtime abuse, so per-agent identity scope, IMDS blocking, and observed-behaviour sandboxing become the decisive controls.
NHIMG editorial — based on content published by ARMO: Sandboxing AI Agents on AKS: Network Policies, Workload Identity, and Least Privilege
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read ARMO's full AKS sandboxing guide for AI agent least-privilege controls →
AI agent sandboxing on AKS: are your controls keeping up?
Explore further
20/08/2026 6:17 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Sandboxing AI agents on AKS: least privilege and workload identity
