Identity provisioning for 1,000+ users across 600+ groups

The problem

Two tools needed access managed across the whole organisation, against a membership model where one person belongs to many groups and group membership changes as people join, move and leave.

Done manually, a matrix of that size is not merely tedious. It is unreliable in a specific and dangerous way. Manual provisioning fails safe on joiners, because someone complains when access is missing. It fails unsafe on leavers, because nobody complains about access that should have been removed. That asymmetry is how organisations accumulate active accounts belonging to people who left months ago.

Accounts that outlive their owners also cost money wherever a tool is billed per seat, and seats are the one line of an AI bill a finance team can forecast from a headcount plan, as our guide to budgeting for AI seats, tokens and agent runs explains.

The same asymmetry applies to software acting for people. An AI agent in a company's financial close needs its access granted, reviewed and removed like anyone else's. Our guide to SOX controls for AI agents in finance covers that alongside change management, evidence and review.

Why it was built rather than configured

The internal IT team was over capacity and did not have the time to take it on, which is the ordinary reason this kind of work does not get done anywhere.

Off-the-shelf group tooling was considered and rejected. The organisation's membership model (overlapping groups, HR as the source of truth, two target systems with different provisioning semantics) did not fit the shape those tools assume, and bending the model to fit the tool would have left the mismatch to be handled manually anyway.

How it works

HR as the source of truth

Provisioning is driven from the HR system, so joining, moving and leaving are reflected without a separate administrative step that someone has to remember.

Deterministic identity resolution

Matching a person across systems is done by explicit rules rather than fuzzy heuristics, because a wrong match grants the wrong person access.

Diff-based writes

Each run computes the difference between intended and actual state and applies only that, so a run is idempotent and a retry cannot compound.

Dry-run mode

Changes can be inspected before they land, which is necessary when a single run can alter access for hundreds of people.

Audit trail and rollback

What changed, for whom, and why, with a defined path back from a bad run.

Outcome

The system has run for seven months. Access reflects the HR system rather than someone's memory, joiners are provisioned without a ticket, and leavers lose access because a record changed rather than because somebody noticed.

This was built inside the wider enablement engagement at the same organisation, and shares its engineering defaults: idempotency, dry runs, auditability and rollback are the baseline rather than additions.

The same pattern now governs AI tools generally: Anthropic, for example, lets Claude Enterprise admins switch agent features such as Claude Cowork on for chosen groups synced by SCIM, which our guide to Claude Cowork for business leaders describes. How OpenAI decides who gets ChatGPT Work is set out beside it in our comparison of ChatGPT Work and Claude Cowork.

An AI tool that reads company data needs the same rule, access that follows the person using it, and our guide to data strategy for AI makes that the first check before any build.

A company rolling out an AI assistant to every desk meets the same question in its first fortnight. Our plan for the first 90 days of a ChatGPT Enterprise rollout puts sign-in and SCIM provisioning before the first broad invite, for this reason.

Microsoft 365 Copilot makes stale access visible in a new way, because it answers from everything a user can still open. Our comparison of Microsoft 365 Copilot and ChatGPT Enterprise puts the SharePoint permissions clean-up before the first licence for that reason.