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.
Editorial analysis by NHI Mgmt Group, based on content published by Pomerium: “Google Built an Agent Runtime on Kubernetes. Here's How to Build a Cloud-Agnostic One with Identity Included”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Cloud-agnostic agent runtimes still need identity controls because isolation and scheduling do not decide who an agent is acting for.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
22/07/2026 4:40 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Identity included: why cloud-agnostic agent runtimes need access control