Deployments
Where the agent runs decides where its identity comes from
The flows are the same everywhere. What changes with the runtime is the starting credential: what the platform can vouch for, where a secret could safely live, and who can see the agent’s traffic.
Kubernetes
Five layers of identity for an agent pod: ServiceAccount tokens, federation, certificates and SPIFFE, gateways, and user delegation. With an interactive map.
Managed agent platforms
What cloud and identity vendors now offer for agents: per-agent identities, token vaults, on-behalf-of exchange, and administrator-controlled access.
Desktop, IDE, CLI and CI
Agents on a person’s machine are public clients. Agents in a pipeline have a platform identity. Neither should carry a pasted API key.
Sandboxes
For agents that run untrusted code: keep credentials outside the sandbox and inject them at the network edge.
Side by side
The same four questions asked of each runtime.
| Runtime | The agent’s own identity | Acting for a user | Where secrets live | Main risk |
|---|---|---|---|---|
| Kubernetes | ServiceAccount token, pod certificate or SPIFFE ID | Token exchange at a gateway or in the agent | With federation, none long-lived; otherwise a Secret | Shared service accounts; loose federation trust rules |
| Managed platform | A platform-issued agent identity | The platform’s token vault and exchange | In the platform’s vault | Opaque defaults; knowing what the platform can do as your agent |
| Desktop, IDE, CLI | None of its own: a public OAuth client | Authorization code with PKCE, as the signed-in user | Operating system keychain | Tokens on disk; any local process can claim a localhost redirect |
| CI pipeline | The CI system’s OIDC token for the job | Usually none: the job acts as itself | With federation, none long-lived | Trust rules that match more repositories or branches than intended |
| Sandbox | Whatever the host gives it, ideally nothing reusable | Held outside; injected per request | Outside the sandbox | Misuse of access while the sandbox runs |
A pattern across all of them
In every runtime the strongest option is the one where the platform attests to the agent and nothing long-lived is stored: a projected token, a job’s OIDC token, a platform-issued agent identity. Where that is not available, the next best is a secret the agent can use but cannot read.