How should security teams sandbox AI agents running on AKS?

Why This Matters for Security Teams

AI agents on AKS are not just another workload class. They can chain tools, follow unsafe prompts, and turn a permitted call into a cloud control-plane action if the pod has broad identity reach. That is why sandboxing must start with identity scope, then runtime containment, not the other way around. Current guidance on agentic systems from the OWASP Agentic AI Top 10 and NHIMG research on OWASP NHI Top 10 both point to the same operational reality: prompt injection becomes a cloud breach when identity and network boundaries are too permissive.

This is especially important on AKS because Kubernetes isolation alone does not stop an agent from using mounted secrets, instance metadata, or over-scoped workload credentials. The issue is not whether the pod is “containerised”; it is whether the agent can reach anything sensitive once it is executing. NHI governance data from The State of Non-Human Identity Security shows 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks, which reinforces how quickly static access becomes a liability.

In practice, many security teams encounter agent abuse only after a prompt-injected workflow has already touched cloud permissions, rather than through intentional sandbox validation.

How It Works in Practice

Effective sandboxing for AI agents on AKS should treat each agent as a distinct workload identity with tightly bounded permissions, short-lived credentials, and runtime guardrails. Start with a dedicated identity per agent, then bind that identity to the smallest possible set of Kubernetes and cloud permissions. For agents that call Azure or internal services, use workload identity patterns instead of static secrets so the pod proves what it is at runtime, rather than carrying a reusable credential.

Then block the metadata endpoint and any other implicit credential source. If the agent cannot reach instance metadata, it cannot silently escalate through node or managed identity paths. Pair that with admission controls that reject pods lacking security context constraints, but do not stop there. The stronger protection comes from behavioural containment: deny shell execution where not needed, restrict outbound egress to approved domains, limit file-system write paths, and watch for unusual tool chaining or lateral requests.

• Use per-agent identities and separate namespaces for distinct trust levels.
• Issue ephemeral credentials with short TTLs and automatic revocation on task completion.
• Apply policy-as-code at runtime, with request-time decisions based on context and intent.
• Disable metadata access and other implicit credential paths inside the pod network.
• Log tool use, denied actions, and token issuance events for post-incident review.

For implementation detail, the CSA MAESTRO agentic AI threat modeling framework and NIST AI Risk Management Framework both support runtime-aware controls, while NHIMG’s Analysis of Claude Code Security underscores how quickly tool-using AI can become a security boundary problem when it has broad execution authority. These controls tend to break down when agents need access to legacy shared secrets or broad cluster-admin patterns because the sandbox then inherits the same blast radius it was meant to contain.

Common Variations and Edge Cases

Tighter sandboxing often increases deployment and tuning overhead, requiring organisations to balance agent agility against operational friction. That tradeoff becomes real when multiple agents share the same AKS cluster, or when a single agent must access several external tools with different trust levels. Best practice is evolving, but current guidance suggests isolating high-risk agents into separate namespaces or even separate node pools when blast radius matters more than scheduling efficiency.

There is no universal standard for agent sandboxing yet, so teams should distinguish between low-risk read-only agents and high-risk action agents. A read-only summariser may only need egress filtering and identity scoping, while a code-executing or infrastructure-changing agent needs stricter syscall, filesystem, and network controls. Where regulated data is involved, combine sandboxing with explicit approval gates for destructive actions and separate credentials for human override.

One common edge case is service mesh visibility: encrypted east-west traffic can hide prompt-injection fallout unless telemetry is collected at the application and identity layer. Another is secret sprawl in CI/CD, where the agent is safe in production but inherits powerful tokens during build or deployment workflows. NHIMG research on CoPhish OAuth Token Theft via Copilot Studio and Gemini AI Breach Google Calendar Prompt Injection shows that the weakest point is often not the model itself, but the connected tool path.

Related resources from NHI Mgmt Group

• How should security teams manage permissions for AI agents?
• How should security teams govern AI agents that use OAuth access?
• How should security teams limit the risk from AI agents that have access to production systems?
• How should security teams govern AI agents that can access enterprise systems?