A workflow may depend on an API key created by the staff member who originally configured it. Restricting future key creation does not establish who owns that existing integration or how it will recover when the responsible person changes. The useful review therefore starts with an inventory of operational ownership and current credentials, rather than assuming a new policy solves every legacy dependency.
This article provides a proposed key-ownership review checklist. It does not instruct an administrator to change live controls or revoke credentials immediately. The organisation's security and operational owners approve the actual policy and migration. No real key value belongs in the review worksheet, article, chat or shared evidence pack.
Understand what the September control changes
Source: OpenAI API changelog records the September 2026 addition of API key creation governance. The accepted source recheck identifies the entry dated 15 September. Treat that as a dated capability reference, not proof that a particular administrator has already configured the intended policy.
Source: OpenAI production best practices explains that administrators can allow only service-account keys, allow only user-owned project keys or disable new key creation. Organisation restrictions take precedence, and project settings can add restrictions without loosening them. The guide explicitly states that these controls apply to new creation and existing API keys are unaffected.
That distinction matters operationally. A future service-account-only policy can coexist with an existing staff-owned key until the organisation separately reviews it. Disabling new creation is not equivalent to revoking current credentials, reducing their permissions or demonstrating that every workflow has a responsible owner.
Inventory the integration before judging ownership
Create one record per actual integration, with a stable workflow ID and responsible business owner. Record the OpenAI organisation/project reference, credential identifier or secure secret reference, ownership type, runtime locations and permitted operational purpose. Keep the secret value in the reviewed secret-management path, not in the inventory.
Identify scheduled workers, web applications, local scripts and third-party connectors that use the credential. A key label alone may not reveal all consumers. The technical owner should verify the actual deployment references through an authorised read-only process and record unknown consumers as unresolved rather than assuming the obvious application is the only one.
Distinguish provider ownership from operational responsibility. A key can be associated with a user while another team operates the workflow. A service account can still lack a clear recovery owner. The review should identify who can approve access changes, rotate credentials, pause the workflow and investigate failed operations.
Compare policies against the accepted operating need
A service-account-only creation policy may support an organisation's intended integration ownership model, but it is not a universal recommendation for every environment. A user-owned policy or restricted creation process may fit another accepted model. Security owners should decide based on actual roles, access and recovery requirements.
Check the organisation-level rule before evaluating a project's choice. A project setting cannot loosen an organisation restriction. Document the accepted policy and its scope rather than relying on a screenshot that lacks the organisation context. Verify current administrator permissions and supported settings before any later change is proposed.
Separate governance of creation from permissions of an issued credential. A key's ownership type does not establish least privilege by itself. The actual integration also needs appropriate allowed operations and data scope under the organisation's accepted design. Do not infer that a service account makes every tool action safe.
Reusable key-ownership review checklist
Use this proposed checklist to prepare an administrator and operational-owner review. It contains references and decisions, never secret values.
| Review field | Required evidence | Decision to record |
|---|---|---|
| Integration identity | Stable workflow ID, purpose and business owner | Is it still needed? |
| Credential reference | Secure reference/identifier, project and ownership type | Existing key or proposed new key? |
| Runtime consumers | Accepted deployment locations and unknown references | Which consumers must be covered? |
| Governance scope | Organisation rule and project rule/version | Effective creation restriction |
| Operational authority | Access approver, rotation owner and recovery backup | Who can act under the accepted process? |
| Permissions | Actual permitted operations and data scope | Appropriate or needs separate review |
| Legacy status | Existing ownership and unresolved dependency | Keep, migrate or retire under an approved plan |
| Test evidence | Non-sensitive runtime verification and failure handling | Can the workflow recover predictably? |
| Migration decision | Accepted target, sequence and rollback limits | No live change implied by this worksheet |
Before accepting the review:
- Account for each known integration and name an owner for unknown consumers.
- Show the effective organisation/project creation rule without assuming it alters legacy credentials.
- Distinguish credential ownership, operational responsibility and actual permissions.
- Record the approved next step for every existing staff-owned credential.
- Use a separate tested rotation or retirement plan before changing live secrets.
- Preserve the decision and evidence references so another administrator can understand the intended state.
The completion check is a traceable ownership decision for each integration, with unresolved dependencies visible. Merely choosing a new-key policy does not complete the legacy review.
Walk through a new policy and an old worker
Consider a hypothetical organisation that accepts service-account-only creation for future integrations. A nightly worker currently uses an existing user-owned project key. Under the documented new-key control, that old key is unaffected. The review records its current owner, actual worker consumers and the person responsible for migration. It does not claim the policy already converted the worker to a service account.
Now suppose the project's local preference allows user-owned creation but the organisation rule permits only service accounts. The effective restriction follows the organisation rule. The review identifies that precedence and asks the administrator to confirm the intended project policy; it does not propose bypassing the organisation control.
An ambiguous legacy reference creates a different case. Two applications use the same secret label but the owner cannot establish whether they point to one credential or separate versions. Keep that dependency unresolved and verify the secure references before proposing rotation. Similar labels should not justify revoking a key that might support another workflow.
A duplicate inventory entry can be linked when the accepted workflow and credential references establish identity. A genuine second consumer remains in the inventory even if it uses the same key. Removing it as a duplicate would hide a migration dependency.
Review action authority independently of key labels
Source: OpenAI function calling describes application execution of model-requested functions. The integration's application should enforce accepted action permissions independently of how its API key was created. A model request must not acquire broader authority because the credential is service-account-owned.
Evaluate the inventory and policy decision with synthetic references for a new integration, a legacy worker, an unknown consumer and a staff handover. Check that the worksheet reveals operational dependencies without exposing secrets. Any later live migration needs its own authorised, tested plan and actual readback; this article's review does not prove that change occurred.
Questions about key ownership governance
Does service-account-only creation revoke staff-owned keys?
No. The official guide distinguishes new creation controls from existing keys, which are unaffected. Review current credentials separately and use an approved migration or retirement plan where needed. Do not treat a creation-policy change as proof that legacy access has ended.
Can a project permit a key type the organisation forbids?
The documented organisation restrictions take precedence. A project can add restrictions but cannot loosen the organisation rule. Record both scopes when reviewing the intended policy, and verify the actual administrator settings rather than inferring them from the project label alone.
Is key ownership enough to make an integration well governed?
No. The review also needs actual consumers, permissions, operational owners and recovery procedures. A service account with broad access or no accountable owner still raises unresolved design questions. Keep ownership type as one field in the wider accepted integration record.
If your business needs help defining this process, explore Custom AI agents, the wider AI automation services, and our custom-agent workflow guide. The agents and automation comparison and custom AI agent glossary explain the terms. To discuss your records and approval rules, get in touch.