By Greg Nowak. Last updated 2026-08-24.
AI platforms are becoming easier to administer through code. OpenAI’s API Platform now exposes administrative operations for users, groups, roles, projects and spend controls. Anthropic provides administration APIs for Claude Console and Claude Enterprise, although the available resources differ between those environments.
That is useful progress. It does not answer the most important governance question: should this person have access?
An admin API can enforce a decision quickly, but the decision still needs to come from authoritative identity data and an accountable business owner. Without that foundation, automation simply makes inconsistent access faster and more repeatable.
The API applies decisions; it does not own them
A platform can report that an account exists, belongs to a group or holds a role. It cannot establish that the person still works for the company, has moved to another team or retains a genuine business need.
Employment status may originate in HR, while contractor status comes from a supplier or procurement process. The identity directory should bring those governed signals together and present the population that downstream systems can trust. The AI workspace is the enforcement point, not the employment register.
This distinction matters during offboarding. Removing someone from the corporate directory but leaving a manually created AI account untouched creates a gap. Conversely, deleting every inactive AI user can remove legitimate access from people who use the service infrequently. Identity status and usage are different signals.
Map the control boundaries before choosing endpoints
Do not treat a company email domain as one administration boundary. Inventory each tenant, workspace, API organisation and project separately. Record who owns it, which population may enter, how users are provisioned and where exceptions are approved.
The product boundaries are real. OpenAI’s API documentation distinguishes organisation and project resources, including groups, roles and project spend controls. Anthropic’s documentation distinguishes Claude Console from Claude Enterprise: each environment exposes a different subset of members, workspaces, groups, spend and reporting operations.
For every boundary, identify both the authoritative source and the controlling system. A group may be maintained directly in the platform or supplied through SCIM. Those cases require different remediation paths.
| Question | Trusted input | Safe response |
|---|---|---|
| Should this person be present? | Governed directory population | Invite, retain, remove or raise an exception |
| What should they access? | Role rules and approved groups | Reconcile groups and roles |
| Who controls this group? | SCIM or platform ownership metadata | Change it only in the controlling system |
| Has a mover retained old access? | Current department, role and contract data | Remove obsolete access before adding new access |
| Does usage justify a review? | Cost and activity reporting | Request review; do not infer employment status |
Give every account and group one provisioning authority
Current OpenAI group records indicate whether a group is SCIM-managed and therefore controlled by the identity provider. Anthropic similarly marks groups as direct or SCIM-sourced, and its Enterprise Admin API does not allow SCIM-controlled groups or their membership to be changed through the platform API.
These restrictions are helpful. They prevent two systems from competing over the same record.
Classify every account and group as directory-managed, platform-managed or explicitly excepted. An exception should have a named owner, reason and expiry date. “It was already there” is not an acceptable ownership model.
Avoid quietly mixing manual invitations, just-in-time creation, SCIM and custom scripts. If more than one route can create the same account, document which route governs deactivation. Otherwise a leaver may disappear from one group while remaining active through another provisioning path.
Build reconciliation before full automation
A useful first release is usually a read-only reconciliation job, not an automatic deletion service. The workflow should:
- Fetch the approved directory population and every relevant platform boundary.
- Normalise stable identifiers, using email only when no better shared identifier exists.
- Classify differences as missing, unexpected, incorrectly privileged, pending or excepted.
- Produce a proposed change set with the reason and controlling system for each action.
- Route destructive changes and privilege increases through explicit policy checks.
- Record the input snapshot, decision, API result and correlation identifier.
Run this in report-only mode first. Review the output with IT and the business owners who understand why access exists. Once the classifications are reliable, automate low-risk actions and keep ambiguous cases in an exception queue.
The process should also be idempotent: running it twice against the same state should create no further changes. Pending invitations, pagination, rate limits and partial API failures need deliberate handling rather than blind retries.
Separate visibility from change authority
Reporting jobs rarely need write access. Use read-only or narrowly scoped credentials where the platform supports them, and keep mutation credentials in a separate workload. Anthropic offers distinct member and group scopes; OpenAI exposes granular administrative resources and roles that can support a similarly focused design.
Rotate credentials, avoid tying production automation to a person’s workstation and alert on failed or unexpectedly large change sets. Usage and spend data can help identify dormant seats or unusual consumption, but access removal should still follow an identity or business decision.
The real deliverable is an operating model
The API integration is only one component. A dependable result includes mapped environments, authoritative identity inputs, group rules, scoped credentials, dry runs, audit records and an exception process with named owners.
Greg can help inventory the administration boundaries, reconcile users and groups, connect SCIM or governed directory exports, and turn joiner, mover and leaver requirements into a workflow your team can operate. If the platforms are ready for automation but the ownership model is not, that is the right place to start.
Related on GrN.dk
- Not Every AI Job Needs an Instant Answer: Batch the Backlog
- OpenAI Computer Use: Browser Agents Need Credentials, Not Demos
- AI Agents Need a Spending Brake, Not Just a Billing Dashboard
Need help with this kind of work?
Talk to Greg about AI administration Get in touch with Greg.
