AI Cloud Workload Identity Federation: Binding SPIFFE, OIDC, and STS Exchange Boundaries

Inference workers, offline evaluation, model conversion, and index building often access different object stores, queues, and KMS. If they share one long-lived cloud access key, the compromise of any single container escalates into platform-wide privileges. AI platform secrets rotation handles the credential lifecycle; this article further constrains "which workload declaration can be exchanged for which cloud privileges," without treating model outputs, request parameters, or tenant self-reported fields as identity.

Freeze the identity exchange contract

The identity source should give each workload a stable and fine-grained subject, such as spiffe://prod.example/ai/inference/worker, and separate production, staging, build, and manual tasks. A SPIFFE ID is a name; JWT-SVID, X.509-SVID, and cloud OIDC tokens are different credential types that cannot be covered by a single set of claim checks. Trust material and the Workload API socket are injected by the platform; business containers cannot choose their own validation profile.

The token broker implements cloud.exchange.v1 and explicitly separates three audiences: subjectTokenAudience is the audience the source token is minted for (the STS/broker); requestedAudience (or RFC 8693 resource) is the target the caller requests; issuedTokenAudience is the audience the broker writes into the final access token and that the resource service validates. The broker first selects a fixed subjectTokenProfile, then validates the source credential; it must not use the target API name to validate the source token's aud.

{
  "schema": "cloud.exchange.v1",
  "subjectTokenProfile": "prod-jwt-svid-v2",
  "subjectTokenAudience": "sts.prod.example",
  "requestedAudience": "model-store.prod.example",
  "requestedResource": "models/prod/model-42",
  "issuedTokenAudience": "model-store.prod.example",
  "purpose": "read-model",
  "taskId": "task_01J..."
}

The JWT-SVID profile fixes the trust domain/bundle, allowed SPIFFE subject, algorithm, subjectTokenAudience, time claims, and maximum lifetime, then verifies the signature per the SPIFFE JWT-SVID rules. X.509-SVID has no iss/aud/sub JWT claims; the broker should verify the certificate chain, the SPIFFE ID in the URI SAN, validity, and key usage, and use mTLS to prove private-key possession. The cloud OIDC profile fixes the issuer/JWKS, source audience, subject/attribute mapping, provider resource, and allowed roles to exchange. Any profile maps the requested target to a server-allowed set; the requested audience, resource, or scope can only narrow, never rewrite the subject or output audience.

This matches the separation of user, service, and tool identities in MCP Server authentication boundaries: user authorization can be a policy input, but it must not let a worker impersonate the user; tenant_id is obtained from the verified session and task record, not extracted from the prompt.

Bake the four bindings into policy

Federated identity policies match trust roots, subjects, source audiences, and environments by profile, then independently validate the requested target and output audience. Validating only the OIDC issuer lets test jobs from the same issuer reach production; matching only a SPIFFE ID prefix lets similar workloads escalate; confusing the three audiences hands a token issued to the logging system to STS. The claim/certificate-to-cloud-attribute mapping needs a version; unknown fields, empty subjects, wildcard environments, and normalization conflicts all default to deny.

Permissions are split into roles by purpose: inference can only read fixed model digests; builders can only write to staging; releasers can only switch approved aliases; evaluation jobs cannot decrypt production conversations. Downstream object stores and KMS still validate resource tags, tenants, or prefixes; you cannot abandon resource-layer authorization just because "STS already authenticated." Short-lived capability leases target a single tool action; the cloud token here only represents a controlled workload, and the two are not interchangeable.

The cache key includes profile, subject, the three audiences, resource, scope, policy version, and task/session, but this only prevents the broker from reusing by mistake; it cannot stop a stolen bearer token from being replayed. RFC 8693 itself provides no continuous binding or instant revocation. When the provider supports it, sender-constrained credentials should be issued: use RFC 8705 mTLS certificate binding, or use RFC 9449 DPoP to let the resource service verify cnf, the request URI/method, nonce, and proof for replay prevention; the private key stays in the task sidecar or hardware boundary.

If the provider only issues bearer tokens, the resource side should validate short-lived task/session fences, tenants, and resource conditions; where that is not possible, you can only rely on a few-minute TTL, process/network isolation, and minimal resource policies to shorten the risk window. Disabling a subject only stops new exchanges; bearer tokens already issued may still fire new requests before expiry, so you cannot claim it only allows existing calls to finish. Long-running tasks must re-exchange before expiry and must not fall back to a static key baked into the image.

Accept with a negative matrix, not just successful logins

Before going live, generate a fixed test matrix: swapping source and output audiences, switching the requested audience to staging, switching JWT-SVID to the X.509 profile, switching the OIDC issuer to a same-named test domain, expanding scope, and crossing resource boundaries must all fail. Copying a bearer, replaying a DPoP proof, swapping the mTLS client certificate, expired tokens, revoked signing keys, STS timeouts, and stale policy copies must also be covered; the system must not retry indefinitely or relax validation.

Hard gates include: zero static cloud keys; successful exchanges must correlate profile, workload, the three audiences, task, policy, and resource; error logs must not persist tokens. When sender binding or a resource fence is in place, cross-task calls with a stolen token must be zero; in pure bearer mode, the remaining exposure window from disablement to token expiry is measured explicitly, and after expiry successful calls must drop to zero. MCP audit logging design stores only irreversible fingerprints and reason codes.

Migration adopts dual-track observation: keep old credentials serving, while the new exchange chain only makes shadow decisions; once differences drop to zero, enable STS by stable workload buckets, and keep the old path unselectable by new instances. Rollback only switches the buckets back to the still-restricted old roles while preserving exchange audit; if an old static key is found leaked, rolling back to it is forbidden—instead pause the relevant tasks and re-issue controlled identities. Coding agent sandbox permissions still own file, command, and network boundaries; identity federation cannot replace runtime isolation.

The value of workload identity is not "going passwordless," but that every cloud privilege can answer who issued it, for which audience, mapped to which role, and how soon it expires, and you can use negative calls to prove that other combinations truly cannot get in.

Further reading

• AI platform secrets rotation
• MCP Server authentication boundaries
• Short-lived capability leases
• MCP audit logging design