5 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.

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. 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.
  2. kagent 0.10 Ships Audience-Bound Agent Tokens, Off By Default
    — 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.
  3. MCP Agent Identity: One Spec Shipped, Three Still Open
    — The MCP roadmap names four agent identity workstreams. One has shipped, and it authenticates the employee behind the agent rather than the agent itself.
  4. SPIFFE Workload Identity for AI Agents, End to End
    — 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.
  5. Your AI Agent Should Not Hold the LLM API Key
    — The LiteLLM PyPI compromise stole exactly where LLM API keys live. A working agentgateway demo: agents that call LLMs holding no provider credential at all.

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.