OpenAI has connected enterprise identity groups to API Platform access. That closes an invitation gap, but it does not make old API keys disappear.
OpenAI API Platform SCIM is now generally available for tenant-wide SCIM customers. Enterprise and Edu global admins can assign synchronized identity-provider groups to API organizations and selected projects through Product access in Admin Console. Managed users receive access without accepting an invitation, and membership updates as group assignments change.
The access path has four separate layers
| Layer | What it proves | What it does not prove |
|---|---|---|
| Tenant identity | The person is a managed user in the enterprise tenant. | The person should access every OpenAI product. |
| Synchronized group | The identity provider places the person in a governed group. | The group has been assigned to an API organization or project. |
| Organization membership | The person can enter the assigned API organization. | The person can access every project or secret. |
| Project access | The person can use a selected project under its role and policy. | Previously issued credentials outside that membership are revoked. |
Keeping these layers distinct prevents a common audit error: reporting that an employee was removed from a project while a service account, copied secret or external deployment still has working credentials.
Design groups around work, not org charts
A department-wide group is easy to maintain and often too broad. Prefer groups that express a stable access purpose, such as API billing administrators, production model operators, evaluation-project contributors or security auditors. Separate organization access from elevated project roles.
- Give each group an owner and review date.
- Document which API organization and projects it grants.
- Record the intended role, not only membership.
- Avoid nested-group assumptions until they are tested in the actual identity provider and SCIM path.
- Keep break-glass administrators outside ordinary automated removal, with separate monitoring.
Run the joiner, mover and leaver test end to end
| Event | Expected result | Evidence to keep |
|---|---|---|
| Joiner added to group | Organization and selected project access appears without an invitation. | Identity-provider event, SCIM result and API audit record. |
| Mover changes team | Old project access is removed and new access is added. | Before-and-after memberships and role comparison. |
| Role change | The effective project role matches policy. | Role test using a non-production account. |
| Leaver removed | Managed membership disappears within the expected window. | Removal timestamp and failed access attempt. |
| Group unassigned | SCIM-managed access from that assignment is removed. | Assignment change and resulting membership diff. |
| Identity provider outage | Known fail behavior and alerting activate. | Runbook result and owner notification. |
Key revocation is a second workflow
SCIM governs memberships that it manages. An API key may be stored in a deployment platform, local environment, CI system or vendor integration. A leaver test should therefore trigger a credential inventory, not stop at a successful group removal.
- List keys and service accounts associated with the person’s projects.
- Identify which secrets are personal, project-scoped or externally copied.
- Revoke or rotate credentials according to the change risk.
- Update dependent systems and confirm they use the replacement.
- Search logs for post-removal use of retired credentials.
- Close the offboarding record only after both membership and secret checks pass.
Service accounts need named owners
Human group synchronization does not replace service-account governance. Every non-human identity should have an owner, purpose, project, rotation schedule and disable path. Do not place a production service identity into a human team group merely to make onboarding easier.
Break-glass accounts should be rare, strongly authenticated and monitored. Test them without weakening the ordinary least-privilege path, and review their use after every activation.
A pre-production validation sequence
- Create one test organization and two projects with different sensitivity.
- Assign one synced group to the organization and only one project.
- Add and remove a test user at the identity provider.
- Measure propagation time in both directions.
- Test a nested group, if your design depends on it.
- Change a role and verify effective permissions rather than the admin label alone.
- Remove the user and separately test a previously issued development key.
- Export the logs needed to reconstruct every change.
OpenAI’s release note confirms the assignment and membership behavior. It is not a complete security architecture or an independent audit of a customer’s identity configuration. Organizations remain responsible for group design, key lifecycle, logging and downstream systems.
Our multiple-account permission guide covers provenance inside interactive ChatGPT. SCIM solves a different enterprise problem: centrally managed membership for API organizations and projects.
The practical verdict
API Platform SCIM replaces manual invitation handling with identity-provider-driven access for Enterprise and Edu tenants. That is a meaningful joiner-mover-leaver improvement. A complete control still needs project-role tests, break-glass handling, service-account ownership and a separate process for keys that may outlive human membership.
Primary source
Checked September 18, 2026. Product scope and group-assignment behavior come from OpenAI. Lifecycle, key-rotation and break-glass tests are MustHave.ai analysis.
