Agent Flows

AI Agent Auth — End-to-End Delegation Chain

A complete agentic authorization flow illustrating the composition of standards recommended by draft-klrc-aiagent-auth-00 ("AI Agent Authentication and Authorization"). KLRC itself is a framework draft — it composes WIMSE, OAuth 2.0, RFC 8693 token exchange, and the txn-tokens draft rather than defining new claim names or token typ values. In this scenario the orchestrator bootstraps a WIMSE workload identity (SPIFFE SVID → WIT), a user delegates authority via token exchange, the orchestrator mints a short-lived transaction token for a sub-agent, and the sub-agent calls an MCP server using its delegated token plus a WIMSE Workload Proof Token (WPT) as proof-of-possession.

draft-klrc-aiagent-auth-00 WIMSE Identity & Auth RFC 8693 Token Exchange Txn-Tokens (draft)RFC 7523 JWT Bearer Grant

POST unix:///run/spire/sockets/agent.sock — /SpiffeWorkloadAPI/FetchX509SVID (server-streaming RPC)200

The orchestrator bootstraps its cryptographic identity via the SPIFFE Workload API (a local Unix socket served by the SPIRE Agent). SPIRE uses two independent attestation phases: node attestation establishes trust between the SPIRE Agent pod and the SPIRE Server (using the SPIRE Agent's own service account token — not the orchestrator's); workload attestation then identifies the specific orchestrator process calling the socket using OS kernel attributes (cgroup, UID, pod labels). The resulting X.509 SVID cryptographically proves the orchestrator is the registered workload spiffe://example.org/agents/orchestrator-5fa3b.

• The Workload API is gRPC over Unix-domain socket, not REST. Methods: FetchX509SVID, FetchX509Bundles, FetchJWTSVID, FetchJWTBundles, ValidateJWTSVID. Responses are protobuf, not JSON; bytes fields (x509_svid, x509_svid_key, bundle) are DER-encoded.

• Every call MUST include the gRPC metadata 'workload.spiffe.io: true' (case-sensitive) per the SPIFFE Workload Endpoint spec — an anti-SSRF guard. Requests missing this header are rejected with gRPC InvalidArgument and clients SHOULD NOT retry.

• The private key for the SVID is generated on-node and never transmitted — only the certificate (signed SPIFFE ID) is returned.

• SVIDs have short TTLs (default: 1 hour) and are auto-rotated by the SPIRE Agent before expiry.

• The Unix socket limits access to processes on the same host — no network exposure of the Workload API.

• The same Workload API also exposes SpiffeWorkloadAPI/FetchJWTSVID(audience=...) — the orchestrator calls this in the next step to obtain a JWT-SVID for use as an RFC 7523 client assertion to the AS.

• KLRC §6 (Agent Credentials) and §7 (Agent Attestation) require attestation-backed credentials cryptographically bound to the agent identifier — static API keys are called out as an anti-pattern. KLRC composes the WIMSE/SPIFFE machinery shown here rather than defining its own attestation protocol.

1 / 9

speed

Step 1: gRPC SpiffeWorkloadAPI/FetchX509SVID

Request / response

POSTunix:///run/spire/sockets/agent.sock — /SpiffeWorkloadAPI/FetchX509SVID (server-streaming RPC)

:method

POST

:scheme

http

:path

/SpiffeWorkloadAPI/FetchX509SVID

content-type

application/grpc

trailers

workload.spiffe.io

true

Body

{
  "_comment": "Empty protobuf message: X509SVIDRequest {}"
}

Cryptographic Signature

Construction Steps

1. 1. Node Attestation (SPIRE Agent → SPIRE Server)

Node attestation establishes trust between the SPIRE Agent and the SPIRE Server — it has nothing to do with the orchestrator workload yet.

The SPIRE Agent pod mounts its own Projected Service Account Token (a token bound to the spire-agent Kubernetes service account, not any workload SA). It presents this token to the SPIRE Server, which calls the Kubernetes TokenReview API to confirm the SPIRE Agent pod is legitimately running inside the cluster. On success, the SPIRE Server registers this agent as a trusted node.

Note: in Kubernetes, 'node' in SPIRE terminology means the SPIRE Agent pod itself — not a physical Kubernetes worker node.

2. 2. Workload Attestation (Orchestrator process → SPIRE Agent)

This is a completely separate step from node attestation. When the orchestrator process calls the Workload API (Unix socket), the SPIRE Agent uses OS kernel attributes to determine which workload is calling:

• Process UID (e.g., uid=1000)
• cgroup path (e.g., /kubepods/burstable/pod.../container...)
• Kubernetes pod labels (app=orchestrator, version=v2)

The SPIRE Agent matches these against its registered workload entries. If a match is found, it confirms the caller is the registered 'orchestrator' workload and proceeds to issue an SVID for it.

3. 3. SVID Issuance

SPIRE Server mints an X.509-SVID: a short-lived certificate with SubjectAlternativeName URI = spiffe://example.org/agents/orchestrator-5fa3b. The private key was generated locally by the SPIRE Agent and never leaves the node.

4. 4. Resulting SPIFFE ID

spiffe://example.org/agents/orchestrator-5fa3b

This stable URI is the orchestrator's cryptographic identity for all subsequent interactions. It will appear as the subject or actor in every token in this flow.

Signature Base String

Node Attestation: SPIRE Agent k8s-psat (spire-agent SA) → Workload Attestation: cgroup + UID + pod labels → SVID issued

Signing Key

SPIRE Server CA (X.509, trust domain: example.org)

Signature Output

spiffe://example.org/agents/orchestrator-5fa3b