API Key Leaked? Rotation and Offboarding Runbook

If an API key leaks, disable it in the console first — a disabled key is rejected immediately and no other key is affected. Then create a replacement key with the same settings, deploy it, and filter usage by the old key and export a CSV to see which models were called and what it cost while exposed. Offboarding works the same way: disable the member, and every key under that member stops working at once; then deal with any department keys they created. This runbook covers the first 10 minutes, the preventive settings worth turning on today, an offboarding checklist, and how to confirm the result with the audit log and usage CSV.

The first 10 minutes after a key leaks

When a key turns up in a public repo, a chat thread, a screenshot or a log file, contain it first and investigate later.

Minutes 0–2, disable: find the key under API Keys in the console and disable it. It takes effect immediately and affects only that key. Once you are sure it is no longer needed, revoke (delete) it; deleted keys keep who deleted them, when, and their usage history for later review.
Minutes 2–5, rotate: create a new key with the same groups, quota, expiry, IP list and concurrency, and swap it into the services or config that used the old one.
Minutes 5–8, check usage: on the Usage page, filter by the leaked key and review request time, model, token counts and status across the exposure window to find when misuse began.
Minutes 8–10, keep evidence: export a CSV with the same filter (up to 50,000 rows and 400 days per file) and hand it to finance or security. Every row can be recomputed as official cost × discount ÷ exchange rate = amount charged; failed requests are not billed.

After these four steps, trace the source and check whether other keys created by the same person also need rotating. Every key shows its creator, and the Usage page can filter by key creator.

Recommended rotation order

For routine, non-urgent rotation, go new-before-old to avoid downtime:

Create a new key with the same configuration;
Deploy the new key to the service;
Filter usage by the old key and confirm no new requests arrive;
Disable, then revoke the old key.

Setting an expiry date turns routine rotation into something that has to happen; leave expiry blank only for keys that should never expire.

Preventive settings: limit what a leaked key can do

You cannot rule out a leak, but you can cap the worst case in advance. Each key has its own settings:

Setting	What it does	Recommendation
Key quota	Maximum USD the key can spend; once used up, requests are rejected before processing (HTTP 402 `insufficient_quota`)	Set to one month of normal usage for that service, plus a small margin
Expiry	The key stops working on that date	Always set for temporary work, contractors and CI tests
IP list	Restricts which IPs can use the key	For production services, list your egress IPs, one per line
Groups (1–10)	The key can only call models in its groups; `GET /v1/models` returns them	Include only the groups the workload needs, so a leaked key cannot reach other models
Concurrency	Caps simultaneous requests	Keep it low on batch keys so a leaked key cannot be used for bulk calls

Three organisation-level safeguards on top:

One key per service: a leak stops one service, not all of them;
Member and department quotas: even a key with no quota of its own is capped by its member's and department's quota for the period;
Balance alerts: set several thresholds on your available balance so an email and in-app notice flag unusual spend early.

For setting up members, departments and three-level quotas, see team API key management for LLMs; for the full evaluation list, see the enterprise AI API security checklist.

Employee offboarding checklist for API keys

On the employee's last day, in this order:

Disable the member under Team → Members. Every key under that member stops working immediately.
Find department keys they created: some keys belong to a department rather than a member (for example, a production service they maintained). Check the creator in the key list, or filter usage by key creator, and rotate each one.
Export their final period: filter by member and export the CSV for settlement and department allocation.
Reassign roles: if they were a department manager, appoint a new one; if they were an enterprise admin, the owner revokes the admin role.
Delete the member (optional): their sign-in is disabled and all their keys are deleted, permanently. Usage history and records are kept and remain visible under Removed members.
Rotate shared config they had seen: any service key they could read in plain text, rotate new-before-old as above.

Confirm with the audit log and usage CSV

Doing the work is not enough; you need to show it was done and that it took effect:

Audit log: organisation changes, member changes, quota and permission changes and key operations are all recorded and searchable by time and object. The owner and enterprise admins can view it to confirm who disabled which key or member, and when.
Usage CSV: every request records model, token counts, latency and status. Filtered by the old key or the departed member, there should be no successful, billed requests after the time you disabled them.
Test the old key: call GET /v1/usage with it and confirm it is no longer usable (this endpoint is judged by is_active; see the balance and quota reference).

What you investigate is billing metadata: prompts and outputs are used only to complete the request, not retained as business data and not used for training. All traffic uses TLS.

FAQ

My API key was leaked. Is deleting it enough?

Disable it first, deploy a replacement key with the same settings, then filter usage by the old key and export the CSV to check spend during the exposure. Deleting without checking leaves you blind to the damage and to other keys the same person created.

How do I revoke API keys when an employee leaves?

Disable the member and every key under them stops working at once. Then filter by key creator to find department keys they created and rotate each one. Deleting the member also deletes their keys; usage history is kept.

How can I see when a key was used and which models it called?

Filter the Usage page by that key to see each request's time, model, token counts, latency and status, and export it as CSV. Key creation, edits and disabling are in the audit log, searchable by time and object.