AI Admin APIs Are Here—But Your Directory Is Still the Source of Truth

By Greg Nowak. Last updated 2026-07-23.

AI workspaces are becoming much easier to administer through code. OpenAI now supports workspace-scoped Admin keys for supported ChatGPT and Codex administration APIs, covering group management, spend controls, cost reporting and analytics. Anthropic’s beta Admin API can manage Claude Enterprise members, invitations and groups, as well as expose custom-role information.

That removes a fair amount of manual work. It does not make either workspace the authority on who works for the company, where they sit in the organisation or what access their role requires.

Those answers still need to come from the corporate identity directory and the business processes behind it. The administration API is there to enforce decisions and report on the result. If you treat the workspace itself as the source of truth, automation can preserve exactly the problems you meant to fix: orphaned accounts, unmanaged users, inconsistent groups and privileges that survive a move or departure.

An admin API cannot decide whether its records are right

An admin API can tell you who belongs to a workspace, which invitations are pending, which groups exist and which administrative operations are available. It can also apply changes quickly and consistently.

What it cannot do is establish whether the current state is legitimate. A person’s presence in an AI workspace does not prove that they still work for the company. A familiar group name tells you nothing about whether its membership matches today’s organisation. An active account does not demonstrate an ongoing business need.

Those decisions normally come from an identity provider or another governed directory tied to HR lifecycle processes. The workspace should be checked against that authority. Any mismatch should become a visible exception with an owner, reason and expiry, rather than a quiet fact that every future automation run accepts.

The risk grows as administration becomes easier. A manual error may affect one account. A reconciliation job that assumes every existing account is valid can reproduce the same error across several workspaces, run after run.

Map the boundaries before writing the workflow

OpenAI distinguishes tenant-level identity settings from individual workspaces. Its SCIM documentation also separates ChatGPT workspace membership from API Platform organisation membership. The surfaces are related, but they do not automatically form a single provisioning context.

Claude Enterprise has comparable boundaries. Its user-management API covers Enterprise organisation members, invitations, groups and role visibility, while the documentation points Claude Console organisations to a separate Admin API guide. An inventory therefore needs to name every tenant, workspace and organisation. A company email domain is not a sufficient model.

For each boundary, record its owner, the directory population allowed to enter it, the provisioning method, permitted exceptions and the rule for deprovisioning. This stops a workflow designed for one workspace from quietly becoming the company’s default identity process everywhere.

Control matrix for an AI workspace reconciliation

Decision	Trusted input	Workflow response	Evidence for an exception
Should this person be a member?	Approved directory population	Invite, retain or flag for removal	Named owner, reason and expiry
What access should they have?	Directory attributes and governed groups	Reconcile groups and roles	Approved role deviation
Has a mover kept obsolete access?	Current team and job attributes	Remove old groups before adding new ones	Time-limited transition approval
Is this workflow allowed to change the record?	Provisioning ownership and API scope	Write only through the controlling system	Manual remediation ticket
Does usage support the access decision?	Workspace analytics and cost reporting	Report inactivity, limits and anomalies	Documented operational need

Give each account one provisioning authority

OpenAI’s SCIM guidance highlights an easy trap. ChatGPT allows manually added users alongside SCIM-managed users, and its member list shows how each person was added. The guidance also warns against combining Automatic Account Creation with SCIM because doing so can provision unmanaged users. Only SCIM-managed users can be automatically deactivated when identity-provider group membership changes.

So “the account exists” is not enough information for a safe reconciliation. The workflow must also know who controls it. In practice, accounts need a clear classification: directory-managed, explicitly excepted or unmanaged. An unmanaged account should be reviewed, given an accountable owner and either moved into governed provisioning or removed through an approved process.

Anthropic’s API behaviour follows the same ownership principle. If SCIM controls a membership, the API rejects its removal. It also rejects membership changes to SCIM-managed groups because those changes belong in the identity provider. Organisations using automatic JIT or SCIM provisioning cannot create invitations through the user-management API.

These restrictions are useful. They tell you where a change belongs. A sound workflow detects the controlling system, makes the change there when permitted and raises a clear exception when a person must intervene.

Groups need a business meaning

Groups make access manageable at scale, but a group is not a permission in its own right. OpenAI’s quickstart explains that groups can receive roles for tenant- or workspace-level resources and control access to shared GPTs. It recommends planning groups and RBAC before broad onboarding so that permissions do not develop inconsistently.

A durable group model starts with plain business questions. Who belongs in this group? What does membership enable? Who owns the rule? Where possible, membership should be reproducible from governed directory attributes. Administrative groups should be narrower than general-access groups, and specialised capabilities should be granted deliberately instead of inherited from a catch-all “AI users” population.

Names also matter when systems are connected. OpenAI notes that when an existing ChatGPT group shares a name with a group synced from the identity provider, the existing group becomes SCIM-managed and its membership comes under the identity provider’s control. Reviewing group names and members before enabling sync avoids an unexpected handover.

Separate reporting access from change access

OpenAI’s workspace-scoped Admin keys inherit their available permissions from the administrator’s workspace role and cannot be used for model inference. Anthropic provides separate read and write scopes for member and group operations. That makes a least-privilege setup practical: reporting jobs do not need mutation rights, credentials can be limited to the relevant environment, and a reconciliation process need not receive more authority than its task requires.

The first production step should be discovery, followed by a dry run. Fetch the directory and workspace states, normalise identifiers, classify the differences and generate a proposed change set. Destructive actions and privilege increases need explicit policy checks. For investigation and audit, retain the input snapshot, proposed action, result, error and correlation identifier for each run.

The workflow should also be idempotent. Repeating a successful reconciliation should produce no additional changes. A pending invitation, an existing group membership or a platform-specific error is a state to understand, not a reason to keep retrying blindly.

Joiners, movers and leavers are the starting point

A joiner needs the right workspace, seat and baseline groups. A mover needs obsolete access removed with the same care used to add new access. A leaver needs prompt deprovisioning across every mapped boundary. A mature review also catches pending invitations, manual accounts, expired or dormant exceptions and groups that no longer have an accountable owner.

Spend and usage data add useful context, but they do not settle an identity decision. OpenAI’s expanded administration capabilities include spend controls, cost reporting and analytics, with up to 120 days of credit and Codex analytics history in the Global Admin Console. Administrators can use that history to spot unused access, investigate unexpected consumption and make better limit decisions. Low usage alone should not remove someone whose role still requires access.

The useful deliverable is not simply an API integration. It is an administration process people can trust: mapped boundaries, authoritative identity inputs, narrowly scoped credentials, repeatable reconciliation, dry runs, audit records and exception reports with named owners.

Greg can help untangle the identity sources and workspace boundaries, reconcile users and groups, connect SCIM or governed directory exports, and turn joiner, mover and leaver controls into a working operational process. The aim is straightforward: faster administration without mistaking a vendor workspace for the company’s source of truth.