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

At a glance

What this is: This is an analysis of cloud-agnostic agent runtimes on Kubernetes and the key finding that isolation alone does not govern agent identity, authorization, or auditability.

Why it matters: It matters because IAM, PAM, and NHI teams need controls that follow the agent at runtime, not just the pod, especially when agents call tools, APIs, and internal systems.

By the numbers:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems , organisations failing to scope AI access properly are 4.5x more likely to experience a security incident.

👉 Read Pomerium's analysis of identity-included agent runtimes on Kubernetes

Context

Cloud-native agent runtimes solve placement and isolation, but they do not answer the identity question that matters most for security: who the agent is acting for, what it may do, and how each action is recorded. For identity security programmes, the gap is not about running code safely in a cluster. It is about governing the agent once it leaves the sandbox and starts touching production systems, internal tools, and federated APIs.

That gap becomes sharper in Kubernetes because the platform was built for durable services, not stateful AI sessions that wake, act, and sleep repeatedly. The article’s core point is that infrastructure identity for agents needs a control layer above runtime containment, and that control layer has to align with NHI governance, access policy, and audit evidence. The question is not whether the agent can execute. It is whether its execution is attributable, scoped, and revocable.

Key questions

Q: How should security teams govern AI agents that call internal tools from Kubernetes?

A: They should separate runtime containment from identity governance. Kubernetes can isolate execution, but the tool boundary still needs delegated identity, per-request authorization, and action-level logging. Without those controls, the agent behaves like an unscoped service account with model-driven output, which makes attribution and revocation much harder.

Q: Why do cloud-native agent runtimes create new identity risk for IAM teams?

A: Because the agent becomes a runtime actor that can initiate tool calls, not just a workload that sits behind a pod. IAM teams must account for delegation, scope, and traceability across each action, especially when the same runtime works across multiple clouds and internal systems.

Q: What breaks when agent access is governed only at the Kubernetes layer?

A: You lose the ability to express tool-specific policy, user-scoped delegation, and per-action accountability. That leaves security teams with a container boundary, but not a meaningful authorisation boundary for the systems the agent can reach.

Q: How can organisations audit AI agent behaviour without over-privileging the workload?

A: By issuing delegated access through an access layer that logs every action and refreshes upstream credentials without exposing them to the agent. That preserves accountability while reducing the need for standing secrets that can be reused outside the intended session.

Technical breakdown

Why Kubernetes containment stops short of identity governance

Kubernetes can schedule workloads and enforce isolation boundaries, but those controls do not describe the identity of an AI agent once it begins calling tools or APIs. In the article’s model, the sandbox protects untrusted code, yet the real risk starts at the boundary where the agent needs delegated access to external systems. At that point, pod identity, network policy, and container isolation cannot express tool-level intent, per-request authorization, or user-scoped delegation. That is an NHI governance problem, not a runtime placement problem.

Practical implication: treat cluster isolation as a baseline control, not a complete agent security model.

Stable identity is the missing control plane for MCP traffic

The article’s most important architectural point is that an agent session needs a stable identity that persists across tool calls without becoming a standing credential. That is especially relevant where MCP servers expose internal tools to model-driven workflows. Workload identity can authenticate workloads, but it does not natively capture delegation, tool-specific policy, or per-action accountability. Identity-aware access therefore has to sit between the agent and the target system, evaluating each request as a discrete authorization event rather than a generic session grant.

Practical implication: place policy enforcement at the tool boundary, not only at workload admission.

Per-action auditability changes how agent risk is governed

Traditional logging answers what a session did, but AI agents require evidence at the action level because the model can generate many discrete operations inside a single runtime session. The article’s access layer records the method, tool, parameters, and policy outcome, which is the minimum viable evidence set for reviewing agent behaviour after the fact. That matters because security teams need to reconstruct not just access, but intent, delegation source, and policy rationale when an agent touches sensitive systems.

Practical implication: require action-level logs for every delegated agent request, not only session summaries.

NHI Mgmt Group analysis

Identity included is the real control problem for agent runtimes: the runtime stack can isolate code, but it cannot by itself govern the identity boundary where agents become operational actors. Once an agent can open tickets, query databases, or call internal tools, the security model is no longer about where the code runs. It is about who authorized the action, under what delegated context, and whether that context can be revoked cleanly.

Agent runtime design exposes a named concept we should carry forward: the runtime governance gap. This is the space between container isolation and identity-aware access, and it is where most current programmes are thin. The gap is not theoretical. It appears whenever a platform assumes that isolating execution also solves authorization, delegation, and audit. Practitioners should recognise that runtime security and identity governance are separate control planes that must converge at the action layer.

Per-action identity is now more important than per-session identity for AI systems. A session-based model can tell you where an agent lived, but not why a specific tool call was allowed or who it served. That is a governance failure because accountability must follow each action, not just the session envelope. For IAM and NHI teams, the implication is that agent control models need to be reviewed at the granularity of individual tool calls.

Least privilege for agents cannot be expressed only as workload placement or static entitlements. The article shows why agent access has to be constrained by tool, context, and delegation source. This is especially relevant when autonomous or semi-autonomous systems operate across cloud boundaries and internal SaaS tools. The practitioner takeaway is that agent governance must be identity-centric, not infrastructure-centric.

Cloud-agnostic agent stacks will only be safe when identity controls are cloud-agnostic too. If the runtime works on any Kubernetes distribution, the access policy and auditing layer must do the same or the control model fractures by environment. That makes centralized identity policy and portable enforcement the real differentiators, not the runtime branding. Practitioners should plan for portable access governance as a foundational requirement, not an integration afterthought.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, which shows how far governance maturity trails deployment.
• The next step is to anchor agent access in the OWASP Agentic AI Top 10 and the Ultimate Guide to NHIs so runtime policy and identity governance stay aligned.

What this signals

Runtime governance gap: the industry is converging on agent runtimes that can be deployed anywhere, but identity controls still need to decide who the agent serves, what it can do, and how each action is evidenced. That means platform teams and IAM teams must design together, not in sequence, if agentic systems are going to be governable across clouds.

With 53% of security leaders expecting AI to run major portions of infrastructure autonomously within three years, per The 2026 Infrastructure Identity Survey, access governance has to move from session thinking to action thinking. The operational signal to watch is whether your current identity stack can authorise individual tool calls without turning every agent into a standing privileged identity.

This also changes how teams should evaluate access telemetry. If the logs only show that an agent session existed, they are not enough for investigations, recertification, or delegated-risk review. The next programme milestone is action-level evidence that can be tied back to the acting principal and the policy reason for each decision.

For practitioners

• Define a stable delegated identity model for agents Bind each agent to a verified human or service principal so tool calls are attributable and revocable across sessions.
• Move authorization to the tool boundary Enforce per-request policy for MCP servers and other internal tools instead of relying on pod-level network controls or cluster admission alone.
• Require action-level audit logs Capture the tool name, parameters, policy decision, and acting principal for every agent action so investigations can reconstruct what happened.
• Review standing credentials used by agents Replace any free-floating agent secret with delegated access that is issued and refreshed by the access layer, then revoke unused upstream tokens on schedule.

Key takeaways

• AI agent runtimes can be isolated in Kubernetes, but isolation does not solve identity, delegation, or per-action authorisation.
• The practical control gap is at the tool boundary, where stable delegated identity and auditability matter more than pod placement.
• IAM and NHI teams should design for action-level governance now, because agentic systems are already moving beyond session-based security models.

Key terms

• 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.
• Tool-boundary authorisation: Tool-boundary authorisation means deciding, at the moment of execution, whether an agent may call a tool or system. It differs from ordinary login validation because the control is tied to the action itself, not just the identity that initiated the session.
• Content-Level Auditability: The ability to reconstruct the actual prompt, response, and policy decision involved in an AI interaction. Metadata alone proves a session occurred, but not what was read, generated, or blocked. For identity and compliance teams, this distinction determines whether investigations and attestations are defensible.
• Agentic Runtime Governance Gap: The distance between approving an AI agent as a project artefact and controlling its actual production behaviour. This gap appears when static approvals, access reviews, or policy documents do not keep pace with the agent’s live tool use and changing operational context.

What's in the full article

Pomerium's full blog post covers the operational detail this analysis intentionally leaves for the source:

• Layer-by-layer explanation of the open agent runtime stack, including Agent Sandbox, Agent Substrate, and kagent.
• Policy language examples showing how per-tool authorization is expressed for MCP traffic in practice.
• Delegation and token-handling details for acting on behalf of a human user without exposing upstream credentials.
• Logging and audit design for tracing each agent action back to the acting principal and decision reason.

👉 The full Pomerium post covers the runtime stack, delegation model, and action-level logging details.

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.