Summary
We'd like to extend spire-identity-exchange (SIX) to support agentic identity — credentials that prove a specific AI agent is acting on behalf of a specific user, so downstream services can authorize, audit, and revoke at agent + user granularity rather than collapsing both into one identity.
The standard for this is RFC 8693 OAuth Token Exchange: subject_token (user) + actor (agent) → JWT with sub=user, act={sub=agent}.
Landing an act claim in a SPIRE-signed JWT-SVID likely requires a small extension to SPIRE Server's JWT-SVID issuance path. There may be additional gaps we haven't surfaced.
The problem
AI agents acting on behalf of users need a credential that downstream services can verify in one step and that carries both identities distinctly:
- Who the request is for — the user (
sub)
- Who is doing the acting — the agent (
act.sub)
Without this, every agent call collapses to a single identity. Resource servers can't tell whether agent A or agent B is operating.
Today, neither SPIFFE nor SPIRE has primitives for expressing this in an SVID. The JWT-SVID claim set is iss, sub, aud, exp, iat; there's no act claim and no way to inject one through MintJWTSVID or NewJWTSVID. The OSS ecosystem has no token-exchange service equivalent to what's standardized in RFC 8693.
We have visibility into at least one production implementation of this pattern (an internal token service at one organization) that operates as:
subject_token (user OIDC JWT) + mTLS SPIFFE workload cert (agent) → signed JWT with sub=user, act={sub=agent}
Where we need SPIRE support
Two viable paths — both keep SPIRE Server as the signer.
Option A — Path-encoded SPIFFE ID
Encode both identities into the SPIFFE ID path:
sub = spiffe://corp/delegation/user/alice/agent/ai-agent-svc
|
|
| SPIRE-side change |
none |
| Compromises |
Not RFC 8693 shape — off-the-shelf act-aware verifiers don't work |
|
Multi-hop becomes unwieldy (…/agent/A/agent/B/agent/C) |
|
No may_act path for delegation pre-authorization |
|
Per-actor revocation requires regex on sub |
|
Audit + policy engines must parse a private path convention |
Option B — SPIRE Server gains controlled custom-claim support (preferred)
SPIRE Server JWT-SVID issuance gains the ability to thread a gated act claim into the signed token, with authorization so callers can't forge arbitrary claims.
|
|
| SPIRE-side capability |
inject a controlled act claim into a JWT-SVID, gated by entry- or admin-level authz |
| Touches |
MintJWTSVID / NewJWTSVID API surface, internal claim builder, validator |
| Spec change |
small SPIFFE-spec amendment defining act semantics for JWT-SVIDs (chain shape, depth, verification) |
| Result |
standard RFC 8693 act chain in a SPIRE-signed JWT-SVID — one issuer, one verifier path, one spec-defined claim |
Why Option B: Option A works but bakes a private convention into the trust domain forever. Option B keeps delegation tokens as first-class SPIFFE credentials.
Summary
We'd like to extend
spire-identity-exchange(SIX) to support agentic identity — credentials that prove a specific AI agent is acting on behalf of a specific user, so downstream services can authorize, audit, and revoke at agent + user granularity rather than collapsing both into one identity.The standard for this is RFC 8693 OAuth Token Exchange:
subject_token(user) + actor (agent) → JWT withsub=user, act={sub=agent}.Landing an
actclaim in a SPIRE-signed JWT-SVID likely requires a small extension to SPIRE Server's JWT-SVID issuance path. There may be additional gaps we haven't surfaced.The problem
AI agents acting on behalf of users need a credential that downstream services can verify in one step and that carries both identities distinctly:
sub)act.sub)Without this, every agent call collapses to a single identity. Resource servers can't tell whether agent A or agent B is operating.
Today, neither SPIFFE nor SPIRE has primitives for expressing this in an SVID. The JWT-SVID claim set is
iss, sub, aud, exp, iat; there's noactclaim and no way to inject one throughMintJWTSVIDorNewJWTSVID. The OSS ecosystem has no token-exchange service equivalent to what's standardized in RFC 8693.We have visibility into at least one production implementation of this pattern (an internal token service at one organization) that operates as:
Where we need SPIRE support
Two viable paths — both keep SPIRE Server as the signer.
Option A — Path-encoded SPIFFE ID
Encode both identities into the SPIFFE ID path:
act-aware verifiers don't work…/agent/A/agent/B/agent/C)may_actpath for delegation pre-authorizationsubOption B — SPIRE Server gains controlled custom-claim support (preferred)
SPIRE Server JWT-SVID issuance gains the ability to thread a gated
actclaim into the signed token, with authorization so callers can't forge arbitrary claims.actclaim into a JWT-SVID, gated by entry- or admin-level authzMintJWTSVID/NewJWTSVIDAPI surface, internal claim builder, validatoractsemantics for JWT-SVIDs (chain shape, depth, verification)actchain in a SPIRE-signed JWT-SVID — one issuer, one verifier path, one spec-defined claimWhy Option B: Option A works but bakes a private convention into the trust domain forever. Option B keeps delegation tokens as first-class SPIFFE credentials.