OpenAI Ships Model Test, Codex Policy Audit Logs, Groups Admin API, and Group Managers for Enterprise Workspaces

OpenAI’s September 11 admin-control bundle is about proving access, delegating safely, automating groups, and preserving audit evidence

OpenAI’s September 11 release-note updates for ChatGPT workspaces add a practical administration layer for teams that already manage model permissions, Codex configuration, groups, and compliance logs at enterprise scale. The most visible change is Model Test in Admin Console, which OpenAI says lets an administrator select a member and see which models that member can access and which saved settings contribute to the result. In the same release window, OpenAI also says changes made through the Codex Policies & Configurations interface began appearing in workspace audit logs, and the Groups Admin API gained create, update, and delete operations for eligible workspaces.

The operational theme is not “more buttons.” It is a four-part control pattern that administrators can use to reduce ambiguity in large workspaces: diagnosis through Model Test, delegation through group managers, automation through the Groups Admin API, and auditability through workspace logs and the Compliance API. Each control addresses a different failure mode. Model Test helps answer “why can or can’t this person use a model?” Group managers let workspace owners and admins delegate selected day-to-day group administration without making every delegate a workspace admin. The Groups Admin API supports programmatic group lifecycle operations where the workspace is eligible and the Admin key has the right permissions. Codex policy audit events give security and compliance teams a source of evidence when managed Codex settings change.

The release is especially important for administrators who have been forced to troubleshoot model access by reading multiple configuration screens, identity-provider groups, role assignments, and workspace defaults. OpenAI’s documentation describes Admin Console visibility as dependent on the selected tenant, product resource, plan, and administrator role. That means an administrator may have authority in one part of an OpenAI deployment without having owner or admin access to every ChatGPT workspace, API organization, or Ads account. The new controls are useful only if teams keep those boundaries explicit instead of treating “admin” as a single universal permission.

This ChatGPT Enterprise deployment playbook explains how organizations roll out AI while retaining administrative control, giving readers the broader operating model in which role-based access, delegated administration, and managed permissions must function. The complete ChatGPT Enterprise Deployment Playbook: How to Roll Out AI Across Your Organization Without Losing Control article provides the destination-specific detail for this section’s OpenAI Enterprise RBAC decision because the target directly addresses controlled enterprise deployment and is a stronger RBAC companion than a workload-identity-only article.

What changed: concise admin-impact table

The diagnostic leg: Model Test reduces access disputes without changing access

Model Test is the cleanest example of the September 11 diagnostic pattern. OpenAI says it is available to administrators on ChatGPT Business, Enterprise, Healthcare, and Edu, and that it shows a member’s effective model access along with contributing workspace defaults, model permissions, roles, and preferences. In practice, that gives an administrator a faster way to distinguish a genuine provisioning defect from an expected result caused by a saved workspace setting, role assignment, model permission, preference, seat type, plan, or model eligibility boundary.

The most important operational warning is that Model Test is not an override mechanism. OpenAI’s release notes and help documentation make clear that testing a user does not grant a model, change permissions, change usage limits, override the member’s seat type, or bypass workspace-plan restrictions. An administrator should therefore treat a Model Test result as evidence for a change ticket, not as the change itself. If the result shows that a member lacks access because of a role or group configuration, the fix still belongs in the relevant role, group, model-permission, or workspace-default workflow.

A practical support workflow is to run Model Test before changing any setting, capture the effective-access explanation in the ticket, make the approved change through the correct admin path, wait for the saved setting to apply, and then run Model Test again. This sequence creates a defensible before-and-after record without implying that the diagnostic tool is the source of authority. It also prevents a common failure in large deployments: changing several unrelated settings at once because the administrator cannot see which setting is actually contributing to the access result.

The delegation leg: group managers distribute work without creating hidden admins

Group managers matter because model access, spend controls, analytics review, and role-permission editing often need local ownership. A central workspace admin team may not know which finance users need a default model, which research group needs a stricter access profile, or which departmental analytics should be reviewed weekly. OpenAI’s documentation says owners and admins can delegate selected responsibilities to group managers in Enterprise contexts, including group analytics, spend controls, model access/defaults, and selected role-permission editing.

That delegation is intentionally narrower than workspace administration. OpenAI’s documentation states that a group-manager designation does not make the person a workspace Admin or Owner, does not make the person a tenant User manager, and does not create unrestricted group-administrator authority. Group managers cannot create or delete groups or custom roles, appoint managers, change delegation, or grant themselves authority. For governance teams, that distinction is essential: group managers are a controlled delegation mechanism, not a workaround for promoting more administrators.

Administrators should also avoid treating a default model as an access grant. OpenAI’s group-management notes state that a default model does not grant access. The practical rule is simple: model availability and model default selection are separate controls. A group can be configured with a default model for users who are otherwise eligible and permitted to use it, but the default setting should not be expected to bypass a missing entitlement, plan boundary, role restriction, or model-eligibility rule.

The automation leg: the Groups Admin API extends lifecycle control, but only inside its workspace and key scope

The Groups Admin API update gives eligible workspaces programmatic create, update, and delete operations for groups. This is useful for organizations that already maintain departmental, project, regional, or cost-center structures in internal systems and need group lifecycle changes to follow approved operational processes. For example, a platform team might use an approved automation workflow to create a new group when a business unit launches, update its metadata when ownership changes, and delete it after retention and offboarding checks are complete.

The API does not erase eligibility, identity-provider, or credential boundaries. OpenAI’s documentation says Groups Admin API operations require an eligible workspace and a workspace Admin key with the necessary permissions. If group membership is SCIM-managed, membership remains managed in the identity provider. That means the API should not be positioned as a way to bypass identity governance or overwrite the system of record. It is better understood as a workspace administration surface that can be integrated with existing approval, change-management, and logging processes.

Workspace-scoped Admin keys are the credential boundary that makes this automation possible. OpenAI says these keys are available to eligible managed workspaces, require Owner or Admin access in the selected workspace, and authenticate supported ChatGPT and Codex administration APIs. Owners can create All, Read only, or Custom keys, while admins create custom-scoped keys. Admin keys are not API Platform project keys, do not perform model inference, do not control other workspaces, and do not grant tenant-wide authority. Any automation design that treats one Admin key as an all-purpose enterprise credential is over-scoping the control.

The article compares Falcon Guardian runtime detection with Codex Managed Configuration, framing managed configuration as preventive controls that define what enterprise Codex agents are allowed to attempt. The complete Falcon Guardian vs Codex Managed Configuration: Runtime Detection vs Preventive Agent Controls article provides the destination-specific detail for this section’s Codex Managed Configuration decision because it directly matches the Codex Managed Configuration marker and helps readers distinguish policy configuration from monitoring or incident response.

The auditability leg: Codex policy changes now leave workspace log evidence, with a 30-day export obligation

OpenAI says changes made through the Codex Policies & Configurations interface now appear in workspace audit logs. Authorized administrators can review those records in the Admin Console or retrieve them through the Compliance API, subject to appropriate permissions. This gives security and compliance teams a clearer evidence path when investigating who changed a managed Codex setting, when the change occurred, and which workspace context produced the record.

The scope must stay precise. The release note does not claim complete logging of every Codex action, every code operation, every agent step, or every repository event. The safe description is narrower: changes made through Codex Policies & Configurations are recorded in workspace audit logs. If an organization needs broader engineering telemetry, repository history, CI/CD logs, endpoint logs, or application-level traces, those systems still need their own collection, retention, and review processes.

OpenAI’s Compliance Logs Platform documentation adds an important retention constraint: compliance events are immutable and append-only, and the platform retains data for 30 days. Organizations that need longer retention must continuously export and retain logs under their own policies. For a regulated enterprise, that means the operational control is not merely “turn on log review.” It is a scheduled export pipeline, access-controlled storage, documented retention policy, and periodic verification that the export still captures the events the organization expects.

Key definitions: tenant, workspace, resource, role, group, Admin key, and Compliance API

Tenant

A tenant is the higher-level administrative context in which OpenAI Admin Console visibility is organized. OpenAI’s documentation says Admin Console visibility depends on the selected tenant, product resource, plan, and administrator role. A tenant user record should not be confused with ChatGPT workspace membership; a person can appear in a tenant context without automatically having the same access in each workspace or product resource.

Workspace

A workspace is the ChatGPT administration boundary where members, workspace roles, groups, model controls, Admin keys, and supported workspace logs are managed. A user with authority in one workspace should not be assumed to have authority in another. This matters when running Model Test, creating Admin keys, reviewing audit logs, or using the Groups Admin API, because each action must be evaluated against the selected workspace and the administrator’s role inside it.

Resource

A resource is the product-specific administrative object inside the broader OpenAI environment, such as a ChatGPT workspace, API Platform organization, or Ads account. OpenAI’s documentation warns that global-admin authority does not automatically grant owner or admin access to every resource. Administrators should document which resource a control applies to before interpreting access results or creating automation.

Role

A role is an authorization package that determines what a member or administrator can do in a specific context. In this release story, roles matter because Model Test can show role-related contributors to model access, group managers receive selected delegated powers rather than full admin rights, and Admin keys are created by Owners or Admins under workspace rules. Role names should not be reused casually across tenant, workspace, and API Platform contexts without verifying their documented meaning.

Group

A group is a workspace-level structure used to organize users for administration, analytics, spend controls, model access/defaults, and selected delegated management. In Enterprise and Edu contexts, groups are available, and Enterprise supports group-manager delegation. If membership is managed by SCIM, the identity provider remains the system of record for membership, so workspace automation must respect that boundary.

Admin key

An Admin key is a workspace-scoped credential for supported ChatGPT and Codex administration APIs in eligible managed workspaces. It is not a project API key for model calls, not a Codex service-account token, and not a tenant-wide master key. OpenAI’s documentation says Admin-key creation supports expiration choices, and existing expiration dates cannot be edited, so replacement should be deployed and verified before revocation when rotating a planned automation credential.

Compliance API

The Compliance API is the retrieval path for supported workspace compliance logs where the workspace and administrator permissions allow it. It should be treated as an export interface for immutable append-only events with a 30-day platform retention window, not as an indefinite archive. Teams with legal, regulatory, or internal retention obligations need their own continuous export, storage, access review, and evidence-preservation process.

Diagnosing model access without turning diagnostics into permissions

OpenAI’s Model Test belongs in an administrator’s troubleshooting workflow, not in the approval workflow itself. According to OpenAI’s release notes and Enterprise/Edu administration documentation, Model Test is available in Admin Console for ChatGPT Business, Enterprise, Healthcare, and Edu administrators, and it shows a selected member’s effective model access together with contributing settings such as workspace defaults, model permissions, roles, and preferences. The operational point is narrow but important: the test explains a saved access outcome; it does not create that outcome.

A practical Model Test run should start with three inputs that administrators can verify before interpreting the result: the selected workspace or tenant context, the selected member, and the saved configuration state that applies to that member. Admin Console visibility can vary by selected tenant, product resource, plan, and administrator role, so an administrator who can see one resource should not assume they can diagnose every ChatGPT workspace, API organization, or Ads account from the same view. A tenant user record is also not the same as ChatGPT workspace membership, which means the first troubleshooting step is confirming that the person is actually a member of the workspace where the access dispute occurred.

Model Test is most useful when support tickets are written as access questions rather than broad complaints. A ticket such as “User cannot access Model X in Workspace Y after Group Z rollout” gives the administrator enough context to test the member, compare the result with expected group and role assignments, and identify a likely contributing setting. A ticket such as “AI stopped working” should be triaged first into workspace, model, seat, plan, browser, network, and usage-limit possibilities before Model Test becomes the right tool.

The article provides a troubleshooting playbook for GPT-6 Astra rollout issues across ChatGPT Work and Codex, focusing on plans, allowances, permissions, CLI behavior, and app updates. The complete GPT-6 Astra Rollout Troubleshooting Playbook for ChatGPT Work and Codex: Plans, Allowances, Permissions, CLI, and App Updates article provides the destination-specific detail for this section’s Model Access Troubleshooting decision because it directly supports the model-access troubleshooting theme by focusing on entitlement, rollout, and permission checks when users cannot access a model.

How additive access sources complicate “remove the group” fixes

Model access disputes are often misdiagnosed because administrators look for a single switch. In governed workspaces, effective access can be the result of multiple contributing settings, including workspace defaults, model permissions, roles, preferences, and group-based administration decisions where groups are used. The practical consequence is that removing one apparent grant may not be sufficient if another saved setting still contributes to the same access result.

Administrators should describe model access as an effective outcome assembled from available sources rather than as a single field. For example, a member may appear in a group used for model access, hold a role that contributes relevant permissions, and inherit a workspace default that affects the model experience. If the access objective is to withdraw a model from that member, the administrator should use Model Test after each saved change to confirm whether another source still contributes to the outcome.

A default model deserves special handling because OpenAI’s group-management documentation states that a default model does not grant access. In practice, that means an administrator can set a model as a default for a group or workspace scenario, but the default cannot overcome a missing entitlement, an ineligible model, a plan boundary, a seat limitation, or a permission boundary. When a user says, “The default is set but I still cannot use it,” the administrator should test effective access rather than repeatedly changing the default.

Group-manager delegation is workload distribution, not hidden administration

OpenAI’s group-management documentation distinguishes workspace Owners and Admins from group managers. Groups are available in Enterprise and Edu, while group-manager delegation is available in Enterprise. Owners and admins can delegate selected responsibilities to group managers, but that designation does not make the person a workspace Owner, a workspace Admin, a tenant User manager, or an unrestricted group administrator.

The delegation model is useful because many access decisions are local to departments, projects, labs, programs, or cost centers. A security team may want central control over workspace roles and Admin keys, while a business-unit operations lead may be better positioned to review group analytics, adjust spend controls for that group, or request model defaults for a known team workflow. Delegation lets the organization move routine governance closer to the people who understand the work, while preserving administrative boundaries around group creation, manager appointment, and self-escalation.

OpenAI’s documentation identifies supported delegated areas including group analytics, spend controls, model access and defaults, and selected role-permission editing. These delegated permissions should be assigned deliberately, because each one creates a different operational risk. Analytics delegation exposes group-level usage insight; spend-control delegation can affect budget behavior; model access and default delegation can change who is offered or allowed to use certain capabilities; and role-permission editing, where supported and delegated, can have wider effects if the edited role is shared beyond the immediate group.

Shared-role side effects require a blast-radius check before delegation changes

Role-permission editing is the delegated area that most often needs additional change control. If a role is reused across groups, changing that role for one team’s request can alter permissions for other members who hold the same role. The safe operating assumption is that any shared role may have a broader blast radius than the manager’s immediate group, unless the administrator has verified otherwise in the workspace configuration.

A practical review should ask four questions before approving delegated role-permission editing: which role is being changed, which groups or members currently depend on it, whether a narrower custom role is needed, and who will validate the post-change Model Test results for affected members. If the delegated manager cannot answer those questions with evidence, the change should be escalated to a workspace Owner or Admin rather than implemented as a local adjustment.

Group managers also need a clear list of what they cannot do. OpenAI’s documentation states that group managers cannot create or delete groups or custom roles, appoint managers, change delegation, or grant themselves authority. Those restrictions matter because they prevent local delegation from becoming an uncontrolled privilege-escalation path. If a workflow requires those actions, the correct process is an owner/admin change request, not a workaround through role edits or identity-provider changes.

Recommended change note for delegated role-permission review

Change request:
- Group:
- Requested permission or role change:
- Business reason:
- Delegated manager:
- Workspace Owner/Admin reviewer:

Blast-radius checklist:
- Is the role shared outside the requesting group?
- Which members or groups currently hold the role?
- Does the change affect model access, spend controls, analytics, or administrative visibility?
- Has Model Test been run for a representative affected member before the change?
- Who will run Model Test after the saved change?
- What is the rollback plan if access differs from the approved outcome?

Approval rule:
- Do not implement privileged, broad, or irreversible changes without workspace Owner/Admin approval and recorded evidence.

SCIM boundaries: membership source determines where the fix belongs

SCIM-managed group membership remains managed in the identity provider. This boundary is especially important now that the Groups Admin API supports create, update, and delete operations for eligible workspaces, because administrators may be tempted to fix every group problem from the ChatGPT side. If membership is SCIM-managed, the durable correction belongs in the identity provider, not in an ad hoc workspace-side adjustment.

The first SCIM troubleshooting step is to identify whether the group’s membership source is manual or identity-provider-managed. If the group is manual, a workspace Owner, Admin, or appropriately delegated process may be able to correct membership inside the workspace, subject to role and feature boundaries. If the group is SCIM-managed, the administrator should inspect the identity-provider group, assignment rules, synchronization status, and the affected user’s identity attributes before expecting ChatGPT-side diagnostics to change the result.

Groups Admin API automation must respect workspace and key scope

OpenAI’s release notes state that the Groups Admin API added create, update, and delete operations for eligible workspaces. That does not mean every workspace can use those operations, and it does not mean any administrator credential can call them. The API requires an eligible workspace and a workspace-scoped Admin key with the necessary permissions. Workspace Admin keys authenticate supported ChatGPT and Codex administration APIs; they do not grant model inference, tenant-wide administration, access to other workspaces, API Platform organization authority, Ads account authority, or rights that exceed their configured scope.

The safest automation pattern is to create a narrow Admin key for the specific administration workflow, set an expiration that matches the organization’s credential policy, store it in a secret-management system, and monitor its usage through approved logs. OpenAI’s Admin-key documentation says Owners can create All, Read only, or Custom keys, while admins create custom-scoped keys. Creation supports Never, 30-day, 60-day, 90-day, or custom 1–365-day expiration options, and existing expiration dates cannot be edited. If a key must be replaced, deploy and verify the replacement before revoking the old key unless the key is suspected to be exposed or misused.

Automation should never be used to bypass delegation design. If group managers are responsible for local review but cannot create or delete groups, the automation should route those requests to a workspace Owner or Admin approval step rather than embedding broad credentials in a departmental script. A narrow workflow that creates groups only after ticket approval, records the approver, and validates the final state is safer than an all-purpose tool that lets local teams mutate groups without a durable governance trail.

Least-privilege review for model access and delegated administration

A least-privilege review should happen before rollout, after major organizational changes, and whenever support tickets suggest that access differs from policy. The review should start by mapping who can diagnose access, who can change access, who can delegate group authority, who can create or scope Admin keys, who can automate group operations, and who can retrieve audit evidence. These are separate powers, and combining them casually makes troubleshooting faster at the cost of accountability.

The review should separate diagnostic authority from change authority. An administrator may need Model Test visibility to resolve support cases, but that does not mean the same person should be allowed to modify group delegation, edit role permissions, or create broad Admin keys. Conversely, a group manager may be allowed to adjust model defaults or spend controls for a group, but that does not make them the right person to investigate compliance logs or tenant-level user records.

The final acceptance criterion for any diagnosis-and-delegation workflow is reproducibility. Another administrator should be able to read the ticket, see the member and workspace tested, identify the contributing settings, understand which person approved any change, and confirm that the post-change Model Test result matches the intended policy. If the evidence packet cannot support that review, the organization has not solved the access problem; it has only made an undocumented configuration change.

Automation and audit controls: making group changes repeatable and Codex configuration evidence defensible

OpenAI’s September 11 release notes turn group lifecycle work and Codex configuration governance into a more automatable control surface, but they do not remove the need to prove eligibility, scope credentials, and export audit evidence before the 30-day retention window closes. The practical enterprise reading is narrow: eligible workspaces can use the Groups Admin API for create, update, and delete operations, while changes made through the Codex Policies & Configurations interface now appear in workspace audit logs that authorized administrators can review in the Admin Console or retrieve through the Compliance API.

The first operational checkpoint is eligibility. OpenAI’s help materials state that groups are available in Enterprise and Edu, group-manager delegation is available in Enterprise, and workspace-scoped Admin keys are available to eligible managed workspaces. A tenant administrator should not assume that a tenant-level user record, a global-admin role, or access to one OpenAI resource automatically creates API authority over a ChatGPT workspace. Before writing automation, verify the selected tenant, the exact ChatGPT workspace, the workspace plan, the administrator role in that workspace, and whether the target workspace is eligible for the relevant Admin-key and group-management features.

For implementation planning, treat the Groups Admin API as a workspace-bound lifecycle interface rather than an identity-provider replacement. OpenAI’s group guidance preserves the boundary for SCIM-managed membership: if the group membership is managed by an identity provider, membership changes remain in the identity provider. The API can be useful for repeatable group creation, naming updates, cleanup, and policy-aligned administration in eligible workspaces, but a workflow that tries to override SCIM membership from the ChatGPT side is likely to create drift, failed changes, or confusing review evidence.

Workspace-scoped Admin keys are the gate for safe automation

OpenAI’s Admin-key documentation describes workspace-scoped Admin keys as credentials for supported ChatGPT and Codex administration APIs. The scope matters: these keys do not grant model inference, do not grant access to other workspaces, do not create tenant-wide authority, and do not apply to API Platform organizations or Ads accounts. That separation should be reflected in runbooks, secret inventories, and incident response procedures, because confusing an Admin key with an API Platform project key can lead to the wrong credential being rotated, revoked, monitored, or over-permissioned.

Owners and admins have different Admin-key creation powers. According to OpenAI’s help materials, Owners can create All, Read only, or Custom keys, while admins create custom-scoped keys. Where broad compliance and Conversation messages permissions are supported, OpenAI identifies those as owner-only. A least-privilege design should therefore assign routine group automation to a custom-scoped key with only the required permissions, reserve broad compliance exports for an owner-approved path, and document who approved the permission set before the key is created.

A practical key request should include the workspace name, the automation purpose, the specific supported API capability needed, the requested permission scope, the expiration choice, the storage location, the service owner, and the revocation trigger. The reviewer should reject requests that ask for “All” permissions because a script might need them later, that combine group mutation and broad compliance retrieval in one credential without a reason, or that omit the expected evidence trail for changes performed by the automation.

OpenAI’s Admin-key documentation states that creation supports Never, 30-day, 60-day, 90-day, or custom 1–365-day expiration. It also states that existing expiration dates cannot be edited. The safe operating pattern is to create a replacement key with the desired expiration, deploy it to the automation’s approved secret store, verify that the automation succeeds with the replacement, and only then revoke the old key. Revoking the old credential before the replacement is verified can turn a governance improvement into an avoidable outage.

Expiration policy should be matched to the blast radius of the automation. A read-only inventory job with narrow group metadata access may justify a different lifetime from a workflow that can delete groups or retrieve sensitive compliance evidence, but both should have named owners, monitored usage, and a calendar-driven rotation plan. If a key is suspected to be exposed or misused, planned no-downtime rotation no longer applies; the incident path should prioritize containment, revocation, replacement, evidence preservation, and review of downstream changes.

{
  "proposed_admin_key_record": {
    "workspace_scope": "ChatGPT workspace identifier recorded internally",
    "credential_type": "workspace-scoped Admin key",
    "purpose": "Groups Admin API automation for approved group lifecycle tasks",
    "permissions": "custom-scoped permissions approved by workspace Owner or Admin",
    "expiration": "30, 60, 90, never, or custom 1-365 days as approved",
    "storage": "approved secret-management system",
    "rotation_owner": "named operations owner",
    "revocation_rule": "revoke after verified replacement, suspected exposure, owner change, or automation retirement",
    "notes": "never store or transmit the real key in tickets, chat, repositories, or logs"
  }
}

The sample record above is a proposed internal inventory format, not an OpenAI API schema. Its purpose is to prevent a common audit failure: teams can often prove that a key exists, but cannot prove why it was created, who approved its permissions, where it is stored, when it expires, or what business process depends on it. That missing context makes both incident response and compliance review slower.

This enterprise AI governance guide examines Microsoft Purview and OpenAI built-in compliance capabilities, providing practical context for deciding how Compliance API records feed retention, investigation, and oversight workflows. The complete How Enterprise AI Governance Is Evolving in 2026: From Microsoft Purview to OpenAI’s Built-In Compliance Tools article provides the destination-specific detail for this section’s Compliance API Guide decision because the target is explicitly about enterprise compliance tooling and governance rather than an unrelated API security guide.

Designing Groups Admin API workflows that do not bypass approval

A safe Groups Admin API workflow starts with an authoritative source of intent. For many enterprises, that source will be an identity-governance ticket, an HR-driven access request, a data-owner approval, or a configuration repository reviewed by workspace administrators. The automation should translate approved intent into workspace group operations; it should not discover an inconsistency and unilaterally create, rename, or delete groups without a review rule.

The workflow should also separate destructive operations from routine updates. Creating a group and updating its description may be reversible with limited impact, while deleting a group can affect model defaults, model access, spend controls, analytics visibility, and delegated management relationships that depend on that group. A deletion job should therefore require a stronger preflight check: confirm the group is not SCIM-owned, confirm no active delegation or policy depends on it, capture the before-state, require an approval reference, and preserve the result in the evidence store.

1. Confirm that the selected ChatGPT workspace, not merely the tenant, is eligible for the Groups Admin API.
2. Confirm that the Admin key is workspace-scoped and has only the necessary custom permissions for the planned operation.
3. Determine whether the target group is manually managed or SCIM-managed, and send SCIM membership changes back to the identity provider.
4. Run a dry-run or preflight comparison in the automation layer before submitting any create, update, or delete operation.
5. Record the requester, approval reference, before-state, intended after-state, automation version, key identifier, timestamp, and result.
6. Send completed-change evidence to the same retention path used for workspace audit logs, while avoiding storage of secrets or unnecessary personal data.

The “key identifier” in that workflow should be an internal reference to the credential record, not the secret value. Logs should never include the Admin key itself, request headers, copied secrets, or unredacted troubleshooting dumps. If a developer needs to debug authentication, the safer pattern is to log whether the credential was present, which secret version was loaded, and which workspace the automation intended to target, while excluding the credential string.

Group-manager delegation deserves a separate control point because it can look like administration to business users while remaining deliberately constrained. OpenAI states that owners and admins can delegate group analytics, spend controls, model access and defaults, and selected role-permission editing, but the designation does not make the person a workspace Admin or Owner, tenant User manager, or unrestricted group administrator. Group managers also cannot create or delete groups or custom roles, appoint managers, change delegation, or grant themselves authority.

That boundary should be visible in automation output. When a workflow reports that a group manager was assigned, the evidence should say which delegated capabilities were included and which capabilities remain unavailable. This prevents business owners from assuming they can fix every downstream access issue themselves and prevents auditors from treating the delegation as a hidden administrator role. If a group manager requests broader authority, the request should move through the workspace Owner/Admin path rather than being handled as a routine group update.

Codex policy and configuration changes now have audit evidence, but the scope is specific

OpenAI’s September 11 release notes state that changes made through the Codex Policies & Configurations interface began appearing in workspace audit logs. The wording is important because it does not claim complete logging of every Codex action, every code-generation event, every repository interaction, or every service-account operation. Administrators should describe the new coverage as audit logging for Codex Policies & Configurations changes, and they should avoid expanding that description in policy documents unless OpenAI publishes broader coverage.

The immediate governance benefit is change accountability. A Codex policy change can affect how development teams use Codex in a managed workspace, so the audit record should be tied to change-management context: who requested the change, who approved it, what setting changed, what workspace it applied to, and what rollback condition was defined. The audit log is not a substitute for approval, but it is the evidence that a specific administrative change occurred.

Authorized administrators can review these audit records in the Admin Console or retrieve them through the Compliance API, according to OpenAI’s release notes and compliance documentation. Retrieval rights should be assigned carefully because compliance logs can contain sensitive administrative and user-context evidence. Where broad compliance and Conversation messages permissions are owner-only, teams should not route exports through a convenience account or a broadly shared administrator credential.

The article outlines three enterprise security checks before deploying ChatGPT Work, covering data governance, access control, and audit compliance. The complete 3 Enterprise Security Checks Before Deploying ChatGPT Work — Data Governance, Access Control, and Audit Compliance article provides the destination-specific detail for this section’s Enterprise Audit Logging decision because it directly reinforces the audit-logging marker with enterprise audit compliance and access-control context for regulated workspace deployments.

Compliance API retrieval and the 30-day export obligation

OpenAI’s Compliance Logs Platform for Enterprise and Edu is described as providing immutable append-only events with a 30-day retention period. The operational consequence is direct: organizations that need longer retention must continuously export and retain logs under their own policies. A weekly manual download is usually a weak control for regulated teams because outages, vacations, permission changes, or missed handoffs can cause evidence loss inside a short retention window.

A defensible export design should run on a schedule that leaves recovery margin inside the 30-day window. The export worker should authenticate with an appropriately scoped workspace Admin key, retrieve the permitted log data, write it to approved storage, record a checkpoint, and alert when no successful export has occurred within the organization’s defined threshold. The alert should go to both the platform owner and the security logging owner, because failures can be caused by credential expiration, permission changes, network controls, storage errors, or workspace administration changes.

Proposed export control loop:

1. Load workspace-scoped Admin key from the approved secret store.
2. Retrieve only the Compliance API log categories the organization is authorized to collect.
3. Write raw events to immutable or access-controlled evidence storage.
4. Record export checkpoint, event count, retrieval time range, and export worker version.
5. Forward normalized security fields to the SIEM without discarding the raw source record.
6. Alert if export fails, returns unexpected gaps, or approaches the credential expiration date.
7. Rotate the Admin key by deploying and verifying a replacement before revoking the old key.

The control loop above is a proposed workflow, not a statement of OpenAI endpoint names, payloads, or retention guarantees beyond the cited 30-day platform retention. It is written this way because evidence durability depends as much on customer-side scheduling, storage, and monitoring as it does on the availability of the Compliance API. If the export process fails for 31 days, the organization should assume that some workspace log evidence may no longer be retrievable from OpenAI.

SIEM handling should preserve two forms of evidence: the normalized event used for detection and the raw exported record used for investigation and audit. Normalization makes correlation practical, but it can remove fields that later matter, such as workspace scope, actor context, administrative action type, source system, retrieval time, or event identifiers. The raw record should be stored with restricted access, tamper-evident controls where available, and a retention period aligned to legal, regulatory, and internal policy requirements.

Security teams should resist the temptation to over-enrich logs with secrets or unnecessary personal data. The useful enrichment for a group or Codex configuration event is usually the workspace identifier, administrator identity reference, change ticket, owning team, affected group or policy area, credential record identifier, and severity label. The enrichment should not include Admin-key values, copied conversation content beyond what the organization is authorized to retain, or speculative conclusions about user intent.

Evidence packets for group automation and Codex configuration reviews

A reusable evidence packet gives auditors and incident responders a complete view without requiring them to reconstruct a change from chat messages and partial logs. For a group automation event, the packet should include the approved request, workspace scope, group identifier or name, operation type, before-state, after-state, automation job identifier, Admin-key inventory reference, operator or service owner, result status, and any linked identity-provider record if SCIM is involved. For a Codex policy or configuration event, the packet should include the audit-log record, the change request, the business justification, the approver, the affected workspace, and the verification step.

The packet should also document negative evidence when it matters. If a group was not SCIM-managed, record how that was determined. If a default model was changed for a group, record that the default does not itself grant model access. If a Model Test result was used to validate the impact, record that Model Test is diagnostic and reflects saved settings rather than granting access or changing usage limits. These notes prevent reviewers from drawing conclusions that OpenAI’s documentation does not support.

The final design rule is to make automation and audit mutually reinforcing. Groups Admin API jobs should produce change evidence that can be reconciled with workspace audit logs, while Compliance API exports should be monitored like production infrastructure rather than treated as a passive reporting feature. OpenAI has provided more administrative surface area for eligible workspaces, but the customer remains responsible for scoping credentials, preserving evidence beyond 30 days, and proving that privileged changes were authorized, executed, reviewed, and retained under policy.

Adoption plan: roll out the new controls without creating new privilege paths

Administrators should treat OpenAI’s September 11 controls as an operations upgrade, not as a single feature switch. Model Test improves diagnosis, group-manager delegation distributes routine administration, the Groups Admin API supports repeatable lifecycle work in eligible workspaces, and Codex policy and configuration changes now produce workspace audit-log evidence. Each control still depends on the selected tenant, workspace, plan, role, group design, Admin-key scope, and log-export process.

A practical rollout should begin with a boundary inventory. List each ChatGPT workspace, its Owners and Admins, the groups that affect model access, any SCIM-managed memberships, the people proposed as group managers, every workspace Admin key used for automation, and the team responsible for exporting compliance logs before the 30-day retention window expires. This inventory prevents a common failure mode: using a workspace-level tool to troubleshoot what is actually a tenant-selection, identity-provider, or plan-eligibility issue.

The article presents a Codex enterprise deployment playbook with prompts for team onboarding, access control, and usage governance. The complete The Codex Enterprise Deployment Playbook: 12 Prompts for Team Onboarding, Access Control, and Usage Governance article provides the destination-specific detail for this section’s Codex Service Account Governance decision because it best matches service-account governance because it focuses on Codex deployment discipline, access control, onboarding, and governance practices.

Phase 1: inventory, scope, and risk classification

Start with a two-week discovery phase for large workspaces and a shorter discovery phase for smaller teams. The output should be a control register that maps each group to its business purpose, membership source, delegated manager, model-access implications, spend-control implications, and administrative automation dependencies. Mark groups as identity-provider managed, manually managed, or mixed only if your governance process permits that classification; OpenAI’s group guidance makes clear that SCIM-managed membership remains managed in the identity provider.

During this phase, do not create new group managers or Admin keys. Use Model Test only to validate representative access outcomes for a sample of users: an Owner, an Admin, a standard member, a member of a model-restricted group, a member of a default-model group, and a user affected by multiple groups. Record what setting contributed to each result and whether the setting was saved before testing. Because Model Test is diagnostic, a passing result is evidence of current effective access, not approval to expand access.

Phase 2: delegate low-risk group operations first

After the inventory is complete, assign group managers only for groups with clear ownership and stable membership rules. OpenAI states that group managers are not workspace Owners or Admins, cannot create or delete groups or custom roles, cannot appoint managers, cannot change delegation, and cannot grant themselves authority. That makes group-manager delegation suitable for local operational oversight, but not for replacing workspace administration or identity governance.

The first delegated groups should be business-unit groups where the manager already owns the access rationale. Avoid starting with groups that control broad model availability, sensitive spend controls, regulated teams, executive access, or high-impact Codex workflows. For those groups, require an additional approval step from the workspace administrator and, where applicable, security or compliance before delegation is enabled.

Phase 3: automate repeatable group changes with constrained Admin keys

Only after manual delegation is stable should teams introduce Groups Admin API automation. OpenAI’s documentation ties the Groups Admin API to eligible workspaces and suitably scoped workspace Admin keys. A workspace Admin key authenticates supported ChatGPT and Codex administration APIs for that workspace; it does not provide model inference, tenant-wide administration, access to other workspaces, API Platform organization control, or Ads-account authority.

Use separate Admin keys for separate automation jobs where your process requires distinct ownership, review, and revocation. A provisioning workflow, a reporting workflow, and a break-glass remediation workflow should not all depend on the same broad key unless there is a documented reason and compensating monitoring. Owners can create all, read-only, or custom keys, while admins create custom-scoped keys, so key creation itself should be part of the ownership model.

Phase 4: operationalize Codex audit evidence and log export

Once Codex policy and configuration changes are visible in workspace audit logs, define who reviews them, how quickly they are exported, and how they are correlated with change tickets. OpenAI’s Compliance Logs Platform is described as immutable and append-only, with 30-day retention. Organizations that need longer retention must continuously export and retain logs under their own policies. A monthly export alone is not enough if a failed export would leave no time to retry before older events age out.

For regulated or high-change environments, set a daily export job and a weekly reconciliation report. The reconciliation should compare approved Codex policy-change tickets against exported audit events, identify policy changes without a matching approval, and identify approvals without observed implementation. Treat either mismatch as an operations exception, not as proof of malicious activity, until an administrator reviews the source records.

Access-review cadence and decision rules

The cadence should be risk-based, but it should not be informal. A workspace that uses Codex for production engineering, handles regulated data, or delegates group management across many business units needs shorter review intervals than a small workspace with stable membership and limited model variation. The strongest signal is not the number of users; it is the combination of privilege, automation, and business impact.

Control ownership matrix for administrators, security, identity, and audit teams

The matrix should be approved before automation starts. Without assigned ownership, an Admin key can become an orphaned control, a group manager can become an informal approver, and audit logs can become unread evidence. The accountable owner decides whether the control is appropriate; the operational owner executes; the reviewer verifies that the execution matches policy.

Test plan before broad deployment

1. Tenant and workspace selection test: Confirm administrators are operating in the intended tenant and ChatGPT workspace. OpenAI notes that Admin Console visibility depends on selected tenant, product resource, plan, and administrator role, so a test performed in the wrong workspace is not valid evidence.
2. Model Test baseline: Run Model Test for representative members and record the contributing settings. Include at least one user whose expected access is “not available” because a negative result is useful for proving restrictions.
3. Delegation boundary test: Assign a pilot group manager and verify the manager can perform only the delegated functions. Confirm the manager cannot create or delete groups, appoint other managers, change delegation, or self-escalate.
4. SCIM boundary test: Attempt membership correction through the approved identity-provider process for a SCIM-managed group, then verify the workspace reflects the change. Do not use workspace automation to override the identity source of truth.
5. Groups Admin API permission test: Use a custom-scoped workspace Admin key for a non-destructive or approved pilot operation, then verify that the key cannot perform actions outside its intended scope.
6. Codex audit-event test: Make an approved Codex Policies & Configurations change, verify the workspace audit-log record, export it through the compliance process, and attach it to the change ticket.
7. Retention test: Confirm exported compliance logs are stored outside the 30-day platform retention window under the organization’s retention policy.
8. Rollback test: Revert the pilot change through the approved path and confirm that the rollback produces the expected administrative evidence.

A successful test plan proves more than feature availability. It proves that administrators understand the boundary between diagnostics and authorization, delegation and ownership, API automation and key scope, workspace logs and enterprise retention, and Codex policy evidence versus broader engineering activity.

Exception workflow for urgent access and configuration changes

Exceptions should be rare, time-bound, and documented before they are implemented unless an active incident requires immediate containment. A valid exception request should name the affected workspace, group, member population, model or policy setting, business justification, risk owner, expiration date, rollback path, and evidence that will be collected after the change. If the request involves a SCIM-managed group, route membership changes to the identity provider rather than treating the workspace as the source of truth.

{
  "exception_type": "time_bound_admin_change",
  "workspace": "redacted-workspace-name",
  "affected_control": "group_manager_delegation_or_codex_policy",
  "business_reason": "approved operational need",
  "risk_owner": "named accountable owner",
  "approval_record": "change-ticket identifier",
  "start_time": "recorded by administrator",
  "expiry_or_review_time": "defined before implementation",
  "rollback_plan": "documented reversible steps",
  "evidence_required": [
    "admin approval",
    "before-and-after settings",
    "Model Test result if model access is affected",
    "audit-log export if Codex policy/configuration changed"
  ]
}

The exception record should avoid secrets, tokens, or unnecessary personal data. If an exception depends on a workspace Admin key, record the key name or internal identifier, scope, owner, and expiration status, but never record the secret value. Existing Admin-key expiration dates cannot be edited according to OpenAI’s Admin-key guidance, so a poor expiration choice should be corrected by creating a properly scoped replacement and revoking the old key after dependent workflows are verified or contained.

Evidence checklist for audits and post-change reviews

• Workspace and tenant identifier used by the administrator, with confirmation that the correct resource was selected.
• Change request, approver, business reason, affected groups, affected models, and affected Codex policies or configurations.
• Before-and-after screenshots or exported settings where permitted by internal policy.
• Model Test results for representative affected users when model access is part of the change.
• Group-manager delegation approval and confirmation that the delegated manager is not being treated as a workspace Admin or Owner.
• Identity-provider record for SCIM-managed membership changes.
• Workspace Admin-key scope, owner, expiration, and automation run record for API-driven group changes.
• Workspace audit-log entry for Codex Policies & Configurations changes and proof of Compliance API or other approved export.
• Retention proof showing that exported logs are preserved beyond OpenAI’s 30-day platform retention if the organization requires longer retention.
• Rollback result, exception closure, and reviewer sign-off.

This checklist should be attached to quarterly access reviews and to any high-impact change ticket. The point is not to accumulate paperwork; it is to make access decisions reproducible when a user disputes model availability, a manager changes roles, an Admin key is retired, or an auditor asks how a Codex policy changed.

Incident handling for suspected misconfiguration, unauthorized delegation, or key exposure

For suspected unauthorized model access, use Model Test to establish the current effective access and contributing settings, then preserve the result with the relevant group and role records. Do not “fix” the issue by removing random group memberships until you know whether the source is a workspace default, group rule, role, user preference, plan boundary, or identity-provider assignment. A rushed fix can remove legitimate access while leaving the actual source unchanged.

For suspected unauthorized group-manager action, freeze further delegation changes for the affected group, collect the delegation record, review recent group changes, and determine whether the manager acted inside delegated authority. Because group managers do not become workspace Admins or Owners, the investigation should focus on delegated permissions, approval records, and membership source rather than assuming tenant-wide compromise.

For suspected workspace Admin-key exposure, treat the key as a credential incident. Identify the dependent automation, create or activate a safe replacement only if doing so does not prolong exposure, revoke the affected key when containment requires it, and review API-driven group changes executed during the exposure window. Planned rotations can use verified overlap; suspected compromise requires prompt containment and should not wait for a perfect no-downtime migration.

For suspected unauthorized Codex policy or configuration change, preserve the workspace audit-log event, export it before the 30-day retention window closes, attach the approval or exception record if one exists, and compare the change against repository, CI/CD, and engineering governance records. OpenAI’s audit-log coverage for this release is scoped to changes through Codex Policies & Configurations, so absence of a particular Codex activity in that audit category should not be interpreted as proof that nothing happened elsewhere.

What this release does not establish

• It does not make Model Test an access-granting, limit-changing, or plan-overriding mechanism.
• It does not prove that every Codex action is logged; the release note concerns Codex Policies & Configurations changes appearing in workspace audit logs.
• It does not make group managers workspace Owners, workspace Admins, tenant User managers, or unrestricted group administrators.
• It does not allow group managers to create or delete groups or custom roles, appoint managers, change delegation, or grant themselves authority.
• It does not move SCIM-managed membership authority from the identity provider into ChatGPT workspace administration.
• It does not make the Groups Admin API available outside eligible workspaces or without a suitably scoped workspace Admin key.
• It does not turn workspace Admin keys into API Platform project keys, model-inference credentials, tenant-wide admin credentials, or Ads-account credentials.
• It does not remove the need to export compliance logs when an organization requires retention beyond OpenAI’s 30-day Compliance Logs Platform retention.
• It does not replace change approval, least-privilege design, incident response, legal review, privacy review, or internal audit.

The durable value of the September 11 administration bundle is operational clarity. Administrators can diagnose access with Model Test, delegate defined group responsibilities, automate eligible group operations with scoped Admin keys, and preserve evidence for Codex policy and configuration changes. The safe adoption pattern is to keep each control in its lane: diagnostics inform decisions, delegation distributes work, APIs execute approved workflows, and exported logs preserve evidence before retention windows close.

Useful Links

• OpenAI product release notes
• ChatGPT Enterprise and Edu release notes
• Managing your tenant in Admin Console
• Managing groups and group managers
• Managing Admin keys in Admin Console
• OpenAI Compliance Platform for Enterprise and Edu customers