# What to do about a stolen AI API key

A leaked AI key is spent fast. It turns up in a public repository, a client-side bundle, a CI log or a shared notebook, and within hours someone is running image and video models on it around the clock. A provider's monthly spend cap stops everything at a total for the whole account, often days later, and can't tell your traffic from theirs.

## Tell it apart from a busy day

Look at the key's usage by the hour and by model, at the provider or in your monitoring. The signs of a stolen key are:

- a key nobody had used for weeks suddenly spending;
- models the key has never run, often image, video or the largest text models;
- spend around the clock, at a steady rate, outside your traffic's daily shape;
- spend your own requests don't account for, when you track which key each request used;
- a key whose owner has left the company.

One sign is worth a look. Two together, especially a dormant key running new models, usually means the key is out.

## Shut it off

1. **Disable or delete the key** at the provider: OpenAI and several others can only delete keys, while Anthropic, Google Cloud, AWS and others can disable and re-enable them. If you don't know what else uses the key, disabling is safer where the provider offers it.
2. **Replace it** wherever your own services used it, from your secret manager, and redeploy.
3. **Check the other keys** in the same project or account: whoever found one may have found more.
4. **Find the leak**: search your repositories, CI logs and front-end bundles for the key's prefix, and rotate anything else that sat beside it.

## Ask for the money back

Providers consider refunds for unauthorized usage case by case, and they ask for the same things: which key, when it started and stopped, what it ran, and proof the traffic wasn't yours. Gather, before you write to the provider's support:

- the key's id or name and the time you disabled it;
- hour by hour, what the provider billed for that key, by model;
- the same hours from your own records, showing what your code actually sent;
- how it leaked, and what you've changed since.

Keep the claim open until the provider answers, and record the credit when it arrives.

## Keep it from happening again

- **Give keys owners**, so a departed engineer's keys are found and closed.
- **Close dormant keys**: a key unused for 30 days is one nobody would miss.
- **Restrict keys** to the projects and models they need, where the provider allows it.
- **Watch each key by the hour**, not the account by the month, and alert on the signs above.
- **Keep keys out of client code** and out of anything that gets logged.

## With Veqen

Veqen reads each provider's usage per key, matches it with the calls your own code made, and opens an incident with the reason when a key spends in a way nobody on your team did, usually within the hour. Owners and security hear about it in email, Slack or their SIEM, can shut the key off from the alert, and get the hour-by-hour evidence for the refund claim in one file. Start with the [free audit](/audit) of the last 30 days, or read how [protection](/docs/protection) works.