AI agent identity is an architecture decision, not a policy edit

At a glance

What this is: This is an analysis of why AI agent identity on Kubernetes is set by binding architecture, not by later IAM policy edits, with blast radius determined before runtime controls take effect.

Why it matters: IAM and platform teams need to treat AI agents as a binding and scope design problem, because policy-only remediation cannot undo shared identity, inherited overreach, or weak delegation boundaries.

Context

AI agent identity on Kubernetes is the problem of deciding which workload identity an agent uses, how far that identity can reach, and whether that scope can be attributed cleanly later. The article argues that the deployment-time binding choice matters more than post-deployment policy editing because the blast radius is already set when the agent ships.

The governance gap is familiar to IAM and platform teams: least privilege assumes the workload’s access pattern is knowable before execution, but AI agents do not behave like deterministic services. When prompts, tools, and inference outcomes shift the action set, a shared identity can turn one agent’s permissions into every agent’s permissions.

Key questions

Q: What breaks when AI agents reuse the same Kubernetes identity?

A: Shared identities turn multiple agent workloads into one effective trust boundary, so the resulting permissions become the union of every agent’s needs and mistakes. That creates inherited overreach, weak attribution, and audit findings that are hard to fix after deployment. The safer pattern is to separate agent identities before reuse becomes the default.

Q: Why does least privilege fail for AI agent workloads?

A: Least privilege fails when access cannot be enumerated at design time. AI agents can change their action set based on prompts, tools, and inference outcomes, so the permissions that look minimal on paper may still be too broad or too narrow in practice. Identity scope has to be decided from how the agent is bound, not only from the policy attached later.

Q: How do security teams know if an AI agent binding is too broad?

A: Look for shared roles, multiple agent types behind one principal, and audit findings that only show the binding rather than the specific workload. Those are signs the scope lives above the agent and is likely inherited by more than one workload. If runtime logs cannot tie actions back to a single agent, the binding is probably too broad.

Q: How should teams handle sub-agent credentials in delegated agent chains?

A: Treat sub-agent access as a separate identity decision, not a free inheritance from the parent. Token reuse gives the child the parent’s full scope, while fresh binding or narrowed token exchange preserves attribution and limits reach. Choose the child’s credential model before delegation becomes a hidden privilege expansion path.

Technical breakdown

Why least privilege breaks for non-deterministic agent workloads

Least privilege works when the workload’s action set is stable enough to enumerate at design time. AI agents are different because prompts, tools, and inference outcomes can change the sequence of actions at runtime, which means the privileges needed are not fully knowable in advance. On Kubernetes, that makes a ServiceAccount, IAM role, or federated binding an architectural boundary, not just a credential container. Once the binding is chosen, the agent can only operate inside the scope that binding permits, even if the policy attached later is tightened. The practical effect is that policy editing cannot restore a safer design if the original identity envelope was too broad.

Practical implication: Treat agent identity scope as a deployment architecture decision and size the binding before the workload goes live.

How shared identities create inherited overreach

Shared-identity collapse happens when multiple agent types reuse the same role or ServiceAccount because creating a new one feels costly. The result is a union of capabilities, not a clean per-agent scope: every agent inherits what the other agents can do, and the blast radius becomes the sum of all their permissions. This is especially dangerous when the identity sits above the agent, because the audit trail may only show the role, not the specific workload that exercised the excess. Runtime findings can therefore surface long after the architectural mistake was made, and editing the policy at that point only exposes the fact that the role is already serving conflicting workloads.

Practical implication: Separate agent identities by work envelope before reuse creates unioned permissions that are hard to unwind.

What federated and ephemeral bindings change at runtime

Pod-level federation, per-agent federation, and per-session ephemeral credentials each tighten the relationship between the workload and its identity, but they do so at different operational costs. Pod-level federation narrows the credential lifecycle but still allows shared scope across multiple agent types. Per-agent federation makes attribution cleaner because each agent maps to its own principal. Per-session issuance goes further by scoping the credential to a task and expiring it when the task completes. The trade-off is that narrower runtime scope only helps when observability can verify that the binding matches actual behavior; otherwise, you merely move the complexity into token issuance without proving the reduction in exposure.

Practical implication: Use runtime-scoped credentials only where your telemetry can prove the agent stayed inside the intended task boundary.

Threat narrative

Attacker objective: The effective objective is to exercise more cloud capability than the new agent should have been granted, using an inherited identity scope that survives policy cleanup.

1. Entry occurs when a platform engineer reuses an existing ServiceAccount with cloud access so a new agent can ship quickly under an already-authorised identity.
2. Credential access is not stolen here, but the reused binding grants the new agent the same cloud permissions as the older workload, including any excess already present on the role.
3. Impact follows when policy edits stall because another agent using the same role depends on the permissions being removed, leaving the excessive scope in place and the finding recurring at audit time.

Breaches seen in the wild

• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Binding architecture, not policy editing, is the first-order control plane for AI agent identity. The article shows that the agent’s blast radius is determined at deployment when the ServiceAccount or federated role is chosen. Editing IAM policy later can only trim what was already granted, not change the fact that the workload identity was over-scoped from the start. The practitioner conclusion is simple: identity architecture has to be designed before the agent is allowed to ship.

Least privilege is losing precision because AI agents make access non-deterministic at runtime. The assumption that a workload’s access pattern can be enumerated in advance was reasonable for deterministic services, but it fails when prompts and tool selection change the action set. That is an assumption collapse, not just a missing control. The implication is that identity teams need to rethink how privilege is defined for workloads whose intent is not fixed before execution begins.

Shared-identity collapse creates an identity blast radius that audit evidence cannot easily unwind. When one role serves multiple agent types, the permissions become the union of all of them, and audit findings surface months after the architectural mistake. The article’s most useful concept is the union-scope problem: reuse above the agent creates inherited overreach below it. Practitioners should assume every shared binding is a future exception queue until proven otherwise.

Per-agent attribution is now a governance requirement, not an implementation nicety. The difference between pod-shared and per-agent identity is the difference between ambiguous and traceable access. Clean attribution matters because the control question is no longer only what the agent can do, but which agent did it and under which binding. That is where NHI governance meets Kubernetes design, and it is where mature programmes will need to focus their review cycles.

Runtime scoping only works when the organisation can observe behaviour, not merely issue tokens. Per-session credentials reduce exposure only if telemetry proves the task stayed within the intended boundary. Without that evidence, teams are swapping static scope risk for invisible dynamic scope risk. The practitioner takeaway is to match binding style to observability maturity, or the control will look tighter on paper than it is in practice.

From our research library:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Cloud Workload Identity Guide

What this signals

Identity scope for AI agents has to be decided before deployment, because the binding choice is what sets blast radius. For Kubernetes programmes, that means ServiceAccount design, workload federation, and role partitioning belong in architecture review, not only in post-deployment policy cleanup. Teams that wait for audit findings are already dealing with a scope decision that was made upstream.

Union-scope reuse is the failure mode most likely to survive into production. A shared role can look efficient until the first agent’s permissions become the second agent’s hidden dependencies. Once that happens, policy edits start colliding with live workloads, and the organisation discovers that identity reuse is a governance debt, not an optimisation.

Runtime telemetry should validate agent scope, not merely record activity. Observability only becomes useful when it proves the agent stayed inside its intended work envelope, especially where per-session credentials or delegated child identities are involved. Without that proof, teams are measuring usage, not governance.

For practitioners

• Define per-agent identity by work envelope Give each agent type its own ServiceAccount and federated principal so one workload cannot inherit another workload’s cloud scope.
• Stop reusing shared roles across agent types Treat any shared IAM role or Kubernetes binding as temporary and time-bound, then split it before audit findings become union-scope exceptions.
• Use runtime observations to tighten scope Start from a broad observation-mode role, then narrow the binding only after runtime telemetry shows the agent’s actual calls and resource use.
• Scope delegated child agents separately Avoid token reuse for sub-agents and use a narrowed child credential or fresh binding when delegation crosses data or privilege boundaries.

Key takeaways

• AI agent identity on Kubernetes is governed by how workloads are bound, not by later edits to IAM policies.
• Shared identities create unioned permissions that are difficult to unwind once multiple agent types depend on the same role.
• Per-agent or per-session scoping only works when architecture and observability are aligned from the start.

Key terms

• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Shared-Identity Collapse: A governance failure where multiple AI agents share one role or ServiceAccount, causing their permissions to merge into a single blast radius. The problem is structural, not just operational, because the audit trail and accountability model stop matching the real behavioural boundaries.
• Per-Agent Federation: A design pattern in which each agent type gets its own federated principal and ServiceAccount. This separates permission scope, improves attribution, and makes access reviews possible at the workload level rather than at a shared binding level.
• Per-Session Credential: A short-lived credential issued for one task or invocation rather than for a long-lived workload identity. It reduces standing privilege, but it only improves security when runtime instrumentation can prove the credential actually matches the task scope.

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 programme, it is worth exploring.