Answer target
How do I rotate an OpenAI API key after it was shared?
Updated June 25, 2026
Short answer
Treat the OpenAI API key as exposed. Create a replacement key with the narrowest permissions that work, update the legitimate application or agent workflow, revoke the old key, check recent usage, and avoid pasting the replacement key into another chat or .env file.
What to do now
If the key reached a chat, agent prompt, screenshot, repo, local file, or log, rotate it before continuing. Do not wait until there is confirmed misuse.
- Create a replacement key in the OpenAI dashboard.
- Use the least privilege and project separation available.
- Update the app, service, or agent workflow that legitimately needs it.
- Revoke or delete the exposed key.
- Review recent usage and billing for unexpected activity.
Better pattern
Store the replacement key once, then let named agents resolve it through scoped runtime access. The chat can describe which secret to use without containing the raw OpenAI API key.
Avoid
Avoid sharing user-owned OpenAI keys across teammates, pasting replacement keys into AI chats, or keeping duplicate copies in .env files, shell history, tickets, and notes.
Example
If a Codex agent needs an OpenAI key for a test harness, store the new key under the OpenAI provider, grant only that project secret to the Codex agent, and audit each resolve.
Try this with one key
- 1.Store one API key.
- 2.Create one agent identity.
- 3.Grant only that key.
- 4.Resolve it at runtime.
- 5.See the audit entry.
No card required.
What counts as an exposed OpenAI API key?
Treat an OpenAI API key as exposed if it was pasted into an AI chat, committed to a repo, stored in a shared .env file, printed in logs, shown in a screenshot, or copied into a tool transcript that may persist beyond the task.
Rotate before investigating
The safest response is to make the old key unusable first. Investigation can happen after the production or test workflow has been updated to a clean replacement key.
Replace with narrower access where possible
When creating the replacement key, prefer project-level separation and explicit permissions where available. Do not replace a leaked broad key with another broad key just because it is faster.
Prevent the next OpenAI key leak
The new key should not go back into the same chat, local file, or shared prompt. Move future agent access to named identities, project assignments, direct grants, runtime resolution, and audit events.
Practical workflow
- 1Create a replacementGenerate a new OpenAI API key with the permissions and project boundary your workflow needs.
- 2Update legitimate consumersReplace the key in the application, CI job, local runtime, or scoped credential layer that should use it.
- 3Revoke the exposed keyRemove the old key after the replacement path is verified.
- 4Clean up copiesSearch for the exposed key in local files, shell history, logs, tickets, documentation, and screenshots.
OpenAI key in chat vs OpenAI key in scoped custody
Frequently asked questions
Do I need to revoke an OpenAI API key after pasting it into AI chat?
Yes, if it can access a real account, project, or billable usage. Treat it as exposed and rotate or revoke it.
Can I share an OpenAI API key with a teammate?
Avoid sharing a user-owned key. Use account, project, or permission controls where available, and use a scoped credential workflow for agents.
What should I do if I lost an OpenAI API key?
Create a new key and update the legitimate application or runtime. Full secret values are normally shown only when created, so do not rely on retrieving the old value.
Where ScopeHold fits
ScopeHold lets teams store the replacement OpenAI key once, grant it only to the members and agents that need it, and audit reveal or runtime resolve events without putting the raw value back into chat.