Accidentally Pasted an API Key into ChatGPT? A Safe Response Checklist

You meant to ask an AI assistant why an API request was failing. While pasting the error message, you accidentally included an API key, password, or another credential. What should happen first?

The priority is to make a real exposed credential unusable at the issuing service, not to ask the chatbot to forget it. Then assess what the credential could access, check usage, and handle copies in chats or attached files. A clearly fictional placeholder is different from a production token.

This procedure focuses on credentials entered into ChatGPT, whether issued by OpenAI, GitHub, a database, or another service. Entering a credential does not prove it was publicly disclosed or abused. The guide draws on official OpenAI and GitHub documentation reviewed October 26, 2026, not on a live test of a private account.

First, classify the secret without copying it again

Identify the credential’s issuer, owner, and type using approved records or the provider’s settings. Do not paste it into another model or an online key checker.

• Active API key or access token: Can authorize calls or other operations. Rotate or revoke an unapproved exposure through its issuer.
• Account password or session credential: Follow the affected service’s password and session-security procedure. Changing an API key is not a password reset.
• Database or cloud credential: Notify the authorized infrastructure owner; determine which systems and permissions it covers.
• Demo placeholder: A deliberately nonfunctional value such as \[EXAMPLE\_KEY\] needs no revocation.
• Unknown string: Ask the credential owner to classify it without sharing the full value.

A token-like string is not evidence of actual unauthorized use. But a valid key should not be considered safe merely because the chat looks private. Check whether sending it was permitted under the issuer’s and your organization’s rules.

Contain the credential before deleting the conversation

A real credential’s continued validity is usually the immediate risk. Work in the provider’s security or credential dashboard, not in ChatGPT’s answer box.

1. Stop reproducing the secret in prompts, screenshots, tickets, repositories, or chat messages.
2. Identify the responsible service and whether the credential is for production, staging, or development.
3. Alert the authorized security or account owner if you cannot revoke it yourself.
4. Revoke or rotate it according to the issuer’s incident procedure, prioritizing any highly privileged active credential.
5. Note the credential identifier and action time, not its secret value.
6. Check usage and relevant saved copies after the immediate authorization risk is contained.

OpenAI’s account-security guide tells users to delete a potentially compromised OpenAI API key, review usage, and contact support. GitHub’s secret-scanning guidance recommends updating dependent services, replacing exposed tokens, and reviewing security logs when available.

These sources describe different providers. Neither lets an AI assistant revoke a third-party credential just because it appeared in a prompt.

Rotate an OpenAI API key safely

If it was an OpenAI Platform API key, sign in to the Platform account or project that owns it and locate the API key controls. Delete the affected key, create an appropriately permissioned replacement, and update authorized applications that used the original.

OpenAI’s API key safety guidance recommends scoped permissions, expiration, credential rotation, and secrets stored outside source code. Avoid including new keys in client-side JavaScript, mobile apps, public repositories, or another AI conversation.

For an ordinary planned rotation, a team may create a replacement, deploy it, verify its operation, and then revoke the old key. Suspected compromise changes the priority: waiting for a perfect, zero-downtime cutover may leave a credential active. Follow the organization’s emergency containment plan, including escalation when necessary.

Record which deployments were updated and whether the issuer confirmed revocation. A redacted identifier or masked suffix may be acceptable evidence under your policy; an image showing the full key is another leak.

If you pasted a password instead

A password is not interchangeable with an API token. Change it at the relevant service and use its supported session-management controls when unauthorized access is possible. For OpenAI accounts, the official security documentation describes reviewing security history, active sessions, and logging out devices. It also recommends unique passwords and multifactor authentication.

If the exposed password was reused, change it at each affected service, using a different unique value. If the exposed item was a private key, recovery code, or session cookie, follow that issuer’s specific containment procedure; a standard password change may not invalidate every credential type.

Be precise in reporting: “The password was included in a chat” and “An attacker used the password” are different claims. The latter needs independent evidence.

Review account activity and usage

Once the credential is contained, inspect the issuing provider’s authorized records. OpenAI tells API users to review usage for unexpected activity and contact support about suspected misuse. GitHub recommends checking security logs when available.

Ask five questions: When might exposure have begun? When was revocation confirmed? What resources were in scope? Were there unexplained API calls, billing changes, sign-ins, or deployments? What logs are unavailable?

Unexpected usage deserves escalation, but a usage spike alone does not identify its cause. Normal usage also cannot prove that nobody copied the secret. Record your observations, the provider, and the relevant time zone without inventing certainty.

Do not ask the chatbot to validate a live credential by sending it the original key. Use the provider’s account dashboard or an authorized security team instead.

Delete the ChatGPT conversation only after containment

To remove the affected conversation from your account view, find it in ChatGPT history, open its more-options menu, select Delete, and confirm. An organizational incident process may require securing approved evidence before removal.

Archive is not delete. According to OpenAI’s chat deletion documentation, archiving hides a chat from the regular sidebar but retains it. Deleting removes the chat from the account view immediately and schedules permanent deletion from OpenAI systems within 30 days, with documented exceptions for security, legal obligations, and applicable workspace policies.

Deleting an old conversation does not revoke the API key at its issuer. It cannot establish that copies never existed elsewhere. Do not describe deletion as an immediate, universal erasure guarantee.

If you are subject to an organizational retention or investigation requirement, follow its authorized evidence-handling rules rather than deleting records contrary to policy.

Check Library files, projects, and shared content

If the credential was in a screenshot, pasted configuration file, uploaded log, or project attachment, review the file itself as a separate item.

OpenAI’s retention documentation explains that a file saved in ChatGPT Library is managed separately from the conversation that used it. Deleting a chat does not delete its separately saved Library files. Delete a relevant Library copy through Library controls where permitted.

Files used by projects and custom GPTs have additional retention rules. Shared conversation links and saved recipient copies also create separate exposure questions. Do not assume that deleting one conversation removes the original file from an external cloud drive or repository.

Locate each relevant copy, who controls it, and the approved removal procedure. Avoid blindly deleting unrelated projects or records to address a single paste.

Fictional example: a staging key in an error report

Imagine a developer copied a test-service error report into ChatGPT. The note included a working staging key, although the intended question was only why an API call was rejected. The token is not reproduced here; this is an original fictional exercise.

The safe, redacted version of the diagnostic note is:

Environment: staging
Request outcome: authorization failed
Credential value: [REDACTED]
Observed at: 2026-10-26 10:20 KST
Expected result: approved test request succeeds

The authorized owner determines from provider records that the key was active. They revoke it, configure a replacement with limited permissions, update staging, and review available usage. They also identify the ChatGPT conversation and separately saved attachments for the appropriate deletion and retention process.

A defensible incident statement is:

A working staging credential was entered into a ChatGPT conversation. The credential owner revoked it and updated the staging service. Review of provider activity is ongoing; unauthorized use has not been established.

This does not claim the key was made publicly searchable, used by an attacker, or erased from every system. The facts do not establish those conclusions.

Keep confirmed facts separate from unresolved questions

The two columns prevent a containment milestone from turning into an unsupported promise. If you have no provider logs, write “not verified,” not “no unauthorized use.”

Copy a minimal incident template

Store this only in an approved, access-controlled incident system. The template deliberately excludes credential values:

Incident ID: [INTERNAL_ID]
Observed at: [TIME AND TIME ZONE]
Credential type: [API KEY / PASSWORD / OTHER]
Issuer and owner: [PROVIDER / AUTHORIZED ROLE]
Environment: [PRODUCTION / STAGING / OTHER]
Exposure surface: [CHAT / FILE / SHARE]
Secret value: DO NOT RECORD HERE
Revocation: [CONFIRMED / PENDING / UNKNOWN]
Replacement deployment: [CONFIRMED / PENDING / N/A]
Usage review: [EVIDENCE / UNAVAILABLE]
Saved copies: [CHAT / LIBRARY / PROJECT / SHARES]
Escalation contact: [AUTHORIZED ROLE]
Open questions: [ONLY UNVERIFIED FACTS]

If forensic preservation is required, let the incident-response owner decide where protected evidence belongs. Do not create a second exposure by attaching the original token to a broadly visible support ticket.

Prevent the next leak without hiding the symptom

Before sending a log to any AI assistant, work from a sanitized copy. Remove authorization headers, API keys, cookies, session IDs, connection strings, private keys, passwords, and unrelated personal information. Keep the meaningful error, endpoint category, non-sensitive configuration, and reproducible steps.

Prefer fictional fixtures for tutorials. Store live production keys in approved secret management, and avoid embedding them in front-end code or committing them to Git. Automated scanning can help detect secrets in repositories but is not a substitute for reviewing prompts.

A better troubleshooting question is: “What non-sensitive evidence would distinguish an expired API key from a missing permission?” The assistant can suggest tests without receiving an active credential.

Close the incident by checking distinct outcomes

Do not conflate these outcomes:

1. Containment: The issuing provider confirmed the exposed credential was made unusable.
2. Restoration: Approved workloads use a safe replacement where needed.
3. Investigation: Available usage or security records were reviewed, with uncertainty recorded.
4. Data handling: Relevant chats, saved files, projects, and shares were addressed under applicable retention rules.
5. Prevention: The workflow now removes secrets before content reaches an AI tool.

Revoking a token reduces future misuse but does not erase historical copies. Deleting a conversation helps manage retained data but does not invalidate a provider token. A successful replacement deployment does not prove there was no earlier misuse.

Bottom line: If a live credential entered ChatGPT, secure that credential at its issuer first. Then check activity and saved copies, and record what was verified rather than declaring the problem fixed because the conversation disappeared.

Official references

• OpenAI — Keeping your OpenAI account secure
• OpenAI — Best practices for API key safety
• OpenAI — Deleting and archiving chats in ChatGPT
• OpenAI — Chat and file retention in ChatGPT
• GitHub Docs — Resolving alerts from secret scanning