Incident response
I Pasted an API Key Into ChatGPT. What Should I Do?
A practical incident-response checklist: revoke the key, inspect usage, replace it safely, and prevent the same mistake next time.
If you pasted a real API key into ChatGPT, treat the key as exposed. Revoke or rotate it first, then check usage and replace it everywhere that legitimately needs it. Deleting the chat is not a substitute for invalidating the credential.
The short response plan
- Revoke or rotate the exposed credential.
- Create a narrowly scoped replacement.
- Update the applications and jobs that used the old key.
- Check usage, billing, and audit logs for activity you do not recognize.
- Search for other copies in logs, tickets, shell history, and repositories.
- Document what happened if the key belonged to a company or customer environment.
That order is deliberate. People often spend twenty minutes inspecting the chat, debating provider retention settings, or trying to decide whether the key was “really” compromised. During those twenty minutes, the credential is still live. Rotation closes the door. Investigation tells you whether anyone walked through it.
1. Revoke the old key at the source
Go directly to the service that issued the credential. For an OpenAI API key, use the API Keys page in the OpenAI platform. For AWS, disable or delete the access key in IAM. For GitHub, revoke the token in Developer settings. Stripe, Twilio, SendGrid, and most other providers have equivalent controls.
Do not merely rename the environment variable or delete the value from your local .env file. The provider validates the credential itself, not the variable name on your laptop. The old value remains usable until it is revoked, disabled, expired, or otherwise made invalid.
OpenAI's own API key safety guidance recommends rotating a key immediately if you believe it leaked and reviewing account usage for signs of misuse.
2. Replace it with less privilege than before
A rotation is also a chance to reduce the blast radius. If the provider supports project-scoped keys, restricted tokens, expiration dates, IP restrictions, or spending limits, use them. A key used by one staging job should not also have access to every production project.
Create the replacement, store it in your secret manager or deployment platform, and update only the systems that need it. Avoid posting the new key into a team chat or ticket while coordinating the fix; that simply creates the next exposure.
3. Check whether the key was used
Once the old key is dead, inspect the provider's usage dashboard, billing page, and audit logs. Look for calls outside your normal time window, unfamiliar models or endpoints, unusual locations, new resources, or spending that does not match your applications.
What “unusual” means depends on the key. For an AI API, it may be a sudden token spike. For AWS, inspect CloudTrail for actions made with the access key ID. For GitHub, review token activity and repository access. For a payment provider, involve the person responsible for security and finance rather than treating it as a harmless developer mistake.
4. Find the other copies
The ChatGPT prompt may not be the only place the credential appeared. Ask how it reached the prompt. Was it copied from a terminal? Included in an error trace? Stored in a support ticket? Committed to Git? Pasted into Slack before it reached the AI chat?
Search the places where that workflow leaves traces:
- Git repositories, including commit history and pull-request comments
- CI logs and deployment output
- Shell history and copied debugging commands
- Issue trackers, support tools, and internal chat
- Application logs and screenshots
If the secret was committed to Git, deleting it in a later commit does not remove it from earlier history. Rotation is still the immediate fix. History cleanup is a separate task, and on a shared repository it should be coordinated because rewriting history can disrupt other contributors.
5. Should you delete the ChatGPT conversation?
You can delete it as a cleanup step and follow your organization's incident policy, but do not confuse deletion with revocation. A credential is a bearer secret: possession may be enough to use it. The only reliable way to make the pasted value harmless is to invalidate it at the issuing service.
If the prompt also contained customer data, health information, source code, or internal documents, the incident is broader than one API key. Escalate according to your company's privacy and security process. This article is a practical checklist, not a substitute for legal or incident-response advice.
How to prevent the same mistake
The boring controls work: keep secrets in a secret manager, do not print them into logs, add .env to .gitignore, enable repository secret scanning, and give production credentials the narrowest possible permissions.
If the exposure started with a configuration file, use the .env sanitization checklist before sharing another debugging prompt.
The browser is still a gap. People paste logs into ChatGPT because it is useful, and a policy that says “never paste anything” tends to fail under deadline pressure. A practical control is to remove sensitive values before the request is sent.
You can do that manually with our free AI Prompt Sanitizer, or use OmniShield to detect and mask matching API keys and PII automatically in supported AI chats. Either way, test with fake values first and inspect the request yourself. Our Network tab guide shows exactly how.
A simple rule to remember
If a secret reached a service where it did not belong, assume exposure, rotate it, and then investigate. That response may feel conservative, but it is cheaper than discovering unexpected usage after the next billing cycle.