Provision AI Users at Your IdP, Not the Vendor's Panel

Every vendor admin panel is a place where someone who left the company still has an account. The offboarding checklist never quite reaches all of them, and the gap between "left" and "lost access everywhere" is exactly the seam a breach walks through.

A security analyst runs an access review a week before an audit, the kind of chore that exists mostly to satisfy a control and rarely turns up anything alarming. She exports the user roster from a SaaS vendor's admin console and starts matching names against the HR system of record, one row at a time. The third name down belongs to someone who left the company eight months ago. The account is still active, still consuming a license, still holding whatever permissions it had on that person's final Friday. Nothing about this was negligent in the ordinary sense. The manager filed the offboarding ticket. IT disabled the mailbox, revoked the badge, wiped the laptop, and pulled the person out of the directory. But this particular tool had been set up long before, by clicking "invite user" inside the vendor's panel, and the person who clicked it has since changed teams. The account was never wired to anything that would learn its owner was gone, so it simply stayed — quietly valid, indefinitely.

That single stale row is not a story about one careless tool or one dropped ticket. It is a story about where the industry has decided user provisioning belongs, and the decision is quietly wrong in a way that compounds with every vendor an enterprise adds. When you create and manage users inside a vendor's admin panel, you have made that vendor a small, unsupervised identity provider. Its user list becomes a place where the truth about who works at your company can drift out of sync with the truth your HR system and your directory already hold, and every panel drifts independently. Multiply that by the dozens of tools a modern enterprise runs, and offboarding stops being an event and becomes a scavenger hunt — a race to remember every island of identity a departing person was ever granted a foothold on, run by people who were not the ones who granted it.

The account that outlives the employee

The reason this failure mode is so durable is that the vendor panel is genuinely convenient at the only moment anyone is paying attention to it, which is the moment of onboarding. Someone needs access, an admin opens the console, types an email address, picks a role, and clicks a button. The person is in, the work proceeds, and the transaction feels complete because from the onboarding side it is. What the panel cannot make convenient — what it structurally has no way to know — is the far more important second half of the lifecycle, the day the person's relationship with the company ends. Deprovisioning in the vendor-panel model depends entirely on a human remembering, months or years later, that this specific tool exists, that this specific person was granted access to it, and that the access now needs to be pulled. Human memory is exactly the wrong mechanism to hang a security boundary on, because it fails silently and it fails most reliably for the tools used least, which are often the tools nobody is watching.

This is the part worth sitting with, because it reframes what provisioning actually is. We tend to file it under IT convenience, a matter of getting people the tools they need to do their jobs, and in the vendor-panel framing that is all it looks like. But an account is not a convenience; it is a standing grant of access to systems and data, and a grant that no longer maps to a person who should hold it is not a loose end. It is an attack surface. The overwhelming majority of serious breaches trace back not to some exotic zero-day but to credentials that should not have still worked — a former contractor's login, a service account nobody deprovisioned, a role that was never revoked because no single system was responsible for revoking it. Every stale account in every vendor panel is a candidate for that story, and the vendor-panel model manufactures them by design, because it makes creating access a deliberate act and losing access an act of remembering.

Provisioning is a governance property, not an onboarding task

The alternative is not a better panel. It is refusing to let the panel own identity at all, and instead treating provisioning as what it actually is: an identity-governance question that belongs at the one place your organization has already agreed is the source of truth about who works there. That place is your identity provider — the directory that HR events already flow into, where a hire, a transfer, a role change, and a termination are already recorded as they happen. The protocol that carries those facts outward to the tools is SCIM, the standard for automated user provisioning and deprovisioning, and its whole point is to invert the lifecycle so that the vendor's user list is a consequence of your directory rather than an independent copy of it. When a person is hired, the IdP creates their accounts in the connected tools according to policy. When they change roles, entitlements adjust. When they leave, their access disappears everywhere the IdP provisions it, at the moment the termination is recorded, without anyone opening a single admin console or remembering that a given tool exists.

The difference this makes is not incremental, because it moves the security boundary off human diligence and onto a system event. In the SCIM model there is no scenario in which a departed employee's account "stays" in a governed tool, because nothing has to notice they left — the leaving is the trigger. Provisioning stops being a series of independent decisions made in scattered panels and becomes a single governed property of the identity itself: this person exists, therefore they have exactly these accesses; this person no longer exists here, therefore they have none. Auditing collapses from a scavenger hunt across consoles into a query against one system that already knows the answer. The stale row the analyst found in the vendor panel is not merely fixed under this model; it becomes structurally impossible, which is the only kind of fix that survives contact with a large organization over years.

When the user you provision can act on its own

All of this was already true for ordinary SaaS, and enterprises have spent a decade slowly, unevenly moving their tools behind the IdP for exactly these reasons. What raises the stakes now is the kind of user being provisioned. An enterprise AI platform does not just give a person a screen to log into; it deploys Autonomous AI Workers and Assistants that hold real, standing access to systems and data — reaching into the enterprise's applications through the Model Context Protocol, drawing on Enterprise Knowledge, calling models through an LLM Gateway, taking actions that a human would otherwise take. The identities in play are therefore of two kinds that both matter, and both are ruinous to leave in a vendor panel. There are the people who operate and configure the AI workers, whose access to change what an autonomous system does is among the most sensitive an enterprise grants. And there are the AI workers themselves, which are effectively principals with permissions and need to be governed as first-class identities rather than as settings buried in a product's console.

A leaver who still had the ability to reconfigure an autonomous worker, months after their departure, is a materially worse version of the stale-account problem than a leaver who still had a dormant reporting login, because the blast radius of the access is the reach of the AI system rather than the reach of one dashboard. This is precisely the sort of inadequate risk control that turns promising deployments into cancelled ones — Gartner has predicted that over forty percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs and, tellingly, inadequate risk controls among the causes. An AI worker with genuine access to the business, provisioned and governed as loosely as a marketing tool signed up for in a hurry, is a control failure waiting to be discovered in exactly the access review that opened this essay. It is why serious Enterprise Deployment treats provisioning as a security architecture decision from the start: AI workers and their operators are enrolled through the same IdP and the same SCIM lifecycle as every other identity, with Human-in-the-Loop gates on the consequential actions and access that begins and ends with the person's standing in the directory, not with anyone's memory of a panel. The organizations building toward a genuinely autonomous enterprise understand that autonomy without governed identity is not autonomy at all; it is unaccountable software with the keys to the building.

So the useful shift is to stop thinking of provisioning as the act of granting someone access and start thinking of it as the guarantee that access tracks reality. The question a vendor panel invites you to ask — can I add this user — is the easy half and the unimportant one. The question that governance forces, and that only the IdP can answer, is the one that actually protects you: when this person leaves, or this AI worker is retired, does its access leave with it, everywhere, at once, without anyone having to remember that it existed. A tool you provision from a panel can never promise that, because it does not know what your directory knows. A tool you provision from your identity provider cannot fail to, because knowing is the whole point of the identity provider. The stale account in the panel is not a mistake to clean up after. It is the predictable output of putting provisioning in the wrong place, and the fix is not more diligence — it is moving the decision to where the truth already lives.