Identity included: why cloud-agnostic agent runtimes need access control

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Pomerium's blog post: Cloud-agnostic agent runtimes need an identity-aware access layer because Kubernetes isolation and scheduling do not solve who an agent is acting for, what it may do, or how each action is audited.

Why it matters: This matters because IAM, PAM, and NHI teams will otherwise treat agents like workloads with stable privilege, when the real governance problem is per-action authorization and accountable delegation.

Context

Kubernetes can provide placement and isolation, but it was not designed to govern AI agents that wake, act, and sleep in short bursts. In that model, the identity problem is not container placement. It is how each agent session is bound to a principal, a policy, and an auditable decision path once it reaches real systems.

The article’s core point is that runtime portability is only half the problem. When an agent talks to internal APIs, MCP servers, ticketing tools, or source control, the control boundary shifts from execution containment to identity-aware access control. That is where NHI governance, delegation, and action-level auditability become the decisive controls.

Key questions

Q: How should security teams govern agent runtime access on Kubernetes?

A: Security teams should treat the runtime as an execution layer, not the governance layer. The important controls are delegated identity, per-tool authorization, and action-level audit trails. If those controls sit outside the runtime, the cluster may isolate code, but it will not govern what the agent is allowed to do once it reaches business systems.

Q: Why do workload identity standards matter more as AI agents proliferate?

A: Workload identity standards matter because they create a common way to prove identity across services and agents without relying on shared secrets or one-off integrations. As AI agents proliferate, the bigger challenge shifts to controlling what those identities can do after authentication. Standards reduce identity chaos, but governance still has to manage privilege and behaviour.

Q: What breaks when agent access is treated like a normal service account?

A: You lose visibility into why a specific call was allowed, which context justified it, and whether the action still made sense at the time it executed. Agents can behave differently from ordinary service accounts because they make multiple decisions inside one workflow. Governance has to follow the action chain, not just the identity label.

Q: What should teams do when an agent can call internal APIs and MCP servers?

A: Teams should require request-by-request policy decisions, not session-level trust. Each call should be tied to a verified principal, evaluated against least privilege, and written to logs with enough detail to explain why it was allowed or denied. That is the only practical way to preserve accountability across delegated agent activity.

Technical breakdown

Why Kubernetes isolation does not solve agent identity

Kubernetes, gVisor, and Kata Containers constrain where untrusted code runs, but they do not decide who that code acts for. An agent runtime can snapshot state, schedule workers, and isolate execution while still leaving every meaningful authorization question unanswered at the tool boundary. That gap matters because the agent is not just computing. It is initiating requests into business systems. Once a model-generated action crosses the sandbox boundary, isolation no longer supplies identity, delegation, or policy context. The security model changes from workload containment to governed access. Practical implication: treat runtime isolation as necessary but insufficient, and add identity controls at the point where the agent touches external tools.

Practical implication: separate containment controls from access controls so the sandbox does not become the only security boundary.

Stable identity for agents is not the same as workload identity

Workload identity can prove that a pod is legitimate, but it does not express task-level intent. An agent needs a stable identity that follows the session, yet it also needs authorization scoped to the action, tool, and delegated user context. That is a different problem from pod authentication. If the agent carries standing credentials, the blast radius becomes detached from the human or workflow that initiated it. If the agent only inherits coarse workload identity, governance cannot distinguish a harmless read operation from a destructive admin action. Practical implication: bind agent sessions to delegated identity and policy decisions, not to static service credentials.

Practical implication: define agent identity as delegated and policy-bound, not as a generic service account with broader reach.

Per-action auditability is the missing control plane for agentic access

Traditional logs often record that a session existed, not which tool call was allowed, denied, or why. For agentic systems, that is not enough. Security teams need authorization records that capture the method, tool, parameters, and policy decision for each action because the model may generate many fine-grained requests inside one session. Without that record, incident review collapses into guesswork and accountability becomes blurred across the user, agent, and underlying access layer. Practical implication: build audit trails around individual actions rather than session summaries, especially where MCP or similar tool protocols are involved.

Practical implication: log every authorization decision at the tool-call level so post-incident review can reconstruct agent behaviour.

NHI Mgmt Group analysis

Identity-aware access is the missing layer in cloud-agnostic agent stacks: Isolation and scheduling answer where an agent runs, but they do not answer who it is acting for or which actions it may take. That gap becomes decisive the moment the agent reaches an API, ticketing system, or MCP server. Practitioners should read agent runtimes as incomplete until identity and policy are enforced at the request boundary.

Agent sessions should be governed as delegated access, not as autonomous privilege containers: A standing credential attached to an agent creates a service account with model behaviour layered on top, which is exactly the governance mistake teams should avoid. The right question is not whether the agent is contained, but whether each action is tied to a verified principal and a bounded policy decision. That is a lifecycle and governance issue, not a runtime convenience.

Per-action auditability is now a baseline requirement for AI operations: Session-level logging is too coarse when the system can generate many discrete tool calls inside one burst of activity. The control objective shifts from proving that an agent existed to proving what it was allowed to do, for whom, and why. That is the difference between operational telemetry and defensible identity governance.

Cloud portability will accelerate, but control consistency will lag unless identity becomes portable too: Open-source runtimes can move across clusters and clouds, yet identity policy often remains tied to a single platform or perimeter pattern. The market signal is clear: portability without identity governance simply redistributes risk across infrastructure. Practitioners should expect agent identity controls to become a deciding architecture layer rather than an add-on.

Identity blast radius is the right concept for agent runtimes: The relevant question is not whether the sandbox contains the code, but how far an authorised action can spread once the agent is allowed to call tools. That concept connects NHI governance, delegation, and zero trust into one practical lens. Teams that cannot bound identity blast radius do not yet have a safe agent architecture.

From our research library:

• Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.
• Read next: Agentic AI Identity Guide

What this signals

Identity-aware access will become the control plane for agentic systems: As more agent runtimes move onto Kubernetes and other portable infrastructure, the differentiator will not be where the code runs but how every action is authenticated and authorized. Teams should expect their current workload controls to look increasingly incomplete once agents start touching business systems directly.

The practical shift is from platform trust to delegated trust. That means identity policy, not cluster placement, becomes the governance layer that decides whether an AI agent can read, write, or trigger downstream workflows on behalf of a user or service.

Identity blast radius is the right metric for this architecture: If a single agent credential can reach too many tools or too much data, the runtime is overexposed even if the sandbox is sound. The programme question is whether access decisions are bound tightly enough to the task to survive real operational use.

For practitioners

• Define delegated agent identity Map every agent to a verified human or service principal and prevent free-floating agent credentials from becoming the default trust model.
• Move authorization to the tool-call layer Write policies that decide each MCP or API action individually, not just the session, and default-deny any destructive or admin-prefixed operations.
• Separate isolation from access governance Use sandboxing for containment, then add an identity control layer that governs what the agent can do once it reaches internal systems.
• Instrument per-action audit trails Log method, tool name, parameters, and the allow or deny reason for every agent request so investigations can reconstruct intent and outcome.

Key takeaways

• Cloud-agnostic agent runtimes still need identity controls because isolation and scheduling do not decide who an agent is acting for.
• Per-tool authorization and per-action auditability are the missing governance layers once agents leave the sandbox and touch real systems.
• Teams should treat agent access as delegated identity with bounded blast radius, not as a generic workload with broad standing privilege.

Key terms

• Agent Session Chain: An agent session chain is a sequence of child sessions derived from a root session, where each hop records lineage back to the original authority. It allows an agent to split a long job into smaller, separately revocable units while keeping identity and scope tied to the same underlying agent instance.
• Delegated Identity: Delegated identity is when one actor acts on behalf of another with explicit permission and bounded authority. In AI-assisted commerce, it requires clear consent, limited scope, and traceable records so the retailer can distinguish authorised delegation from unauthorised automation.
• Per-action authorization: A control model that evaluates each request as it happens rather than trusting a session after login. For agentic systems, it matters because the same authenticated identity can produce different risk outcomes depending on context, target system, and current instructions.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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.