Sandboxing AI Agents on AKS: Network Policies, Workload Identity, and Least Privilege

Your AI agent runs on AKS with a managed identity that can read Azure Key Vault, and you assume prompt injection is a theoretical risk—until a malicious prompt drives that agent to steal credentials from the Azure metadata endpoint in under a minute. Most teams discover this gap when their SIEM shows a single request to 169.254.169.254, but they cannot trace it back to which agent tool or prompt triggered it, or how far the stolen token traveled across their Azure environment.

This article applies the progressive enforcement methodology from the AI Agent Sandboxing & Progressive Enforcement guide to Azure AKS specifically. Where that guide covers the cloud-agnostic methodology, this one focuses on what to deploy: Workload Identity Federation for per-agent isolation, NetworkPolicies that block the metadata endpoint, and AKS-native controls that close the gaps traditional Kubernetes hardening leaves open. For a full evaluation of where Defender for Cloud’s detection layers end and where runtime CADR fills the gap, see the Azure Defender evaluation.

You’ll leave this article with three concrete things: a realistic attack timeline showing how credential theft unfolds in 47 seconds on AKS, a control-by-control breakdown of what to configure at each stage, and a practical three-week roadmap for implementing observe-to-enforce on your AKS clusters.

Anatomy of a 47-second AI agent attack on AKS

To make sandboxing concrete, let’s walk through a realistic attack that unfolds in under a minute. We’ll assume an AI agent running on AKS, with tools that can call internal APIs and the shell, using a managed identity to talk to Azure services. Each stage ends with the specific control that stops it—covered in the implementation sections that follow.

T+0s – Initial access via a maliciously crafted prompt

The attack starts with a single prompt. An external user—or a poisoned document indexed by Azure Cognitive Search—sends text designed to make the AI agent call a powerful tool in a risky way. This is prompt injection: the prompt changes the agent’s behavior without changing any code. The OWASP Top 10 for LLM Applications lists it as the #1 risk for exactly this reason.

A simple example: the prompt tells the agent it’s a debugging assistant and instructs it to call its HTTP request tool against an internal admin API that lists all environment variables. From the agent’s perspective, this looks like a normal task. In many orchestration frameworks—ReAct, function calling—the model responds with a tool invocation that looks identical to a legitimate request. The problem isn’t that the tool exists. The problem is that the agent has enough autonomy and permission to call internal services with almost no guardrails.

The control that should help here: Runtime behavioral detection. Static policies can’t distinguish a legitimate tool call from a prompt-injection-driven tool call—both look identical at the network and process level. Behavioral baselines can flag when an agent’s tool invocation patterns shift from normal operation.

T+15s – The agent executes unintended code in the pod

About 15 seconds in, the attacker pushes the agent one step further. Instead of just calling an internal HTTP API, they steer the agent toward running local code—often through a tool wired up for operations tasks that allows shell commands for “debugging” or “maintenance.” The prompt chain leads the agent to spawn a shell process that issues a request to the Azure metadata endpoint.

Nothing has escaped the container. There’s no container breakout exploit here. All of this happens inside the pod, using the pod’s normal process tree: the agent application spawns a Python tool runner, which spawns a shell, which calls the metadata service. Every process is a legitimate child of the agent’s own execution context.

Network policies govern where traffic can go, not whether a given process “should” be running. Container runtime controls like seccomp or AppArmor help if you have strict profiles, but most clusters keep them permissive to avoid breaking apps.

The control that should help here: Seccomp profiles generated from observed behavior, restricting which system calls the agent container can make. And IMDS blocking (covered below) to ensure even if a shell spawns, the metadata endpoint is unreachable.

T+32s – The pod queries the Kubernetes API server

Next, the attacker wants to understand what else the pod can touch. Every pod in Kubernetes can be given a service account with permissions defined through RBAC. Inside the pod, the in-cluster configuration is usually available: the API server hostname, a service account token mounted at a known path, and a CA certificate. The shell spawned by the agent reads the token and makes an authenticated request to the Kubernetes API, asking for a list of all pods in the namespace.

If the service account has been granted a broad ClusterRole—common when teams assign admin-like permissions during development and never revisit them—this query can return pod specs including environment variables, mounted volumes, secrets across namespaces, and details about other high-value workloads. IBM’s 2025 breach report found 97% of AI-related breaches involved systems lacking proper access controls. AI agent service accounts are especially prone to over-permissioning because developers grant broad roles to avoid tool invocation errors and those bindings persist into production.

The control that should help here: Namespace-scoped RBAC with minimal permissions for agent service accounts, and a NetworkPolicy that blocks egress to the API server from agent pods.

T+47s – The agent accesses the Azure metadata endpoint

Within about 47 seconds of the first malicious prompt, the attacker goes after the Azure Instance Metadata Service (IMDS). IMDS is available at a fixed, non-routable IP—169.254.169.254—inside every Azure VM and pod. The shell process inside the agent pod issues a request to the IMDS identity endpoint, asking for an OAuth token scoped to Azure Resource Manager.

If the pod is running with a managed identity (often assigned so it can access Azure Storage, Key Vault, or other services), this request returns an access token. With that token, the attacker can read or write Key Vault secrets, access Azure Storage, modify infrastructure via Azure Resource Manager APIs, and move laterally into other subscriptions where the identity has rights. Vectra AI’s research reports SSRF attacks surged 452% between 2023 and 2024, with cloud metadata services as the primary target. The blast radius now extends far beyond the original pod.

The control that stops this: Blocking IMDS access from agent pods—three approaches covered in the next section. And per-agent Workload Identity scoped to the narrowest Azure RBAC role, so even if a token is stolen, its blast radius is contained.

Deploying per-agent Workload Identity Federation on AKS

The single most impactful control against the 47-second attack chain is identity scoping. If the stolen token at T+47s can only read one storage container instead of reconfiguring your environment, the blast radius shrinks from “cloud incident” to “isolated pod issue.”

Azure AD Workload Identity Federation (now Microsoft Entra Workload ID) lets a Kubernetes service account authenticate to Azure AD through OIDC token exchange—no stored secrets, no pod-mounted managed identities. For AI agents, this means each agent deployment gets its own identity with its own narrow permissions.

Enable OIDC and Workload Identity on your cluster

Start by enabling two features on your AKS cluster: the OIDC issuer, which exposes your cluster’s service account tokens in a format Azure AD can validate, and the Workload Identity webhook, which injects the token exchange plumbing into your pods automatically. For existing clusters, both can be enabled through a single Azure CLI update command with the OIDC issuer and workload identity flags. Once enabled, capture the OIDC issuer URL from the cluster properties—you’ll need it when creating federated credentials.

Create a managed identity per agent

Each AI agent deployment gets its own user-assigned managed identity. Don’t share identities across agents “for convenience”—that makes blast radius impossible to reason about when one agent is compromised. Provision an identity named for the specific agent (for example, “id-agent-invoice” for an invoice-processing agent) and capture the client ID. You’ll use it in the Kubernetes service account annotation and Azure role assignments.

Scope Azure RBAC to the narrowest resource

This is where most teams go wrong. An invoice-processing agent needs to read secrets from one Key Vault and read blobs from one storage container. It does not need Contributor on the resource group. When creating role assignments, set the scope to the specific resource: assign Key Vault Secrets User on the individual vault, or Storage Blob Data Reader on the individual storage container—not on the resource group or subscription.

Compare this to the common failure: assigning Contributor at the resource group level. That single role assignment gives the agent identity write access to every resource in the resource group—Key Vault, SQL, Storage, and the AKS cluster itself. When the T+47s attacker steals that token, they own the resource group.

Create the federated credential and service account

The federated credential is the trust link between Kubernetes and Azure AD. It binds your agent’s managed identity to a specific Kubernetes service account in a specific namespace, using the cluster’s OIDC issuer URL. The subject field follows a standard format that identifies both the namespace and the service account name—this ensures only that specific service account in that specific namespace can assume this Azure identity.

On the Kubernetes side, create a ServiceAccount with two critical fields: an annotation containing the managed identity’s client ID, and a label that tells the Workload Identity webhook to inject the token exchange configuration. When a pod references this service account, the webhook handles the rest automatically—no code changes needed in the agent application.

Audit regularly

Review federated credentials periodically to ensure they match active deployments. Azure supports a maximum of 20 federated credentials per managed identity—plenty for most agent fleets but worth tracking. List the federated credentials on each agent identity periodically and remove any that correspond to decommissioned agents or namespaces that no longer exist.

Blocking the metadata endpoint: three approaches on AKS

The T+47s stage showed why IMDS is the critical target. By default, every pod in an AKS cluster can reach 169.254.169.254 and request a managed identity token. For AI agents, this default must be closed. Three approaches, each with different trade-offs:

Approach 1: AKS IMDS Restriction (preview)

AKS now offers a built-in node-level feature that blocks non-host-network pods from reaching the IMDS endpoint. This is the cleanest approach—it applies cluster-wide using iptables rules on each node, without requiring per-namespace NetworkPolicies. Enable it through the Azure CLI with the IMDS restriction flag, then reimage the nodes so the iptables rules take effect.

Constraints to know: This is a preview feature—not backed by production SLAs. Several AKS add-ons that depend on IMDS access (Azure Monitor agent, Azure Policy add-on, Flux/GitOps) are not compatible when IMDS restriction is enabled. Host-network pods are exempt, since they share the node’s network namespace. Verify add-on compatibility before enabling in production clusters.

Why this works well with Workload Identity: Workload Identity Federation uses the cluster’s OIDC issuer for token exchange—pods get Azure AD tokens through the mutating webhook, not through direct IMDS calls. Enabling IMDS restriction closes the fallback path where a compromised process could bypass the webhook and call IMDS directly.

Approach 2: NetworkPolicy blocking IMDS specifically

For clusters where the preview feature isn’t viable, a Kubernetes NetworkPolicy can block egress to the IMDS IP specifically while allowing all other traffic. The policy applies to the AI agent namespace, allows egress to all destinations except 169.254.169.254, and requires a network policy engine—Azure CNI Powered by Cilium (recommended) or Calico.

A gotcha to be aware of: Historically, the legacy Azure Network Policy Manager (NPM) did not reliably block traffic to 169.254.169.254 in some configurations. Azure is deprecating NPM in favor of Cilium. If you’re using Azure CNI Powered by Cilium or Calico, IMDS blocking via NetworkPolicy works reliably. If you’re still on NPM, test this explicitly before relying on it.

Approach 3: Default-deny egress with explicit allow-list

The strictest approach. Create a NetworkPolicy in the AI agent namespace that denies all egress by default, then create a second policy for each agent that explicitly allows only the destinations it actually needs—typically internal service IPs over HTTPS and DNS resolution to the cluster’s DNS service.

This approach blocks IMDS implicitly—169.254.169.254 isn’t in any allow rule. It also prevents agents from calling arbitrary external endpoints if abused. The trade-off is operational overhead: you need to maintain the allow-list as agent dependencies change.

Which approach to choose: AKS IMDS Restriction for broad coverage if your add-ons support it. Default-deny egress for namespaces with high-risk AI agents that need the strictest control. The IMDS-specific NetworkPolicy as the middle ground when you need targeted IMDS blocking without touching all egress.

Restricting Kubernetes API server access from agent pods

The T+32s stage showed what happens when an AI agent pod can query the Kubernetes API: cluster reconnaissance, secret enumeration, lateral movement mapping. Most AI agents don’t need direct API server access—they should talk only to the application services they’re meant to use.

Network-level restriction

Add a NetworkPolicy that blocks egress to the API server from the AI agent namespace. If you’re using Cilium, you can use FQDN-based filtering to target the API server hostname directly. With standard Kubernetes NetworkPolicy, retrieve the API server IP from the cluster’s endpoints object, then add that IP to the exception list alongside the IMDS address—the same pattern used in Approach 2 above, extended to cover both destinations.

RBAC minimization for agent service accounts

Don’t bind cluster-wide roles to AI agent service accounts. If the agent genuinely needs some Kubernetes API access (rare), create a namespace-scoped Role with only the specific verbs, resources, and resource names required. For example, if an agent needs to read a single ConfigMap, the Role should grant read access on ConfigMaps restricted to that specific ConfigMap name—not list or watch access across all ConfigMaps, and certainly not across all namespaces.

A common mistake: during development, teams bind the cluster-admin role to agent service accounts because it’s faster. Those bindings persist into production. The agent’s service account can now list secrets, delete pods, and modify RBAC across every namespace—exactly the reconnaissance path the T+32s attacker exploits.

AKS-specific observe-to-enforce implementation

The controls above—Workload Identity, IMDS blocking, API server restriction, RBAC minimization—are the infrastructure layer. But writing these policies requires knowing what your agents actually do, which is the policy paralysis problem that the progressive enforcement methodology solves. Here’s what the observe-to-enforce workflow looks like specifically on AKS:

Week 1: Deploy and observe

Deploy ARMO’s cloud-native security for AI workloads on the AKS node pools hosting your agents. The eBPF-based sensors operate at the Linux kernel level (1–2.5% CPU, 1% memory overhead)—no sidecars, no code changes, no developer coordination. At the same time, configure Workload Identity Federation per agent using the steps above.

Let the sensors build behavioral baselines: which processes each agent container runs, which network destinations it reaches, which Azure APIs each identity calls, and which system calls are normal. ARMO calls these baselines Application Profile DNA—a runtime-derived representation of what “normal” looks like for each specific agent.

Week 2: Generate policies from behavior

Review the observed traffic patterns. Generate NetworkPolicies from actual destinations—if the invoice agent only talks to the invoices Key Vault and one internal API, the policy allows exactly those endpoints. Identify which agents access IMDS during bootstrap versus never (most agents using Workload Identity should never call IMDS directly). Generate seccomp profiles from observed syscalls, so containers can only use the system calls they actually need. Flag identities with Azure RBAC permissions they never exercise—those are candidates for tighter scoping.

Week 3: Enforce and connect

Apply the generated NetworkPolicies in AI agent namespaces. Enable IMDS restriction or apply the IMDS-blocking NetworkPolicy. Scope Azure RBAC assignments to match observed permissions. Route runtime attack stories into Microsoft Sentinel alongside Defender for Cloud alerts, so your SOC sees behavioral detections and prompt-level alerts in the same incident view. Establish containment playbooks for metadata access anomalies—the 47-second timeline tells you exactly how much response time you have.

For the full four-stage maturity model behind this approach—including how to handle behavioral drift when models update and prompts change—see the progressive enforcement guide.

Detecting legitimate vs. malicious IMDS access

Even with IMDS blocking in place, you need to understand the difference between normal and anomalous metadata access—because some environments can’t fully block IMDS without breaking bootstrapping flows.

The pattern: Legitimate IMDS access happens during pod startup. When a pod uses Workload Identity, the mutating webhook intercepts token requests at bootstrap and exchanges the Kubernetes service account token for an Azure AD token via the OIDC flow. The pod may briefly touch IMDS during its first few seconds of life. After initialization, the pod should never contact 169.254.169.254 again.

The anomalous signal: A metadata call from a child process spawned by an AI tool—not from the pod’s init sequence—is a strong indicator of compromise. In the T+47s attack, the request to IMDS comes from a process that’s a child of a shell, itself spawned by the tool runner, 47 seconds into the pod’s life. That’s a completely different process lineage than the webhook-mediated bootstrap access at second 0–2.

This is exactly what behavioral baselining catches. The baseline shows IMDS access at pod startup as normal. An IMDS call from a tool-spawned shell at T+47s triggers an alert—or, in enforce mode, gets blocked—because it deviates from the behavioral profile. Static network policies can’t make this distinction; they either block IMDS or allow it. Runtime behavioral detection understands when and how the access happens.

Conclusion

The 47-second attack chain gives you a concrete threat model for AI agents on AKS. The controls in this article—per-agent Workload Identity Federation, IMDS blocking, default-deny egress, API server restriction—close the infrastructure gaps. Runtime behavioral detection closes the visibility gap: knowing when those controls are being tested by an attacker, and connecting the dots into a story your SOC can act on.

Map your current AKS controls against the attack timeline. Where do your agents have broader identity scope than they need? Can your pods reach the metadata endpoint? What cluster-wide roles are bound to agent service accounts? Run the scenario, then see what the full attack story looks like in ARMO.

Frequently asked questions

Should I use Azure CNI with Cilium or Calico for AI agent network policies?

Cilium is now the recommended path on AKS. Azure CNI Powered by Cilium provides eBPF-based enforcement, L7 policies, and FQDN filtering—all relevant for AI agent sandboxing. The legacy Azure Network Policy Manager is being deprecated on both Windows (September 2026) and Linux (September 2028) nodes. For AI agent namespaces where you want HTTP-method-level or path-level filtering on egress, Cilium gives you that granularity. Calico works and is supported, but Cilium is where Azure is investing.

Can Azure Policy enforce runtime sandboxing controls on AKS?

Azure Policy for AKS enforces admission-time rules through Gatekeeper—it can block privileged containers, require resource limits on AI workload pods, enforce network policies between namespaces, and mandate specific labels. It cannot observe or restrict what happens inside a running container. Admission-time governance (Azure Policy) and runtime enforcement (eBPF-based behavioral detection) are complementary layers. Use Azure Policy to prevent insecure pod configurations from being deployed; use runtime enforcement to detect and contain what those pods actually do.

What’s the blast radius if an attacker gets a Workload Identity token?

It depends entirely on the Azure RBAC scope. A token from an identity with Contributor on the subscription gives access to every resource in every resource group. A token from an identity scoped to Key Vault Secrets User on a single vault gives access to that vault’s secrets only. Per-agent identity with narrow scope is the single most impactful control you can deploy against the T+47s attack—it doesn’t prevent the token theft, but it decides whether the theft matters.

How do I know if my current AKS configuration is vulnerable to the 47-second attack?

Run a simple test: deploy a pod in your AI agent namespace and attempt to reach the metadata endpoint at 169.254.169.254. If you get a response with instance metadata, your IMDS access is open. Then review what your agent service accounts are authorized to do inside the cluster—check whether they have broad roles that allow listing secrets or pods across namespaces. Finally, review the Azure RBAC assignments on the managed identities bound to your agent service accounts. If any have Contributor or broader roles at the resource group level, your blast radius is larger than it needs to be.