Your Offboarding Is Finished. The Bot They Built Is Still Running.

You revoked their SSO. The bot they built is still running.

An engineer leaves. IT does what it always does: disables the account in Okta, pulls the SSO grants, reclaims the laptop. On paper, the person is gone.

In practice, the Slack bot they wired to a shared channel is still posting. The Zapier connection they authorized still moves data between two apps every night. The AI agent they handed a service account to still has its access, and nobody remembers it exists.

None of those were tied to their SSO login. They were separate credentials, OAuth grants, integration tokens, an agent’s key, created directly against the apps. Deprovisioning a person doesn’t touch them. So the tokens sit there. No owner, no review, no expiry. Live.

That is the gap offboarding misses. You can revoke a person cleanly and still leave a trail of working machine identities behind them. The customers we hear from already have names for what that produces:

“orphaned after projects end,”

“service account sprawl,”

“invisible, ungoverned, and overprivileged”.</i>

How bad is the sprawl, really?

Bad, and worse than anyone can agree on.

Non-human identities now outnumber human ones by a wide margin, and the count is climbing fast. But the exact ratio depends entirely on what you measure, and where. Different vendors offer widely different counts on how many NHIs are running through your org:

So the number is contested. Different vendors measure different environments with different methods, and the spread, 17:1 to 144:1 depending on the study, reflects that, not sloppiness. What none of them argue about is the direction. The non-human surface is now the larger one, AI agents are its fastest-growing slice, and it is compounding. Read 144:1 as the ceiling of a range, not a consensus.

So why can’t your SSO see any of it?

Because it was built to find people, and none of these are people.

Your SSO and IdP are built around people. They govern who a human is, what groups they belong to, what they can log into. Most identity tooling does that work, and does it well. That part is genuinely hard.

Here’s where it gets uncomfortable. It’s a human-identity model in a world that has gone non-human. When CyberArk surveyed the field, 88% of organizations defined only human users as privileged. The machine identities, the OAuth grant one SaaS app holds against another, the integration token, the Slack bot, the MCP server an agent runs through, never touch the IdP at all. They were provisioned directly, app to app. So when the IdP deprovisions a person, it reaches everything that person logged into and nothing they authorized on the side.

The industry conversation points the wrong way, too. Most writing about machine identity is cloud- and infrastructure-first: workload identity, Active Directory service accounts, secrets in a CI pipeline. That matters. But it steps right past the SaaS-app layer, the OAuth grants, integration tokens, bot tokens, and agents that live between the apps your company actually runs on. That layer is where a departing employee’s leftovers pile up. It is also the one nobody has claimed.

What does governing these things at the app layer actually take?

The same three things you already give a human account.

None of this needs another vault or another scanner. Treat every token and agent at the SaaS-app layer the way you already treat a person: give it an owner, watch it for staleness, wire it into offboarding.

Owner. The first question about any machine identity is the one nobody can usually answer: who created this, and who is accountable for it now? A token with no owner is a “decommission candidate,” in a customer’s own words. Attach a human owner to each grant and agent, and an anonymous credential becomes something you can review.

Staleness. Is it still doing anything? “Hasn’t authenticated in six months but still has privileged access” is how one practitioner named the exact failure. Last-use data sorts the tokens that earn their access from the ones that are pure standing risk.

Offboarding trigger. When a person leaves, their machine identities should surface as part of the same offboarding, the bot they built, the token they authorized, the agent they stood up. Then those credentials get a decision, instead of defaulting to “left running.”

This is where Torii sits. Our SaaS discovery already maps the app-to-app graph; it can see the OAuth grants and integration tokens between apps and attach a human owner and an offboarding trigger to each one. Visibility, ownership, and a trigger at the point of offboarding.