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

Why Kubernetes Is Not a Sufficient Authorisation Boundary for Agents

Governance at the Kubernetes layer answers a pod-and-cluster question, not an agent-and-action question. A container can be scheduled, isolated, and network-restricted while the agent inside still has broad tool reach, delegated user context, and the ability to chain requests across systems. That gap is exactly where agentic risk emerges, which is why OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both push decision-making closer to runtime behaviour rather than static deployment boundaries. For non-human identities, the practical issue is that Kubernetes can tell you where code runs, but not whether the agent should invoke a payment API, read a customer record, or escalate via a chained tool call. NHIMG research on OWASP NHI Top 10 shows the same pattern across incident reports: compromise follows excessive reach, not merely bad placement. In practice, many security teams encounter abuse only after the agent has already used legitimate cluster access to perform an illegitimate downstream action.

What Breaks in Practice When the Policy Stops at the Cluster

Once authorisation is limited to Kubernetes, three things typically fail at once: tool-specific policy, user-scoped delegation, and per-action accountability. The cluster may authenticate the workload, but it cannot express that an agent may read tickets on behalf of one user, write to a single repository, and never touch production secrets. Current guidance suggests using workload identity plus runtime policy evaluation, because the decision must reflect the action, the subject, the user context, and the target system. That is why practices aligned with OWASP Non-Human Identity Top 10 and CSA MAESTRO agentic AI threat modeling framework emphasise short-lived credentials, policy-as-code, and least-privilege delegation. In practice, the stronger pattern is: issue an ephemeral OIDC or SPIFFE-style identity for the workload, bind it to a narrowly scoped task, evaluate policy at request time, then revoke access when the task is complete. NHIMG has repeatedly documented how agent workflows amplify credential risk, including incidents like CoPhish OAuth Token Theft via Copilot Studio, where the real failure was not pod placement but uncontrolled token authority. The same pattern appears in Amazon Q AI Coding Agent Compromised, where the agent’s effective permissions mattered more than its runtime location. These controls tend to break down in multi-tenant clusters with shared service accounts because the cluster boundary is too coarse to distinguish one delegated task from another.

Where the Kubernetes Layer Still Helps, and Where It Does Not

Tighter cluster controls often increase operational overhead, requiring organisations to balance deployment simplicity against meaningful authorisation. Kubernetes remains useful for workload isolation, admission control, network segmentation, and node hardening, but there is no universal standard for treating it as the primary policy boundary for autonomous agents. The better pattern is layered: use Kubernetes to contain execution, then use an identity-aware control plane to govern what the agent can actually do. That means pairing cluster enforcement with external authorisation, short TTL secrets, and explicit action logging so investigators can reconstruct who delegated what and which tool was invoked. Best practice is evolving toward per-task controls rather than standing access, especially where agents can laterally move through SaaS tools, internal APIs, and secrets stores. For that reason, security teams should map Kubernetes hardening to broader identity governance using resources like Ultimate Guide to NHIs — 2025 Outlook and Predictions and NIST Cybersecurity Framework 2.0. The critical exception is any environment where the agent brokers access across tenants or handles sensitive user data, because a pod boundary cannot enforce user intent, and that is where cluster-only governance fails most visibly.

Related resources from NHI Mgmt Group

• When does AI agent access create more risk than it reduces?
• What is the difference between governing human access and governing AI agent access?
• Why is JIT access important for AI agent management?
• When does an AI agent become a privileged access problem?