Notifications
Clear all
Topic starter
22/07/2026 4:36 pm
TL;DR: Google’s agent runtime work shows Kubernetes can isolate AI agents and schedule them across clouds, but it does not solve stable identity, per-tool authorization, or per-action auditability, according to Pomerium’s analysis. The missing control layer is identity-aware access that binds each agent action to a verified principal and policy decision.
NHIMG editorial — based on content published by Pomerium: Google built an agent runtime on Kubernetes, and here is how to build a cloud-agnostic one with identity included
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.
Questions worth separating out
Q: How should security teams govern AI agents that call internal tools from Kubernetes?
A: They should separate runtime containment from identity governance.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Pomerium's analysis of identity-included agent runtimes on Kubernetes →
Agent runtimes on Kubernetes: what identity layer teams are missing?
Explore further
22/07/2026 4:40 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Identity included: why cloud-agnostic agent runtimes need access control
