The previous two posts left us with a problem.
When a user leaves, the cached tokens inside agent runtimes on their devices outlive their employment. The downstream SaaS layer cannot save us, because each vendor's revocation quality is its own roll of the dice, and our blast radius is the worst roll.
The frame to abandon: "we revoked their identity, and SCIM closed the loop."
The frame to adopt: every downstream token that ever leaves our perimeter is access we can no longer guarantee we control.
So pull the perimeter inward.
The core move
Stop letting agents hold downstream tokens at all.
Every downstream credential, every OAuth refresh token to GitHub, every API key to Drive, every Jira bearer, lives inside a broker that you operate. The agent does not see those credentials. The agent does not cache those credentials. The agent's runtime, whether on a corporate laptop or a personal MacBook or a third-party agent host, never holds the keys to the downstream system. It holds, at most, a short-lived ticket the broker issues per request.
The kill switch is the broker. One control plane, one revocation surface, instant propagation.
What the agent presents to the broker is a ticket that proves the user's enterprise identity right now. Not a refresh token cached last Wednesday. A fresh assertion from the IdP, with a TTL measured in minutes, scoped to one downstream call.
The broker validates the ticket against the live IdP. If the user is still active, the broker mints a downstream call to the SaaS using the broker's own held token. If the user has been deactivated, the ticket fails validation, and the call never reaches the SaaS. The broker never had to ask the SaaS to revoke anything. The SaaS does not need to know.
What the broker is responsible for
A broker that takes this seriously owns five responsibilities. Each is a hard problem in its own right.
One: token custody. The broker holds the long-lived downstream credentials. They never leave its boundary. Storage is encrypted, access is audited, rotation is automated. The broker is the only thing that needs SOC 2 talking points about credential hygiene, because nothing else holds credentials.
Two: ticket exchange. The broker accepts short-lived assertions from the enterprise IdP (OIDC ID tokens, SAML assertions, or whatever the IdP issues), validates them on every call, and mints downstream calls only when validation succeeds. This is RFC 8693 token exchange territory, with the broker as the audience.
Three: per-call authorization. The broker is not just a token translator. It is a policy enforcement point. The same agent acting for the same user might be allowed to read a repo and not allowed to delete one. The broker checks each call against a policy engine before it dispatches.
Four: audit and observability. Every call the broker makes downstream is logged with the user identity, the agent runtime identity, the policy decision, the time, and the result. This is the audit trail that the cached-token-on-laptop world never had.
Five: revocation. The kill switch. One revocation event in the broker invalidates a user's ability to operate any agent against any downstream system, immediately. Not "after SCIM propagates." Not "after the vendor caches expire." Now.
What the broker is not
It is worth being precise about what this pattern is not, because the space is full of adjacent things that sound similar.
It is not an IGA tool. IGA still has a job: governing the grants themselves, certifying who should have access to what, running attestations. The broker is the runtime enforcement of those grants for agentic traffic.
It is not OAuth federation. Federation lets a user sign in to one vendor using credentials from another. The broker mediates traffic, not sign-in. Federation is the relationship between IdPs and SaaS. The broker is the relationship between agents and SaaS.
It is not BeyondCorp. BeyondCorp moves trust evaluation from network perimeter to per-request identity for human-facing applications. The broker does the analogous move for agent-driven calls, with a different threat model and a different token graph.
It is not a vendor's "AI gateway." Several vendors offer model gateways that proxy LLM traffic. Those gateways protect prompts and responses. The broker protects credentials and downstream API calls. Adjacent, not equivalent.
The before and after, in two diagrams
Token cached locally — lives until the vendor expires it or revocation fails.
The token boundary moves off the device. The broker is the only place a real token lives — and you can revoke it.
The shape of the difference is small in the diagram and enormous in the operational model. The token boundary moved from the device to the broker. The kill switch moved from "the slowest downstream vendor" to "one control plane you operate."
The metric that matters
In a SCIM fan-out world, the question "what is our time-to-revoke?" has no single answer. It is a distribution across vendors, with a long tail.
In a broker world, there is a single answer, and it is measured in milliseconds. You revoke at the broker. The next ticket fails. There is no next ticket.
This is the metric that should appear on the CISO's dashboard, and it is the one that the broker pattern makes meaningful for the first time.
What this implies for the next thing you build
If you are building or buying anything in the agentic space right now, the question to ask is not "does it support our IdP?" The question is "where do the downstream tokens live?"
If the answer is "on the user's device" or "in the agent vendor's cloud, scoped to the user," you have the cached-token-on-laptop problem from post one and the SCIM-asymmetry problem from post two. If the answer is "inside a broker we operate, exchanged per call from short-lived assertions," you have a kill switch you actually control.
That is the point. The broker is not a feature. It is the design decision that makes everything else recoverable.