A senior engineer at one of our customers got laid off on a Friday. By Monday morning their corporate Okta account was disabled, their laptop was wiped, and their badge access was revoked. The IGA report turned green. HR closed the ticket. The CISO moved on.
That afternoon they opened their personal laptop and started Claude Desktop. The MCP servers they had configured the previous week loaded silently. Their company's GitHub. Their company's Google Drive. Their company's Jira. Every one of them connected, refreshed a token, and waited for instructions.
The IGA dashboard still showed green.
This is the new shape of the Joiner-Mover-Leaver problem, and the existing identity stack is not built to see it.
What JML used to mean
For two decades, IGA has been a story about two kinds of identities: humans, and the services they delegate to. The mental model was clean.
A human gets hired. A workflow provisions accounts across systems, attaches them to a directory entry, maps them to roles. The human moves teams. Entitlements get reviewed and adjusted. The human leaves. A deprovisioning workflow yanks the accounts. SCIM closes the loop with each downstream SaaS.
Service accounts got an adjacent treatment: long-lived credentials, machine identities, scoped roles, rotation policies. Not perfect, but coherent.
The pattern was: the credential lives inside infrastructure you can see, and the identity governance plane is the thing that tells those credentials to die when they should.
What agents broke
Agents do not fit either box.
An agent is not a human. It does not need a desk, does not have a manager, does not show up in a directory the way a person does. An agent is also not a service account, because it acts on behalf of a specific human, with that human's authority, against systems that recognize the human's grants.
In practice today, that "on behalf of" means a token. Often several. An OAuth refresh token for the user's GitHub. A long-lived access token for the user's Drive. An MCP server credential bundle pinned to whatever the agent runtime had loaded. These tokens get cached.
Cached where? In the agent runtime. Which lives where? On whichever device the user installed it on.
If the user installed the agent runtime on their corporate laptop, the cache went to the corporate laptop. Deprovisioning works fine for that surface, as far as it goes.
If the user installed the agent runtime on their personal laptop, the cache lives there. And there, it persists past the end of their employment. The corporate IGA plane never saw the cache, never knew it existed, has no mechanism to reach into a personal device and revoke it.
This is not a far-future risk. It is a Tuesday-afternoon risk for any company with a BYOD policy, a tolerance for personal-device email, or even a permissive "you can read company docs from your laptop on weekends" culture. Once an agent runtime touches that company's APIs from that device, a token cache forms.
Where the access actually lives
The corporate identity plane revokes the user's primary identity. SCIM fans out to downstream SaaS. The agent runtime never sat in that fan-out. It carries its own credential cache. The downstream SaaS treats every refreshed token as legitimate until the SaaS itself decides the underlying grant is gone, on whatever schedule and with whatever bug rate that vendor happens to ship.
Three things make this worse than it sounds
Token longevity. OAuth refresh tokens routinely live for 90 days or longer. Some live indefinitely until explicitly revoked. The cached blob on the terminated user's laptop is not a stale cookie that times out by lunch. It is a renewable credential with a multi-month horizon.
BYOD as the accelerant. Every company that allows personal devices to touch corporate systems has, by definition, accepted that some access lives outside their MDM perimeter. The agent token cache is the most concentrated form of that exposure to date, because it bundles cross-system access into a single local store.
Third-party variance. Even when SCIM does work, it works at the speed and quality of each downstream vendor's implementation. Some propagate revocations in minutes. Some do it nightly. Some have bugs that leave residual sessions alive. The IGA team owns the risk and the vendor owns the implementation. This is the subject of the next post.
What this means
The frame to discard is "we revoked them in Okta, we are done." That sentence was true when humans authenticated through the corporate identity plane every time they touched a system. It is no longer true when the agent runtime carries its own cache on a device you do not control.
The frame to adopt: every issued downstream token is a piece of access that lives somewhere outside your visibility, and the half-life of a former employee's access is no shorter than the longest refresh window in your token graph. If you cannot answer "what is the longest such window in our environment?" you cannot estimate your real time-to-revoke.
The next post looks at the mechanism most teams assume will save them, SCIM-based revocation across the SaaS surface, and why it does not.