Why User Provisioning Matters for Enterprise AI

Offboarding a user is not enough when the credentials they leave behind can still spend money and invoke tools.

An orphaned SSO account is inert. Nobody logs in, nobody clicks anything, and eventually someone notices it during an access review.

An orphaned AI credential is different.

A virtual key can still have a budget, provider and model access, and perhaps permission to invoke MCP tools against other systems. The person it belonged to may have left six months ago while the credential continues doing exactly what it was authorized to do, with nobody attached to it and nobody wondering why its usage still appears on the bill.

That is why user provisioning for enterprise AI is not simply another implementation of the joiner, mover, leaver problem IAM teams have managed for decades. The identity lifecycle is familiar. The consequences of getting it wrong are not.

How Should Enterprise AI Provision New Users?

The joiner case is the easy one, which is precisely why it should not get much attention.

The previous post looked at how roles and access profiles connect human authorization to runtime policy. With Bifrost user provisioning, an identity-provider group can map a user to a role, the role supplies its default access profile, and that profile issues governed access when the user arrives. Providers, models, budgets, rate limits, and tool access have already been decided. The new employee inherits policy instead of inventing it.

That is the ideal state: nobody files a ticket for an API key or remembers which model Marketing may use. Organizational intent was encoded before the employee arrived, so provisioning mechanically applies a decision already made.

Joiners are the flattering part of lifecycle management. Movers are where exceptions accumulate.

Why Are Role Changes Dangerous for Enterprise AI Access?

Imagine the acquisition from the first post six months later. One engineer initially joins the migration team, later moves to the platform group, and eventually transfers into an internal agent project.

Each move is legitimate. Each requires new access. The dangerous question is what happened to the old access.

Role-based provisioning can replace assignments that originated from a role default. But a profile assigned directly to a user represents an explicit exception, so it survives the role change. The system can distinguish a role-derived assignment from a direct assignment; it cannot determine whether the reason behind that exception still exists.

Combine that with the role behavior from the previous post: when someone holds multiple roles, permissions resolve upward rather than to their intersection. The result is a familiar enterprise failure with an AI-specific blast radius. People gain access at every transition and shed it at none.

Three teams into someone's tenure, their effective authorization may resemble the union of all three jobs they have held. That can mean access to models approved for a previous team, a larger budget, different logs, or tools their current role has no reason to invoke.

Movers therefore need more than synchronization. They need reconciliation. Bifrost's user provisioning model reflects role and team changes when users are reconciled against the identity provider, but lifecycle management still has to account for exceptions outside those inherited defaults. Automation is good at applying known rules and poor at deciding whether an exception created fourteen months ago still has a business justification.

The question is not simply, "What access should this person's new role add?" It is also, "What access no longer has a reason to exist?" Who owns this key, why does this direct assignment still stand, and would the organization grant the same access today if asked fresh? Those are governance questions rather than provisioning mechanics, and no synchronization job will answer them.

In practice, reconciliation is a scheduled comparison rather than an event handler. Once a quarter, list every access profile assignment that did not come from a role default, along with who created it, when, and against which stated justification. Anything without a justification on record is the finding. Anything with one is a question for the person who owns that team, and the question is not whether the access is being used but whether it would be granted again today.

That distinction matters because usage is a misleading signal here. An unused grant is not evidence of safety; it is a capability sitting idle until an incident or an automation reaches for it. A budget that has never been spent still authorizes the spending.

What Should Happen to AI Access When a User Leaves?

Leavers expose the difference between identity management and AI lifecycle management most clearly.

The obvious response to a departing employee is deletion: remove the account, revoke credentials, clean up the objects, and leave the system tidy. The second post in this series discussed why an expired virtual key should instead fail closed without disappearing. During offboarding, that distinction becomes critical.

By the time someone leaves, the system may hold an identity, roles, access-profile assignments, a virtual key, budget counters, model permissions, rate limits, tool grants, and a record of requests made under that authority. Some must stop working immediately. Some must survive.

Event	Identity	Role	Access profile	Virtual key	MCP credentials	Record
Joins	Created on first login	From IdP group	Role default applies	Issued automatically	Authorized per user	Created
Moves	Unchanged	Replaced	Role defaults swap; direct assignments persist	Reissued	Persist separately	Retained
Leaves	Deactivated	Removed	Copy retained	Fails closed	Revoked separately	Preserved

The last row is the architecture: fails closed, record preserved.

Suppose Security investigates an event six months later. The useful questions are historical: which models could this person reach, what budget applied, did they have MCP tool access, and was that access inherited or directly assigned?

Deleting lifecycle objects because the employee left makes those questions harder precisely when their answers matter most. This is a write-side custody problem as much as an identity problem. The system should preserve enough state to explain what happened rather than reconstructing it later from an IdP, billing export, deleted credential, and today's configuration.

Offboarding therefore has two obligations that pull against each other: end the authority, and preserve the evidence. A leaver should become incapable of causing new actions without becoming invisible to the historical record.

That distinction matters most with tools, and there is a second object hiding here. Where an MCP server uses per-user OAuth, the departing employee holds credentials that are separate from their virtual key and have to be revoked separately. Bifrost exposes a sessions view for inspecting and revoking those per-user MCP credentials, which is easy to miss in an offboarding checklist designed before agentic AI entered the enterprise stack.

It is worth being precise about why that is three operations rather than one, because they fail independently.

Deactivating the identity stops someone logging in. It does not reach anything already issued under that identity. An offboarding process that ends here has closed the front door and left every key that was cut from it in circulation.

Invalidating the virtual key stops the requests. This is the operation most teams think of as revocation, and it is the one that actually severs runtime authority. It should fail closed while remaining inspectable, for the reasons above.

Revoking per-user MCP credentials is the one most likely to be missed, because the credential is not entirely yours. Per-user OAuth means the employee authorized an external service directly, and the resulting grant lives at that service. Invalidating their virtual key stops requests flowing through the gateway. It does not, on its own, tell the external provider that the authorization behind those requests should end. That grant has to be revoked where it lives, which is why a sessions view exists as a separate surface rather than as a checkbox on the user record.

The practical consequence is that "we deactivated their account" answers only the first of three questions, and the third one is the one nobody thinks to ask.

The exposure is conditional rather than automatic, and the condition is the interesting part. By default Bifrost does not execute tool calls on its own; a model returns suggestions and the application has to call the execution endpoint explicitly. But a workload running in agent mode with auto-approval configured has no such pause. A forgotten SaaS login is dormant until somebody uses it. An orphaned key attached to an autonomous workload is already being used, and the human whose authority justified those tool grants left two quarters ago.

An orphaned SSO account is inert.

An orphaned virtual key is an actor.

And there is a question sitting underneath all of this that the series has not answered. The record survives the person, but six months later, what does that record actually prove, and who should be allowed to read it? Removing access is only half of offboarding. The other half is being able to explain what happened while that access still existed.

One practical distinction before designing around any of this. Bifrost itself is open source, including the gateway and the core governance around virtual keys, budgets, routing, and MCP tool filtering. The user provisioning and identity lifecycle discussed here are Enterprise capabilities, and the documentation is the better place to check that boundary than a blog post.

What Happens to AI Credentials That Never Had a User?

There is one uncomfortable limit to this model: lifecycle management assumes a lifecycle.

None of it helps with an identity the system never knew about. A contractor handed a key directly. A shared service account nobody quite owns. A credential minted for a pipeline in 2024 by someone who has since left. These may be the most consequential actors in the environment, because they run continuously, spend consistently, and often hold broad permissions on the theory that automation is inconvenient when it fails. Unlike a person, they never transfer teams and never trigger an offboarding workflow. You cannot deprovision an identity that never existed.

The only workable answer is to give them the lifecycle events they will never generate on their own. Every non-human credential needs a named human owner, not a team alias, and a review date on the calendar. The owner is who gets asked when the credential appears in an incident. The review date is the substitute for the HR event that will never arrive. Expiry helps here more than it does for people: a workload credential that has to be renewed annually forces someone to state, once a year, that the thing still needs to exist. Most of the credentials that worry security teams would not survive that question.

That leaves enterprise AI with a harder question than joiners, movers, and leavers: how do you govern actors that were never people in the first place? An agent does not join a team, does not sit in a reorganization, and does not have a last day. It has an owner who may or may not remember creating it, a budget nobody reviews, and a set of tool grants that made sense on the afternoon they were issued.

That is where the lifecycle problem stops being about users and starts being about workloads.

---

This article was commissioned by the Bifrost team. The link to the Sovereign Systems Specification points to my own work. The architectural perspective and conclusions expressed here are my own.