AI agent security on Azure AKS depends on handoff control

At a glance

What this is: This is a practical guide to wiring AI agent security on Azure AKS, with the key finding that most failures come from broken handoffs between Azure services rather than missing controls.

Why it matters: It matters because IAM, PAM, and cloud security teams need runtime evidence of what AI agents actually do, not just declared policy, especially when Workload Identity, audit logging, and detection are split across teams.

👉 Read ARMO's practical guide to AI agent security on Azure AKS

Context

AI agent security on AKS starts with a governance gap, not a tooling gap. Azure can provide identity, audit, posture, and detection building blocks, but the control plane, log destinations, and runtime signals are often owned by different teams. For identity and access programmes, that means declared configuration can drift far from observed agent behaviour, especially when Workload Identity Federation and cluster logging are managed separately.

The article is really about how to operationalise AI agent security on AKS without assuming that “enabled” means “effective.” The important boundary is between policy and runtime evidence: admission controls, federated identity scopes, and logging pipelines all need explicit handoffs, or the agent’s tool use, data access, and behavioural drift remain partially invisible. That is a genuine IAM and NHI governance problem, not just a Kubernetes one.

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 create gaps in existing cloud security controls?

A: Because many controls stop at the boundary of the model, the cluster, or the policy engine. AI agents can accept a prompt, choose a tool, and act inside the workload at runtime, so teams need both declared access control and observed behaviour monitoring to understand what the agent actually did.

Q: What breaks when AKS audit logging is not wired correctly?

A: The entire evidence chain breaks. If Diagnostic Settings do not route kube-audit data to a workspace that SecOps can query, later detection, forensics, and compliance review depend on assumptions instead of records. That creates a false sense of coverage even when the cluster is otherwise healthy.

Q: When should organisations restrict AI agent access more aggressively?

A: Restrict access aggressively when an agent can reach production systems, sensitive data, or multiple connected services through broad delegated permissions. Those conditions increase the effective blast radius, so tighter scopes, stronger approvals, and faster review cycles become necessary before adoption scales.

Technical breakdown

Diagnostic Settings are the first handoff point for AKS visibility

AKS control-plane logging does not become useful automatically. Diagnostic Settings must explicitly route kube-audit or kube-audit-admin events to a workspace, storage target, or event hub that SecOps can actually query. Because the cluster and the log destination are often owned by different teams, visibility fails at the integration point rather than at the sensor layer. In practice, this means an environment can look monitored while audit evidence never leaves the cluster boundary. For AI agents, that matters because audit logs are the only durable record of namespace actions, identity use, and control-plane changes before runtime behaviour is correlated.

Practical implication: Verify the log routing chain end to end before relying on any downstream detection or compliance reporting.

Workload Identity Federation separates declared access from observed behaviour

On AKS, Workload Identity Federation uses OIDC federated credentials with subject-claim filters, so permissions are expressed as identity bindings rather than node credentials. That helps reduce static secret exposure, but it does not prove which Azure services an agent actually uses. The article’s key point is the difference between declared scopes and observed API usage. If an agent is allowed to reach Key Vault, Storage, Cosmos DB, and Azure OpenAI but only ever uses two of them, the extra allowance is excess entitlement, not theoretical convenience. Runtime profiling turns that gap into a posture signal.

Practical implication: Use observed API activity to tighten federated scopes and remove unused privileges from AI workloads.

Prompt inspection stops at the API boundary, not inside the cluster

Defender for AI Services inspects prompts and responses at the Azure OpenAI boundary, which is useful for jailbreaks, prompt injection, data leakage, and credential theft patterns. But once a model response is returned, the agent may make tool calls, spawn processes, or access data inside the cluster. That behavioural cascade is outside the model boundary. For AI workload security, this means content-plane protection and runtime behavioural detection are complementary, not interchangeable. The article also ties this to broader NHI governance because tool access often depends on credentials, tokens, and service identities that the runtime layer must observe directly.

Practical implication: Pair boundary inspection with kernel-level behavioural detection if you need to see agent escape, tool misuse, or anomalous data access.

Threat narrative

Attacker objective: The attacker wants to turn a trusted AI agent into a bridge from model interaction to unintended tool use and data access.

1. Entry begins when a successful prompt injection or other model-side manipulation changes what the agent is instructed to do inside Azure OpenAI or a similar model boundary.
2. Escalation follows when the agent uses its allowed tools, federated identity, or cluster privileges in ways that exceed its normal behavioural profile.
3. Impact occurs when the agent reaches data, systems, or external services that were not part of its intended operational scope.

NHI Mgmt Group analysis

Handoff failure is the real control gap in AKS AI security. The article shows that Azure can supply separate services for audit, posture, detection, and enforcement, yet those controls still fail if the handoff between them is not explicitly engineered. That is a governance problem, not a product problem. In identity terms, the environment may have federated credentials and policy controls, but no reliable chain from declared access to observed behaviour. Practitioners should treat integration ownership as part of the control surface.

Declared privilege is no longer a sufficient security signal for AI workloads. Workload Identity Federation reduces standing secret exposure, but AI agents are judged by what they actually do at runtime. The article’s runtime profiling approach is a reminder that excess entitlement is often invisible until behavioural evidence is collected. That aligns closely with NHI governance, where the question is not whether an identity exists, but whether its effective access matches its intended task. Practitioners should baseline observed use before trimming privilege.

Prompt-level inspection and runtime detection solve different problems. Defender for AI Services can flag content-plane threats, but tool misuse, agent escape, and drift happen after the model responds. That makes the security model inherently layered: one control sees the prompt, another sees the execution path. For AI and identity teams, the implication is that model security and workload identity governance must be correlated, not independently reported. Practitioners should avoid treating API-boundary filtering as sufficient runtime protection.

Behavioral baselining creates a more precise form of AI governance debt management. The article implicitly defines a named concept: behavioural governance debt, the accumulation of unverified agent permissions, unobserved tool use, and mismatched ownership across cloud services. This debt grows whenever teams assume configuration equals control. In the broader market, that reinforces the shift toward runtime evidence as the basis for AI agent policy. Practitioners should reduce governance debt before expanding autonomous tool access.

Azure’s fragmentation pushes security teams toward integration-led governance. The article is not just about AKS. It reflects a wider cloud pattern where security capability is available, but only if teams understand licensing, ownership, and telemetry pathways across products. For identity programmes, that means the control objective is increasingly orchestration across services rather than point-tool deployment. Practitioners should map each AI security pillar to a named owner and a tested data path.

What this signals

Behavioural evidence is becoming the deciding control for AI workloads. As agentic systems expand across cloud platforms, teams will need to prove what an agent did, not just what it was allowed to do. That shifts governance from static entitlement review toward runtime profile validation, especially where workload identity and tool access intersect. For practitioners, the implication is that policy without telemetry will increasingly fail audit and incident response requirements.

Runtime correlation is the next maturity step for identity governance in AI environments. When model boundaries, cluster controls, and federated credentials are managed separately, the programme needs a common evidence layer that links prompt, tool call, and data access. The Ultimate Guide to NHIs remains the right baseline for service accounts, tokens, and lifecycle control, but AI agents add a behavioural dimension that traditional IAM does not cover. Practitioners should expect this gap to widen before it closes.

For practitioners

• Map every AI security pillar to a named owner Document who owns Diagnostic Settings, the Log Analytics workspace, Workload Identity Federation, Azure Policy, Defender plans, and Sentinel ingestion. Then test the full path from cluster event to analyst-visible alert so no control depends on an assumed handoff.
• Baseline observed agent behaviour before tightening scopes Record which Azure APIs, MCP tools, and data sources each agent actually uses, then compare that profile with its federated credential scope. Remove unused permissions and review any scope that is broader than observed behaviour requires.
• Treat model-boundary detection as incomplete Keep Defender for AI Services in place for prompt-level threats, but add runtime telemetry for process lineage, network destinations, and file access inside AKS. The goal is to correlate prompt events with tool execution and data access, not to rely on one layer alone.
• Audit federated credential scopes after deployment Review OIDC subject claims, audience values, and Azure AD app bindings on a recurring basis. If the agent’s runtime profile no longer matches the access it was granted, tighten the federated credential before the excess entitlement becomes normalised.

Key takeaways

• AI agent security on AKS fails most often at the handoff points between services, not at the absence of tools.
• Runtime behaviour is the only reliable way to distinguish intended agent activity from excess privilege and tool misuse.
• Teams need separate controls for model-boundary inspection, cluster-level telemetry, and federated identity scope if they want governable AI agents.

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.
• Diagnostic Settings: An Azure configuration path that routes platform logs and metrics to a destination such as Log Analytics, Event Hub, or Storage. In security operations, it is often the difference between having a running cluster and having evidence that the cluster can actually be investigated.
• Runtime Behaviour Baseline: The expected pattern of activity for an identity while it is operating in production. It goes beyond entitlement lists by comparing actual actions, timing, and access paths, which is critical when valid credentials can still be abused.
• Governance Debt: The accumulation of unresolved identity control weaknesses created when teams prioritise speed over lifecycle design. In NHI environments, it shows up as accounts with unclear ownership, undocumented purpose, stale credentials, and no reliable retirement path, all of which make later security work harder.

What's in the full article

ARMO's full blog covers the implementation detail this post intentionally leaves for the source:

• Step-by-step guidance for deploying the eBPF sensor as a DaemonSet on AKS user node pools.
• The full pillar ownership map that ties Azure services to Observe, Posture, Detect, and Enforce.
• Implementation detail for Defender plan selection, Sentinel routing, and Workload Identity Federation setup.
• Examples of runtime AI-BOM and Application Profile DNA outputs used to tune behavioural baselines.

👉 ARMO's full post covers the AKS wiring, control ownership, and runtime detection detail behind the framework.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners responsible for modern identity boundaries. It helps security teams connect runtime evidence, access scope, and lifecycle control across hybrid environments.