How a Leaked API Key Turns Into a Bill You Didn't Spend

Credential leaks used to mean someone could read data they should not. With metered model APIs, a leaked key is closer to a stolen card number: possession is spending power, the meter runs in someone else's hands, and the first notification is often the usage graph rather than a security alert.

The leak paths are mundane. A key committed to a repository, including in a file deleted in a later commit but still present in history. A key pasted into a browser-based tool, a notebook, or a chat with a colleague. A key shipped inside a mobile or desktop app, where it can be extracted from the binary by anyone sufficiently curious. A key in a CI log that prints its environment on failure. A key in a screenshot. Automated scanners watch public code hosts continuously for exactly these patterns, and the window between a key appearing publicly and being used is routinely minutes.

What makes model APIs sharper than old credentials is the combination of high per-call cost and no natural ceiling. A leaked key for a read-only database endpoint has limited resale value. A leaked key for a frontier model is immediately useful to anyone who wants free inference, and it can be spent in parallel, around the clock, until something stops it.

The defences that work are structural rather than behavioural. Set a spending cap at the provider, which is the one control that puts an actual number on your worst case. Use separate keys per application and per environment, so a leak is a revocation rather than an outage. Prefer short-lived or scoped credentials where the provider offers them. Keep keys in a secrets manager or the platform's own environment configuration rather than in files that can be committed, and add a pre-commit secret scanner so the mistake is caught locally. Turn on whatever usage alerting exists, set it low enough to notice an anomaly rather than a disaster, and check that the alert reaches a human quickly.

Never put a model API key in client-side code. If a browser or an app needs model output, the call belongs behind an endpoint you control, where you can authenticate the user, rate-limit them, and keep the key server-side. This is the single most common architectural mistake, and it converts one leaked key into unlimited free usage for anyone who opens developer tools.

If a key does leak, the order is: revoke first, investigate second. Rotate the key immediately rather than after you have worked out the blast radius, because every minute of analysis is billable to you. Then pull the provider's usage logs for the period, look for calls you cannot account for, and contact support with specifics; providers will sometimes credit clearly fraudulent usage, and specifics make that conversation shorter.

The general lesson is worth internalising beyond AI. Any credential that can spend money should be treated as money, with the same caps, separation and revocation habits you would apply to a card, not the casual handling that read-only API keys got away with for years.