I leaked an API key. What now?

Make the leaked key stop working before you do anything else. Get a new one from whoever issued it, put it where your app reads its settings, and check that service's usage for anything you don't recognise. Only then go looking for every copy. Deleting the file, message or line doesn't delete it from history, logs or the other person's screen.

This is for anyone who lets an AI agent build or run their business tools, and has just seen an API key or password somewhere it shouldn't be.

The first steps, in order

1. Make the old key stop working. In the issuing service's own settings, revoke it or replace (rotate) it. This is the step that matters: you don't know who has already read it, but you do control whether it still works.
2. Get a new key and put it where your app reads its settings, usually an environment variable on your computer or your host. Never paste it into a chat, including a chat with your agent.
3. Look at that service's usage or billing for anything you don't recognise since the leak. If you see something, tell the service.
4. Then find where else a copy could be. Your agent can search for you (see the prompt below). Clean up what you can.
5. Set a spending limit on the service if it offers one, and write down what happened and what you changed, so the next time is quicker.

Some apps break for a minute when the old key stops working. That's expected: the new key fixes it. A short outage is better than a key that still works for someone else.

Where keys usually leak

More often than you'd think, it isn't a file somebody wrote. Keys get out through:

• Web addresses. A key in a link ends up in the host's logs and the browser's history.
• Logs and error messages. An app that writes out a whole error can write the key with it.
• Chats and support tickets. Once sent, it has arrived.
• Old versions of files. Git keeps every version, so deleting the file today leaves it in yesterday's.
• Caches and copies: backups, build output, another computer it was copied to.

Two of these happened on my own system: a shared secret pasted into a support chat, and sign-in tokens written into logs. In the second, my agent fixed our app's own logs and said plainly in the same message that the host's logs still caught the token. That's worth copying: if your agent calls a fix partial, it is partial. Write the open half down.

What to ask your agent

Replace the key yourself first. Then paste this, so your agent finds the copies without changing anything:

A key or password of mine was exposed. It appeared here: <where it turned up, e.g. pasted into a chat, in a log, inside a web address>. I have already replaced it.

Don't change, delete or rewrite anything.

1. List in plain English every place a copy could still exist in this project and on the services it uses, including old versions in version control, logs and error reports.
2. For each one, tell me whether I can delete it myself, can only wait for it to expire, or have no control over it.

Stop when you've given me that list. Don't edit anything until I say so.

Practise once while nothing is wrong

Pick one key, the least important, and replace it today: make a new one, put it in your app's settings, revoke the old one, check the app still works. The first time is the slow one. Doing it calmly now means doing it quickly when it counts.

I'm Tim. I run a tent company and build my software with AI. See what Dorris does, or build it yourself.

If you use the Dorris kit

The kit's app starts with a read-only connection to your store, so a leaked store key could let someone read your orders and customer details, though as it's shipped it changes nothing in your store. Replace it anyway, straight away. Can this break my store? explains what it touches, and Something broke covers a leaked key along with the other usual problems.

This is general information, not legal or security advice for your situation.

Tim Haines