The runtime gap
The first four articles in this series established a clean issuance model: SPIFFE for workload identity, OAuth SPIFFE Client Authentication for authentication to your authorization server, Token Exchange for delegation, Transaction Tokens for context propagation through the call chain. By the time a request reaches a downstream API, the credential is short-lived, cryptographically attested, and carries the full context of who the user is, which agent is acting, and what transaction is in flight.
Then something goes wrong.
The user’s account is compromised — credential stuffing, phishing, an internal account takeover. The agent goes off the rails — prompt injection, a tool exploit, an LLM provider issue. The agent platform itself is breached. A signal arrives at your IdP, your SOC, your fraud team, your DLP system. The right response is to immediately revoke the agent’s access — kill its tokens, halt in-flight transactions, prevent any further damage.
Your OAuth access tokens have a 60-minute lifetime. Your Txn-Tokens have a 90-second lifetime. The damage will be done long before either expires.
This is the runtime gap. The piece that “agents are workloads” doesn’t solve on its own — and the piece where standards work has been quietly catching up for years, ready to deploy now.
The two specifications that close this gap are the OpenID Foundation’s Shared Signals Framework (SSF) and its Continuous Access Evaluation Protocol (CAEP) profile. The deployment mechanism is the API gateway, which sits in the path between agents and downstream services and can enforce revocation at line rate. This article covers the standards, the deployment pattern, the relationship between dynamic authorization and policy-based access control, and the emerging federation story between LLM platforms and enterprise trust domains.
Shared Signals Framework: the protocol for telling each other what happened
The Shared Signals Framework, published as an OpenID Foundation specification, defines a standard way for security and identity systems to exchange information about events that affect access decisions. It’s the substrate for two profiles:
- CAEP — Continuous Access Evaluation Protocol — for events that affect ongoing sessions and credentials (session revoked, credential change, token claims change, assurance level change, device compliance change)
- RISC — Risk and Incident Sharing and Coordination — for events that affect account state (account credential change, account purged, account disabled, identifier change)
A Shared Signals event is a Security Event Token (SET) per RFC 8417 — a JWT-formatted, signed statement of an event with a defined schema. A typical CAEP session-revoked event:
The IdP — or any authorized signal source — publishes this event, and any receiver that has registered for events about this subject gets notified in near real time. The receiver decides what to do: typically, revoke any active sessions for the named subject, refuse to issue new tokens, and propagate the signal to downstream systems that may also need to act.
The transport is HTTP-based. SSF supports both push (the transmitter POSTs events to the receiver’s endpoint) and poll (the receiver pulls from the transmitter’s endpoint) modes. Both are appropriate for different deployment patterns; high-volume environments often use push for low latency.
What CAEP gives you for agents specifically
For agentic systems, the CAEP signals that matter most are:
- session-revoked — the named user’s session has been revoked. All agents acting on that user’s behalf should immediately lose access.
- token-claims-change — claims that an access token relied on have changed. Tokens carrying the old claims should be treated as suspect.
- credential-change — the user’s credential has changed (password reset, MFA reset, account recovery). Tokens issued under the old credential should be revoked.
- assurance-level-change — the assurance level associated with the session has changed (e.g., dropped from MFA to single-factor). Operations requiring higher assurance should be blocked.
- device-compliance-change — the device the session was established from is no longer compliant (jailbroken, out of policy, marked stolen). Tokens from that device should lose privileges or be revoked outright.
A subtle but important point: CAEP events name the subject (the user), not specific tokens. The receiver is responsible for mapping the subject to the active tokens and sessions in its inventory. For an API gateway, this means maintaining a session-to-token mapping that can be queried by subject ID; for an authorization server, it means tracking issued tokens that are subject to revocation.
For agentic deployments, an additional signal pattern is worth designing for: the agent platform itself becoming a signal source. If your agent runtime detects anomalous behavior — repeated failed tool invocations, unexpected privilege escalation attempts, output that triggers DLP — the runtime can emit a CAEP signal scoped to the specific agent (or agent class) and propagate it to gateways and authorization servers. This is the runtime feedback loop that turns “we have an agent identity” into “we can take an agent out of service in seconds.”
The gateway as the enforcement point
Standards define how signals flow. Implementations need an enforcement point. For modern API-fronted architectures — which is to say, basically all agentic architectures — the API gateway is the natural place to enforce revocation.
The deployment pattern: the gateway maintains a real-time session/token state, subscribes to CAEP signals from the relevant identity providers and authorization servers, and on receipt of a revocation signal immediately invalidates any tokens or sessions for the named subject. New requests presenting revoked tokens are rejected at the gateway, never reaching the backend. In-flight requests are typically allowed to complete (they’re already past the gateway), but subsequent requests in the same session are blocked.
The architectural properties this gets you:
Mid-flight revocation. A rogue agent’s access can be killed in seconds. A CAEP signal arrives at the gateway, the gateway invalidates the session, the next API call from the agent is rejected. The 60-minute OAuth access token lifetime becomes operationally irrelevant — the gateway doesn’t care that the token would be valid on its face, because the gateway has been told to treat the session as revoked.
Centralized policy enforcement. Rather than scattering revocation logic across every backend service, you concentrate it at the gateway. Backend services don’t need to subscribe to CAEP; they just trust that any request reaching them through the gateway has been validated against current state.
Audit consolidation. The gateway is also the natural place to log revocation events and their effects. Every blocked request, every revoked session, every CAEP signal received and acted on flows through the same observability pipeline.
Layered defense. Even if a backend service has stale state, the gateway has fresh state. Even if the agent’s local OAuth library is happily handing out a valid access token, the gateway is the one that decides whether to honor it.
The gateway is the “deploy this today” piece. Modern API gateways — Kong, Istio with appropriate filters, AWS API Gateway with custom authorizers, Apigee, Azure API Management — can all be wired to consume CAEP signals. The OpenID Foundation maintains a registry of certified Shared Signals implementations, and adoption is rising.
Why dynamic authorization changes the policy model
Static OAuth scopes — read:users, write:invoices, admin:billing — work fine when the access decisions are coarse-grained and don’t change after token issuance. They break for agentic systems where the decisions need to be context-aware (“this agent can read invoices, but only for the user who delegated to it, only during this session, only when the user’s assurance level is MFA-strong”) and dynamic (those conditions can change at any moment).
The pattern that’s emerging is Policy-Based Access Control (PBAC), enforced at the gateway, fed by:
- The token (user identity, agent identity, scopes, the Txn-Token’s transaction context)
- The session state (current assurance level, device compliance, recent CAEP signals)
- The request context (what is the agent trying to do, on which resource, with which parameters)
- External signals (DLP, fraud, threat intelligence, the agent runtime’s own self-monitoring)
A policy engine (OPA, Cedar, AWS Verified Permissions, Styra DAS, a custom implementation, etc.) evaluates these inputs against policy rules at request time. The policy is the authoritative source of “is this request allowed right now,” not the token’s static scopes.
instance-level governance does not scale. You cannot maintain a static authorization policy that explicitly enumerates every agent instance. Agents come and go, by the hundred per day. The only tractable governance pattern is to define policy in terms of attributes (agent role, agent class, user attributes, request attributes) and let the policy engine apply those rules to whatever instances exist at the moment of evaluation.
This is the bridge between identity (who is asking) and authorization (should they be allowed). The identity layer answers the first question precisely thanks to SPIFFE + OAuth + Txn-Tokens. The policy layer answers the second by combining the identity with everything else known about the moment of the request.
Federation: when the agent is provisioned by someone else
The model gets more interesting when the agent isn’t yours. If Anthropic provisions an agent that needs to act inside your trust domain on behalf of one of your users, the agent has an identity in Anthropic’s trust domain, not yours. The same question applies to Google Agent ID, Microsoft Copilot extensions, and an expanding list of vendor agent platforms.
Both Anthropic and Google have already made their agent identities federation-compatible — issuing workload identity tokens that other organizations’ authorization servers can consume, publishing the necessary trust bundles and metadata, defining audience and scope conventions that align with OAuth and OIDC.
The architectural pattern:
- Cross-domain trust establishment. Your authorization server is configured to trust the agent platform’s trust domain. This typically involves exchanging Bundle Endpoint URLs (for SPIFFE-style identity) or registering the platform’s JWKS endpoint (for plain OIDC-style identity).
- Identity Chaining at the boundary. When an agent from the external trust domain makes a call into your trust domain, your gateway accepts the agent’s incoming credential (its workload identity token, signed by the platform’s trust domain), validates it, and exchanges it for a domain-internal credential — typically a Txn-Token carrying both the user’s identity (federated through the platform) and the agent’s identity (from the platform).
- Policy at the boundary. Your policy engine applies your trust domain’s rules to the federated request. The fact that the agent comes from an external platform is just another attribute the policy can reason about: “we allow Anthropic-provisioned agents acting for our employees to perform read operations on these resource classes, but not write operations, and never on these sensitive resource classes.”
- Signal propagation across the boundary. CAEP signals can flow in both directions. If your IdP revokes a user’s session, you can publish a signal that the agent platform consumes, telling it to stop dispatching agents for that user. If the agent platform detects an issue with one of its agents, it can publish a signal that your gateway consumes, telling you to block requests from that agent.
Agents become more useful as they can act across more platforms, which means the federation problem will only intensify. The platforms that ship credible federation primitives early — Anthropic, Google, OpenAI as they catch up — become the platforms enterprises can adopt without rebuilding their IAM stack to accommodate each one.
For an enterprise IAM team, the right posture is to invest in the patterns that make federation tractable: a clear trust-domain boundary, standardized ingress points for cross-domain calls, a policy engine that can reason about external actor identities, CAEP-capable gateways. These are platform-agnostic. The specific federation arrangements with specific agent platforms become incremental configuration changes rather than architectural overhauls.
A complete deployment, end to end
Pulling the five articles in this series together, a complete agentic identity deployment looks like this:
Workload identity. Every agent process has a SPIFFE SVID issued by SPIRE, scoped to its specific workload identity, attested by the platform (Kubernetes namespace + service account + image hash, or AWS instance identity, etc.), rotated continuously on the order of minutes.
Client authentication. Agents authenticate to your OAuth authorization server using the draft-ietf-oauth-spiffe-client-auth profile — JWT-SVID, X.509-SVID, or WIT-SVID as the credential. Client ID Metadata Documents support dynamic registration without ceremony. No client secrets exist in the system.
Delegation. When an agent acts on behalf of a user, OAuth Token Exchange (RFC 8693) produces a delegation token that names both the user (sub) and the agent (act). Impersonation is reserved for narrow cases where the agent’s identity must be deliberately hidden.
Context propagation. At ingress to your trust domain, a Transaction Token Service issues a Txn-Token binding user identity, agent identity, authorization context, and transaction-specific context together. The Txn-Token propagates through the call chain, with each workload able to assert its own presence in the chain.
Cross-domain. When calls leave or enter your trust domain, Identity Chaining (Token Exchange variants) re-establishes the chain with the receiving domain’s authorization server. SPIFFE Federation handles cross-domain workload identity verification.
Runtime authorization. An API gateway sits in front of every protected resource, evaluating each request against policy. The policy considers token claims, Txn-Token context, session state, device state, and external signals. PBAC, not static scopes, drives the decisions.
Continuous evaluation. The gateway subscribes to CAEP signals from your IdP, your authorization server, your fraud system, your DLP, your agent runtime. Revocation events trigger immediate session invalidation. The 60-minute access token lifetime becomes operationally irrelevant — revocation happens in seconds.
Audit. Every step produces logged evidence: SPIRE issuance log (which workload got what SVID when), authorization server log (which clients authenticated when), Txn-Token issuance log (which transactions started, with what context), gateway log (which requests were allowed or blocked, against what policy), CAEP receiver log (which signals arrived, what actions were taken). The chain from “user authenticated” to “specific operation occurred” is fully reconstructible.
What this is and what it isn’t
This is not a hypothetical architecture. Every component named in this series exists as either a stable RFC, an actively progressed IETF draft, or a published OpenID Foundation specification. Every component has at least one production-quality implementation available. None of it requires a new vendor category or a new product purchase if your existing stack is reasonably modern.
This is not the whole story of agentic identity. The user-facing consent semantics — how does a human grant an agent open-ended authority for a class of future actions they cannot fully enumerate? — is a research question with active work but no settled answer. The intent-capture semantics — how precisely does an agent need to express what it’s trying to do for the policy decision to be principled? — is similarly early. These are the residual 5% that the workload-identity framing acknowledges but doesn’t solve.
What the workload-identity framing does solve is the infrastructure question. Agents have cryptographic identities. They authenticate without distributed secrets. They preserve user identity and authorization context as they fan out across workloads and trust domains. Their access can be revoked in seconds when something goes wrong. Their behavior is fully auditable.
For an IAM architect, an enterprise CISO, or anyone responsible for the security of an agentic deployment, the actionable takeaway is: agents are workloads, 95% of the problem is solved now, and the standards you need are either stable or near-stable. The deployment work is real, but it’s familiar — the same kind of work IAM teams have been doing for the last decade, applied to a new class of consumer.
Start with SPIFFE for the agents you have. Adopt the OAuth SPIFFE Client Authentication profile in your authorization server. Pilot Transaction Tokens for your highest-value call chains. Wire CAEP into your gateway. The components compose. The result is an agentic identity architecture that holds up under both adversarial pressure and audit scrutiny — and that you can deploy this quarter on standards published, in many cases, before agents were a topic at all.
Primary sources: OpenID CAEP specification; RFC 8417 (Security Event Token); draft-ietf-oauth-transaction-tokens-07; draft-ietf-oauth-spiffe-client-auth-01; draft-ietf-wimse-arch-07; Sean O’Dell, “Agentic Identity Control Framework: You Already Have the Pieces. Now Build It.”