The previous post landed on an uncomfortable observation. When a user leaves, the access cached inside agent runtimes on their personal devices does not go away just because their Okta account did.
The reflexive answer from most IGA teams is: that is what SCIM is for. We do not just deactivate in Okta. We propagate deprovisioning to every downstream SaaS. The downstream tokens get invalidated, and even a cached refresh token becomes useless.
This is the story we tell ourselves to sleep at night. It is mostly fiction.
What SCIM actually is
SCIM is a wire protocol. It is not a guarantee. The IGA plane sends a DELETE or a PATCH active=false to a downstream SaaS endpoint. What happens after that request leaves your network is entirely up to the vendor.
In a charitable vendor, the request hits an API gateway, dispatches to a user service, deactivates the user record, fires events that invalidate active sessions, and propagates to any token introspection layer that gates downstream API calls. In a non-charitable vendor, the request marks a flag in a table and waits for a nightly job. Or fires events that some downstream caches respect and others do not. Or hits a bug.
The shape of your blast radius is the worst vendor in your stack, not the best.
The revocation fan-out, drawn honestly
- GitHub200 OK, session invalidated~5 min
- Google200 OK, refresh rotated~30 sec
- Jiradelayed202, queued for nightly jobnext 24h
- Slack200 OK, session killed~1 min
- Vendor Xfailed500, retry next sync???
Blast radius = the worst leg. The account isn't truly revoked until Vendor X confirms — until then, the agent's access lives on for an unknown window.
The IGA report turns green when the requests are issued. It does not turn green based on the truth, which is the slowest, buggiest, most uncertain leg of the fan-out.
Now overlay the agent runtime from the previous post. The user has cached refresh tokens to GitHub, Google, Jira, Slack, and Vendor X. Each of those tokens stays valid until the corresponding vendor finishes propagation. The IGA dashboard says you are safe at minute zero. The truth says you are safe somewhere between five minutes and "next time someone notices Vendor X has a bug."
Why this is structurally hard
There are four reasons SCIM cannot be the kill switch you want it to be, and each of them is independent of vendor effort.
One: you do not own the implementation. Every downstream SaaS owns its own deprovisioning code path. You can read their docs, you can demand SOC 2 reports, you can run tests. You cannot fix their code. Your time-to-revoke is gated on N independent engineering organizations.
Two: SCIM speaks about users, not tokens. SCIM deactivates an identity. Whether that deactivation also invalidates already-issued tokens is a downstream implementation choice. Many vendors implement deactivation as "the user can no longer log in interactively" but leave previously issued OAuth tokens valid until they expire on their own schedule. The agent does not log in interactively. It refreshes.
Three: token introspection is rarely synchronous. Even vendors that do invalidate tokens on deactivation often do so by writing to a revocation list that token-validation paths check on a cache miss. The validation cache may be tens of minutes long. The agent refresh window is shorter than that cache. The math fails.
Four: the long tail of integrations. Your IGA plane covers your top 20 SaaS vendors. Your real environment has 150. The long tail has worse SCIM, less frequent audits, and more bugs. The agent does not respect this distribution.
The asymmetry
The most uncomfortable part of this is the ownership pattern. Your IGA team carries the risk on their balance sheet, in their on-call rotation, in their next breach narrative. Every downstream vendor carries the implementation, with their own incentives, roadmap, and engineering capacity.
This is an asymmetry no amount of policy can fix. You cannot policy your way into reliable propagation. You cannot audit-question your way into faster cache invalidation. You can negotiate it into a contract, but a contract is a remedy, not a control.
The right question to ask is not "can we make SCIM faster?" It is "why is the kill switch sitting on the other side of fifty vendor boundaries we cannot control?"
What this implies
If SCIM is not the kill switch, something else has to be. Specifically: something on your side of every vendor boundary, that downstream tokens flow through and depend on, that you can flip in a single place.
That something is the subject of the next post: the agentic identity broker.