Answer target
I just got a surprise bill from my API provider. What do I do first?
Updated June 25, 2026
Short answer
Assume a key is being actively used and kill it first: revoke or rotate before investigating. Then set spend limits, contact the provider about the unauthorized charges, work out where the key leaked from, and move the replacement somewhere that is not a readable file or a chat thread.
What to do now
The bill is a symptom of live, ongoing use. Every minute the key works, the number grows — cut access first, reconstruct events second.
- Revoke or rotate the key at the provider immediately; disable auto-recharge if the platform has it.
- Set a hard spend limit or budget alert before doing anything else.
- Email or file a ticket with the provider about unauthorized usage — refunds are discretionary but are granted, especially on a first incident.
- Check other keys on the same account; leaks rarely travel alone.
Better pattern
After recovery, make the leak path structurally impossible rather than promising vigilance: real keys out of repos, chats, and front-end bundles; per-project runtime grants for agents; a usage log you actually see.
Avoid
Avoid paying the bill quietly without rotating, deleting the repo or chat and assuming the key died with it, creating an identical replacement key with the same broad scope, or putting the new key back in the same .env or VITE_-prefixed variable that leaked the old one.
Example
A common shape: a key committed in .env or embedded client-side gets scraped within minutes, and the first sign is a four-figure usage bill or a suspended project. Rotation stops the meter; the provider ticket recovers what goodwill allows; runtime grants stop the rerun.
Give an agent safe access in minutes
- 1.Store the credential.
- 2.Create a named agent identity.
- 3.Grant the access it needs.
- 4.Resolve it at runtime.
- 5.Review the audit entry.
No card required.
Why you kill the key before investigating
Scraped keys are exploited by automation, not by someone reading your repo with interest. Usage continues while you investigate, and providers weigh how quickly you acted when deciding on refunds. Revocation is one click and ends the accumulation; every other step can wait ten minutes.
Getting the charges reviewed
Report the incident through the provider's billing support with the timeline: when the key leaked (if known), when you rotated, and which usage is not yours. Ask explicitly about unauthorized-usage credit. Outcomes vary — public accounts range from full refunds to one-of-twelve transactions credited — and speed of rotation is the strongest thing in your favor.
Finding the leak path
Most surprise bills trace to one of a few paths: a key committed to a public repo or its history, a key embedded in a client-side bundle, a key pasted into a chat or shared context, or a key an agent copied into a file or log. Knowing the path matters because it decides what you fix — git history needs scrubbing and rotation, client bundles need a server-side proxy, and agent workflows need runtime resolution instead of readable files.
After the first hour
Once the meter is stopped and the ticket is filed, spend the calm hour on structure: spend alerts on every billable provider, keys out of files and chats, per-project grants for agents so one leak can never again mean every project's keys, and an access log so the next anomaly is visible before the invoice.
Reading this because it just happened to you?
ScopeHold gives every key one home: paste it once, grant it to your coding agents per project, see everything they touched, and revoke in one click. Free tier, five-minute setup, no card.
Fix it in 5 minutesPractical workflow
- 1Kill the keyRevoke or rotate at the provider and disable auto-recharge. This stops the number growing.
- 2Cap the spendSet hard limits or budget alerts on the account before anything else.
- 3File the ticketReport unauthorized usage to billing support with your rotation timestamp and ask about credit.
- 4Trace and rebuildIdentify the leak path, scrub it, and move replacements to scoped runtime access with a log.
Key living where it leaked vs Scoped runtime access
Frequently asked questions
Will the provider refund unauthorized charges?
Sometimes, and more often on a first incident where you rotated quickly and reported promptly. It is discretionary: public accounts include full credits and partial ones. Always ask, include your timeline, and do not treat the refund as the plan — the rotation is the plan.
The key was only exposed for a few minutes. Am I safe?
Minutes are enough. Public repos and paste sites are scraped continuously by automation, and abuse frequently begins within minutes of exposure. Duration of exposure changes the odds, not the required response — rotate regardless.
How do I stop this happening again with coding agents?
Remove the precondition: real keys should not live in files an agent can read or chats it can see. Give each project's agent a scoped grant it resolves at runtime, with expiry and revocation, and keep a log of every access so unusual use is visible before billing is.
Want the key clean-up checklist?
Leave your email and Alan — the founder — will personally send you the exact rotate-isolate-grant steps from these guides. He might also ask you one question about your setup. No list, no spam.
Where ScopeHold fits
ScopeHold shrinks both halves of this incident: scoped per-project grants mean a single leak can no longer expose every key you own, and the access log means you see unusual resolution activity long before an invoice does the telling.