You Pasted an API Key Into an AI Chat. Now What?

You pasted an api key into an ai chat. The good news is that this is a rotation problem, not a privacy problem, and rotation problems have an ending. A credential can be revoked, which makes it worthless wherever it has travelled. Leaked customer data cannot be revoked. Treat the next twenty minutes as a key rotation, not an incident investigation, and you will be finished before you would otherwise have finished reading the vendor's privacy policy.

Do the revocation first. Everything else, including deleting the chat, is secondary and some of it does not help at all.

Revoke before you tidy up

The order matters because the exposure clock and the cleanup clock are different. Deleting the conversation reduces how long the text sits in the vendor's systems. It does nothing about the eight minutes it has already been there, and nothing at all about a key that still works.

Anthropic's consumer retention documentation is a fair illustration of the gap. Deleting a chat removes it from your history immediately, but it is "deleted from our back-end storage systems within 30 days". And the exception is the part people miss: inputs and outputs flagged by automated trust and safety systems are kept "for up to 2 years", with classification scores kept for up to seven. You cannot know from the outside whether your message tripped a classifier. Rotate the key and the question stops mattering.

Rotate in the order a leak requires, not the order the docs give

Cloud providers publish a careful zero-downtime rotation procedure, and it is the wrong procedure here. AWS's documented sequence is to create a second key while the first is still active, update all applications, check whether the old key is still in use, and only then deactivate it, advising that you "wait several days and then check the old access key for any use before proceeding".

That is correct for a planned rotation and dangerous for a leak, because every day of that careful migration is a day the compromised key still works. Invert the middle of it:

1. Create the replacement credential. AWS allows "a maximum of two access keys per user", which is exactly enough to do this without an outage window.

2. Deactivate the leaked key immediately, rather than after a waiting period. Deactivate rather than delete, so you can reactivate for sixty seconds if something critical breaks and you need a moment to repoint it.

3. Find what broke and repoint it to the new credential. Things will break, and that is the fastest inventory of where the key was used that you will ever get.

4. Delete the old key once nothing has failed for a day.

Keep the deactivate-before-delete habit from the published procedure. It is the one part that applies unchanged, because a deactivated key can be turned back on and a deleted one cannot, and AWS notes a secret access key "can be retrieved only at the time you create it".

Then check whether it was used

Rotation stops future misuse. It tells you nothing about the window you have already lived through, and that window is what determines whether this was a near miss or something you have to tell someone about.

Most providers expose a last-used timestamp or an access log. AWS documents get-access-key-last-used for precisely this question, and recommends CloudTrail for monitoring key usage alongside CloudWatch alarms on denied attempts. Compare the last-used time against the minute you pasted. A key last used by your own application an hour before the paste, and not since, is a near miss. Any use you cannot account for is a different conversation.

Do this check even when you are confident. It takes two minutes, it is the only evidence you will have, and it is the difference between "we rotated it" and "we rotated it and confirmed no unauthorised use".

Which credentials need which response

The bottom row is why the distinction at the top of this article matters. A pasted key is recoverable in twenty minutes. Pasted personal data is a different class of problem, and it is the one worth having a policy for in advance: the runbook for an employee pasting confidential data into AI starts where this article ends.

An OAuth refresh token deserves its own note. Rotating the client secret does not necessarily kill an issued refresh token, so revoke the grant itself in the provider's console. Otherwise the token keeps minting access tokens against a secret you believe you have replaced.

Now delete the chat, and know what that does

Deletion is still worth doing. It removes the text from your own history, where the next person using your screen would find it, and it starts the vendor's backend deletion clock. Read your own provider's retention terms rather than assuming, since the periods differ and the training-data question is separate from the storage question.

What deletion does not do: unsend the message, remove it from a training run already in progress, or clear a copy retained under a trust and safety exception. Deleting your AI chat history covers what actually goes and what stays, and if you are setting policy for a team rather than cleaning up after yourself, how long to keep AI chat logs is the companion question.

Stop it happening again

One habit prevents most of these: never paste a configuration file whole. The paste almost always happens because someone wanted help with a config error and sent the entire file, keys included. Send the error and the three relevant lines with the values replaced by placeholders.

The structural fix is short-lived credentials. A token that expires in an hour converts this whole article into a shrug. AWS's own guidance leads with it, recommending temporary credentials such as IAM roles "instead of creating long-term credentials like access keys".

Worth knowing that agents and coding assistants widen the surface here, because they read files you did not choose to send. That is a different exposure with the same ending, covered in whether an AI coding agent can leak your API keys, and it sits alongside the other practical AI risks worth planning for rather than reacting to.

FAQ

Do I need to tell anyone?

If the credential was only ever yours and the logs show no unauthorised use, there is usually nothing to report beyond your own team's process. If it belonged to a client, or the logs show use you cannot account for, say so early. The cost of a late disclosure is much higher than the cost of an awkward one.

Does it matter if the chat was in incognito or a temporary mode?

It reduces retention and training exposure, and it still does not revoke the key. Treat the mode as a mitigation on the cleanup side only.

The key was in a screenshot rather than text. Same answer?

Yes. Models read text in images, and the file is stored either way. The rotation is identical.

Is a rotated key really safe, even though the text still exists somewhere?

Yes, that is the whole point of the distinction. Once revoked, the string is a dead password. The remaining question is only whether it was used before you revoked it, which the access logs answer.