Your AI Users Don't Exist in Your Directory. That's a Ticking Time Bomb.

When an employee leaves your company, IT knows the drill. Disable email. Revoke VPN. Remove Slack, Salesforce, GitHub, Jira, and the rest of the standard SaaS stack. The process is usually automated, tied to your directory, and backed by years of identity governance work.

Now ask a harder question: what happens to that employee's AI accounts?

The ChatGPT account they created with a work email. The Claude workspace used by their team. The coding assistant linked to an internal repository. The experimental agent connected to a knowledge base. The workflow automation with an AI step that still has access to business data.

In many companies, those users do not exist in the enterprise directory at all. They sit in a shadow identity layer, outside SSO, outside SCIM, outside normal offboarding, and outside the access reviews auditors expect.

The AI Identity Gap

Enterprise identity management works because most business applications eventually connect to the same identity layer. Your identity provider knows who the user is, which groups they belong to, what applications they can access, and when that access should end.

AI adoption broke that pattern. Employees often create standalone AI accounts before IT has approved a tool, before procurement has reviewed the vendor, and before security has connected it to SSO. Team-level AI tools spread quickly because the productivity gain is obvious and the signup process is easy.

The result is a gap between the users your directory can see and the AI users who actually exist across the company.

If an AI account is not tied to your identity system, it is not part of your real access control model. It is just an exception waiting to be forgotten.

Why Orphaned AI Accounts Are Different

An orphaned SaaS account is already a problem. An orphaned AI account can be worse because of what it contains and what it may still reach.

AI conversations often include sensitive context: customer emails, internal documents, product plans, code snippets, incident details, pricing notes, HR questions, and strategy drafts. Even if the account no longer has live access to internal systems, its history may still contain company information.

Some AI tools also connect to knowledge bases, document stores, repositories, or workflow systems. If access is not centrally managed, a former employee may keep access to information long after their official employment ended.

For regulated teams, this creates a clean audit question with an uncomfortable answer: can you prove that AI access was revoked when the employee left?

Directory Sync Is Not Just Convenience

SSO is often treated as a login feature. For AI governance, it is more than that. It is the foundation for lifecycle control.

When AI access is tied to the directory, the same enterprise controls can apply:

• Provisioning: users receive the right AI access based on their role, team, and group membership.
• Deprovisioning: access is revoked automatically when a user leaves or changes status.
• Group-based policy: legal, engineering, finance, and support can access different agents and knowledge sources.
• Access reviews: managers and security teams can periodically verify who still needs which AI capabilities.
• Audit evidence: access decisions are tied to identity records instead of scattered screenshots and spreadsheets.

Without this, access governance becomes manual. Manual access governance does not survive fast AI adoption.

The Group Membership Problem

AI access is not binary. The question is not simply "can this employee use AI?" The real question is: which AI systems, which data sources, which agents, which actions, and under which policy?

A legal contract assistant should not be available to every employee. A code assistant connected to engineering documentation should not be available to HR. A finance analysis agent should not be available to a contractor just because the contractor has a company email address.

This is where group membership matters. If AI tools do not understand your directory groups, permissions drift. People accumulate access as they move teams. Temporary exceptions become permanent. Contractors keep access longer than intended. Nobody notices until an audit, incident, or uncomfortable review forces the question.

The Agent Catalog Is the Missing System of Record

Identity alone is not enough. You also need to know what the user is accessing.

That is the role of the AI agent catalog. Every approved, discovered, or custom-built AI system should have a record with its owner, purpose, environment, data access, lifecycle status, users, groups, and review date. Access policy should be attached to that record, not buried in each vendor's admin panel.

When the catalog and directory work together, governance becomes practical:

• Security can see which groups have access to each AI agent.
• IT can remove access when a user leaves or changes teams.
• Compliance can review evidence by agent, owner, and policy.
• Finance can connect usage and spend to teams and business owners.

What Good Looks Like

Good AI identity governance does not slow teams down. It gives them a safer path that feels normal. Employees log in with the identity they already use. Their available agents match their team and role. When they move teams, access changes. When they leave, access ends. When an auditor asks who could use a specific AI system, the answer is available in minutes.

The companies that get this right will not be the ones with the longest AI policy documents. They will be the ones that connect AI access to the identity and governance systems they already trust.

The Bottom Line

Your directory is supposed to be the source of truth for who has access to what. If AI users live outside it, your AI governance program has a blind spot.

Start by cataloging the AI systems your teams use. Connect access to enterprise identity. Review high-risk agents regularly. And make the governed path easier than the workaround.