Workload Identity for AI Agents: SPIFFE, Token Exchange, and Ephemeral Credentials
By Kehinde Ogunlowo ·
Workload Identity for AI Agents: SPIFFE, Token Exchange, and Ephemeral Credentials
Ask an engineering team how their AI agent authenticates to the systems it acts on, and the honest answer is usually some variant of "a service account with an API key in the environment." That answer was tolerable for a cron job. It is not tolerable for a process that ingests untrusted input and decides at runtime which APIs to call. An agent is the first category of workload where the software's behavior is partially authored by whatever text it reads — which means its credentials need to be designed on the assumption that the process holding them can be talked into misusing them.
This post covers the workload identity stack that fits agents: platform attestation with SPIFFE/SPIRE, OAuth 2.0 Token Exchange (RFC 8693) for carrying user context, and scoped ephemeral credentials issued per task. First, though, it is worth being precise about why the service-account pattern breaks down.
Why Service Accounts Fail for Agents
The traditional service account fails on four separate axes when the workload is an agent:
1. Static lifetime meets untrusted input. A long-lived key held by an agent is exposed to a threat class ordinary services do not face: prompt injection. Retrieved documents, web pages, and user messages are all attacker-reachable channels into the agent's context. The defense is not only better filtering — it is ensuring that even a fully compromised agent process holds credentials worth very little for very long. A key that expires in five minutes and is scoped to one operation converts a catastrophic leak into a contained one.
2. One identity, many behaviors. Service accounts are typically shared — across agent instances, across environments, sometimes across entirely different systems "temporarily." When the audit question arrives ("which agent, acting for which user, made this call?"), a shared principal cannot answer it. Agent actions become an undifferentiated blob attributed to svc-ai-prod.
3. Standing privilege versus per-task need. A service account accumulates the union of every permission the workload has ever needed. An agent that occasionally files tickets and occasionally reads billing data ends up with standing access to both, on every task, forever. The agent's actual need is narrow and momentary: this task requires read access to these three records for the next two minutes. Static grants cannot express that.
4. No user context. Most agent actions happen on behalf of someone. A service account authorizes the agent's identity or the user's — not the conjunction. The result is the classic confused-deputy problem: an agent with broad read access, prompted by a low-privilege user, happily retrieves documents that user could never access directly. Correct authorization needs both identities present at the point of decision, which is precisely what the token-exchange pattern below provides.
None of this is exotic. It is the standard zero trust critique of static credentials — covered more broadly in zero trust for AI — applied to a workload that maximizes every one of its weaknesses.
Layer 1: Attested Identity with SPIFFE/SPIRE
The foundation is answering "what is this process?" cryptographically rather than by possession of a secret. SPIFFE (Secure Production Identity Framework for Everyone) defines the identity format; SPIRE is its production implementation, a CNCF-graduated project.
The moving parts:
- Every workload gets a SPIFFE ID — a URI like
spiffe://prod.example.com/agent/ar-collections/instance-7within your trust domain - A SPIRE agent runs on each node and verifies workloads through attestation: node attestation proves what machine/instance is asking (via the cloud provider's instance identity documents, Kubernetes tokens, or TPM evidence), and workload attestation proves which process on that node is asking (via selectors like Kubernetes service account, container image, binary hash)
- Workloads that pass attestation receive an SVID (SPIFFE Verifiable Identity Document) — an X.509 certificate or a JWT — that is short-lived and automatically rotated
The property that matters for agents: identity is derived from what the platform observes, not from a secret the workload stores. There is no API key to leak into a log, paste into a prompt, or exfiltrate via injection, because the bootstrap credential is the attested runtime itself. The SVID the agent holds at any moment expires on the order of minutes to hours and renews transparently.
For agent fleets this also solves the instance-identity problem cleanly: each agent instance can carry its own SPIFFE ID under a common path, so audit logs distinguish instance-7 from instance-12 while policy can still target agent/ar-collections/*.
Layer 2: User Context with OAuth Token Exchange (RFC 8693)
Attestation establishes what the agent is. It says nothing about who the agent is acting for. That is the job of OAuth 2.0 Token Exchange, standardized in RFC 8693.
The flow, concretely:
- A user's request arrives at the agent carrying the user's token (a
subject_tokenin RFC 8693 terms) - The agent authenticates to the authorization server as itself — using its SVID, so agent authentication rides on attestation rather than a client secret
- The agent requests an exchange: subject token in, plus its own actor identity, plus the specific audience and scope it needs for the immediate operation
- The authorization server applies policy — is this agent allowed to act for this user against this resource? — and issues a new token, typically with an
act(actor) claim recording the delegation chain: user X, via agent Y - The downstream resource authorizes against both identities and sees the full chain in its logs
This kills the confused deputy directly. The document store no longer sees "the agent, which can read everything"; it sees "agent Y acting for user X," and enforces X's entitlements. It also produces the audit answer security reviewers ask for — every downstream log line carries the delegation chain, not a bare service principal. The delegation patterns emerging for multi-step and multi-agent systems build on exactly this primitive, chaining act claims as work passes between components.
Where the systems an agent calls are not OAuth-aware — legacy internal APIs, databases — the same principle applies through a credential broker: the agent presents its SVID plus the user context, and the broker issues narrowly scoped, short-lived database credentials or signed URLs. Cloud-native equivalents (AWS role assumption with session policies and tags, GCP service account impersonation with credential access boundaries, Azure managed identity federation) let you express "this identity, these resources, this hour" without minting long-lived keys.
Layer 3: Scope Discipline — Credentials Per Task, Not Per Agent
The third layer is policy shape: even with attestation and exchange in place, it is tempting to request broad scopes "to reduce round trips." Resist it. The unit of credential issuance for an agent should be the task, and the scope should be the minimum the task's next step requires:
- A ticket-summarization task gets
tickets:readfor the specific project, not org-wide - A refund proposal task gets scope to read the payment record; the write scope is issued only after the human approval gate clears, to the gateway executing the approved action — the agent process itself never holds it
- Long multi-step tasks re-exchange as they go rather than front-loading a super-token
This pairing of ephemeral credentials with autonomy gating is deliberate: the approval systems described in the governed AI agents pattern only provide real protection when the agent cannot execute the gated action out-of-band. Scoped issuance is what makes the gate load-bearing. The same discipline shortens enterprise security review substantially — the credential-handling section of AI agent security review checklists becomes a description of the broker rather than an inventory of exceptions.
Practical scoping guidance:
- Bind tokens to audience. A token minted for the ticketing API must be rejected by the billing API. RFC 8693's
audience/resourceparameters exist for this; use them on every exchange. - Keep lifetimes near task duration. Minutes, not days. If a task legitimately runs for hours, renew rather than extend.
- Sender-constrain where supported. mTLS-bound tokens (RFC 8705) or DPoP make a stolen token useless without the agent's attested key, closing the replay gap.
- Centralize issuance, centralize revocation. One broker issuing everything means one place to see every live grant and one switch to cut an agent off — the credential-revocation layer of the kill-switch story every reviewer asks about.
What This Looks Like Assembled
[User request + user token]
|
v
[Agent instance] --(attestation)--> [SPIRE] --> SVID (auto-rotating)
|
|-- RFC 8693 exchange: subject=user, actor=agent(SVID),
| audience=target API, scope=task minimum
v
[Authorization server / credential broker]
|-- policy: may this agent act for this user on this resource?
v
[Short-lived, audience-bound token with act claim]
|
v
[Target API] -- authorizes user AND agent, logs full chain
Adoption does not require doing everything at once. A workable sequence: (1) give each agent a distinct identity — even distinct cloud service accounts per agent is a strict improvement over shared ones; (2) move issuance behind a broker and shorten lifetimes; (3) add attestation via SPIRE or your platform's native workload identity federation; (4) introduce RFC 8693 exchange for user context on the highest-risk tools first. Each step is independently valuable, and each one converts a finding in your next security review into a strength.
The uncomfortable truth about agent security is that model-level defenses — better prompts, better filters — are probabilistic, while identity architecture is deterministic. You cannot guarantee an agent will never be talked into attempting something it should not. You can guarantee that when it tries, it is holding a credential that cannot do it.
Where to Go From Here
The Enterprise AI Agent Blueprint is a free governance guide covering the identity, credential, and audit architecture in this post alongside the autonomy-tier controls it enforces — enter a work email and it is sent immediately. To talk through retrofitting workload identity onto an existing agent deployment, book a call.