9 posts in this series //

Agent Identity on Kubernetes: The Complete Series

How an AI agent proves who it is: workload identity federation, SPIFFE SVIDs, OAuth token exchange, RFC 8707 audience binding, and what the MCP spec does and does not cover yet.

An AI agent that calls a model, a tool, or another agent has to prove who it is. Almost every production failure I have written up this month traces back to that one question being answered badly, or being answered for the wrong party.

This series works the problem from the bottom up: what the protocol specs actually define, what the platform can issue underneath them, and where the gap between the two has to be filled by a gateway.

The short version

The agent should hold nothing. Every credential an agent stores is a credential that leaks when the agent is compromised, and agents are compromised through their tool surface, not their login page. The pattern that holds up is: the agent presents an identity the platform already gave it, and something on the call path exchanges that identity for a short-lived, audience-bound token.

The spec layer is behind the platform layer. MCP’s roadmap names agent identity as a priority workstream, but the only stable piece authenticates the employee behind the agent, not the agent. If you are shipping this quarter, the workload identity you need exists — just one layer down, in SPIFFE, in Kubernetes projected tokens, and in gateway-mediated token exchange.

Audience binding is the control people skip. A token that names no audience is replayable against every backend sharing an issuer. RFC 8707 fixes that, and the implementations that support it tend to ship with it switched off.

How to read these

Start with the MCP agent identity gap if you want to know what the protocol does and does not promise you. Start with secretless agents if you want a working demo first and the spec argument later. Start with SPIFFE workload identity for AI agents if you want attested identity with no secret on disk.

The posts below are listed newest first. They are independent; none assumes you read the others, but they were written against one running argument, and the audience-binding and token-service posts are the most directly operational of the set.

Every post in this series

  1. Per-Request Minted JWTs for Agent Backends with agentgateway
    — agentgateway v1.5 signs a fresh 15-second JWT on every request, so an AI agent reaches its backend holding no key. Claims, expiry, and a failed replay, tested.
  2. Do AI Agents Need SPIFFE or OAuth?
    — SPIFFE proves which agent process is calling; OAuth scopes what it may do and for whom. When each is enough, and when production agents need both.
  3. Building Workload Identity Federation for AI Agents on Kubernetes
    — How an AI agent pod trades a Kubernetes service account token for a resource-scoped credential, with no shared secret and no long-lived key in the pod.
  4. agentgateway CEL Gotchas: Fail-Open + 403 Fix
    — agentgateway matchExpressions are OR'ed, so two rules fail open; llm.requestModel is empty at the traffic phase, so every call 403s. The working policy.
  5. The agentgateway Token Service Now Runs Without a Cluster
    — agentgateway enterprise 2026.9.0 ships its token service as a standalone binary on a public bucket, so a gateway-mediated agent identity setup fits on a laptop.
  6. kagent Audience-Bound Tokens (RFC 8707)
    — kagent v0.10.0 GA can bind an agent's exchanged token to one backend using RFC 8707 resource indicators. Two environment variables, both empty by default.
  7. MCP Agent Identity: What Shipped, What to Use
    — MCP has one shipped identity spec, and it authenticates the employee, not the agent. DPoP and Workload Identity Federation are still open. What to use now.
  8. SPIFFE for AI Agents: End-to-End Identity Demo
    — An agentgateway v1.5.0 demo where the agent, the gateway, and the model upstream all authenticate with SPIFFE SVIDs and no certificate file exists anywhere.
  9. Your AI Agent Should Not Hold the LLM API Key
    — How an AI agent calls an LLM with no API key in its env, disk, or process: short-lived identity at agentgateway, provider key attached at the gateway.

Frequently asked questions

What is workload identity federation for AI agents?

Workload identity federation lets a workload exchange a platform-issued credential it already has, such as a Kubernetes service account token, for a token from another trust domain, without any long-lived secret being stored. For an AI agent it means the agent authenticates as itself to an identity provider, receives a short-lived token scoped to one backend, and holds no provider API key. The federation step is where organizational policy gets evaluated, which is what makes access centrally revocable.

How does an AI agent authenticate without storing an API key?

The agent presents an identity it already holds from the platform, and something on the call path exchanges that identity for a credential the upstream will accept. In practice this is a Kubernetes projected service account token, a SPIFFE SVID from a workload API, or an OAuth token exchange performed by a gateway. The provider key lives in the gateway or token service, never in the agent process, so compromising the agent yields no reusable secret.

Does the Model Context Protocol define agent identity?

Not for the agent itself. The MCP auth extensions repo ships one stable specification, Enterprise-Managed Authorization, which authenticates the human employee through a corporate IdP using an ID-JAG grant. The two proposals that would give a workload its own verifiable identity, DPoP (SEP-1932) and Workload Identity Federation (SEP-1933), are still open pull requests. Short-lived workload identity is available a layer down instead, at the gateway or service mesh.

What is RFC 8707 audience binding and why does it matter for agents?

RFC 8707 resource indicators let a client name the specific backend a token is meant for, so the authorization server can bind the issued token to that audience. Without it, a token minted for one backend is replayable against every other backend that trusts the same issuer. For agents this is the difference between a compromised tool call reaching one service and reaching all of them. kagent 0.10 supports it through two environment variables, and both default to empty.