Agents on Kubernetes

The five layers

An agent on Kubernetes can draw on five distinct layers of identity. They answer different questions, and a production deployment usually needs several at once. Pick a layer to see which parts of the cluster are involved.

The first four identify the workload: which pod, which service account, which certificate. Only the fifth identifies the person the workload is acting for. Treating a workload identity as if it were the user is the most common mistake in agent deployments, and the reason the last layer exists.

What ships in Kubernetes

The current stable release is v1.37 (August 2026); v1.38 is planned for December. Everything in the first group below is generally available in supported releases.

Two things are worth knowing about the newest entries. Kubernetes 1.37 ships the Pod Certificates API without a signer: you install one. And there is no built-in SPIFFE identity or token-exchange feature in Kubernetes itself; those come from projects layered on top.

A baseline pod

The settings that matter most cost nothing: a dedicated service account, no default API token, and a token minted for one specific audience.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: research-agent        # one per agent, never shared
  namespace: agents
automountServiceAccountToken: false
---
apiVersion: v1
kind: Pod
metadata:
  name: research-agent
  namespace: agents
spec:
  serviceAccountName: research-agent
  automountServiceAccountToken: false   # no Kubernetes API token unless needed
  containers:
    - name: agent
      image: registry.example/research-agent:1.4.2
      volumeMounts:
        - name: identity
          mountPath: /var/run/agent-identity
          readOnly: true
  volumes:
    - name: identity
      projected:
        sources:
          # A token for one consumer only. Read it fresh each time; it rotates.
          - serviceAccountToken:
              audience: https://sts.example
              expirationSeconds: 3600
              path: token
          # v1.37+: an X.509 identity from an installed signer
          - podCertificate:
              signerName: example.com/agent-identity
              keyType: ED25519
              credentialBundlePath: credentialbundle.pem
          - clusterTrustBundle:
              signerName: example.com/agent-identity
              path: trust-bundle.pem

One service account per agent. RBAC, federation trust rules and mesh policy all match on the service account. Two agents that share one are the same principal everywhere, and no downstream control can tell them apart.

Set the audience. The default pod token is addressed to the Kubernetes API server. Sending it anywhere else invites that system to replay it against your cluster. Ask for a separate token per consumer.

Verify the right way. An outside system checking the token against the cluster’s published keys learns that it is authentic and unexpired. It does not learn whether the pod still exists. Where that matters, the Kubernetes documentation says to use the TokenReview API.

Reaching the cloud

All three major clouds accept a pod’s ServiceAccount token in place of a stored key. The mechanics differ; the shape is the same as workload identity federation.

Whatever the platform, the trust rule should pin the issuer, the audience, and the exact subject (system:serviceaccount:<namespace>:<name>). Wildcards in the subject are how one compromised pod becomes every pod.

The same exchange works with your own authorization server. Several accept a Kubernetes ServiceAccount token as a client assertion, which gives an agent an OAuth client identity with nothing to store.

Workload-to-workload

For calls between an agent and tools you run, the usual answer is mutual TLS with SPIFFE identities. There are now three ways to get the certificates.

• A service mesh. Istio and others issue each workload a SPIFFE identity derived from its service account and handle mutual TLS for you. In Istio’s ambient mode this happens in a per-node proxy with no sidecar.
• SPIRE. A node agent attests each calling process and issues SPIFFE credentials over the Workload API. More to operate, and more control: identities can span clusters and clouds, and selectors can include the container image.
• Pod Certificates. New and native. The kubelet handles the key and rotation; you supply the signer. The SPIFFE project has published a specification for reading credentials from files that is designed around this.

Mutual TLS authenticates. It does not authorize. Pair it with policy that names which identities may call which endpoints, or every workload in the trust domain can reach every other.

Where a gateway terminates TLS between agent and tool, the certificate does not arrive. That gap is what workload identity tokens with proof of possession are being standardized to close.

Gateways and policy

Much of what this site describes can be enforced at a proxy, without touching agent code. That is attractive when agents are built by many teams on many frameworks.

• agentgateway is an open-source proxy for model, MCP and agent-to-agent traffic. It can act as the OAuth resource server for MCP, apply per-tool rules or ask an external policy engine through AuthZEN, perform token exchange and the enterprise ID-JAG flow on the agent’s behalf, and run as an egress proxy. Istio can use it as a gateway or ambient waypoint, though that integration is marked experimental.
• Agent Router, the project formerly called Envoy AI Gateway, offers MCP routes with OAuth validation, claim-based authorization and per-backend credential injection.
• Kube Agentic Networking, a SIG Network subproject, is defining Kubernetes APIs for agent traffic policy, including tool-level MCP authorization and SPIFFE-based agent identity. Early releases only.
• A Kubernetes AI Gateway working group has proposed standardizing egress gateways with managed authentication and token injection for third-party AI APIs. Nothing has shipped.

A gateway controls only the traffic that passes through it. Add a NetworkPolicy that denies all other egress from agent pods, including the cloud metadata address, or the control is advisory.

Sandboxed agents

Agent Sandbox is a SIG Apps project that adds a Sandbox resource: an isolated, stateful, single-pod runtime for an agent, with templates, claims and pre-warmed pools. The project is at version 1.0, with an API still labeled v1beta1.

Its defaults are a good statement of what an agent pod should look like. Sandboxes created from a template do not mount a ServiceAccount token, and get a generated NetworkPolicy that allows the public internet while blocking private address ranges and cloud metadata endpoints. Isolation itself is delegated to a sandboxed container runtime such as gVisor or Kata.

It has no built-in credential broker. Credentials reach a sandbox the way they reach any pod, which for an agent executing untrusted code means you should bring your own: see sandboxes.

Checklist

• Each agent has its own ServiceAccount and namespace-scoped RBAC, or no Kubernetes API access at all.
• The default token is not mounted. Projected tokens name a specific audience.
• No long-lived API keys in Secrets where federation is available.
• Federation trust rules pin issuer, audience and exact subject.
• Agent pods can reach the network only through a gateway or egress proxy.
• Workload-to-workload calls use mutual TLS with an explicit allow policy.
• User delegation travels as its own token and is exchanged at each hop, never forwarded.
• An admission policy enforces the above, so a new agent cannot quietly skip it.