Bounding the damage a leaked key can do

Most API keys do not leak in a dramatic way. They end up in a repository that later goes public, a log that gets pasted into a chat, a screenshot, a backup. Nobody attacks you. The key simply sits somewhere it should not be, and it keeps working.

With prepaid credits, a stolen key cannot spend more than the balance. That is a real bound and worth saying plainly. But "bounded by the balance" still means the balance, and it means you find out when the credits are gone rather than while they are going.

This week we added the part that notices.

What changed

• A cap on each key. A key can carry a spend ceiling. When the ceiling is reached that key stops, rather than draining the account behind it.
• A freeze when usage changes shape. If a key's spending moves far faster than its own history, it is frozen and further requests are refused.
• A freeze only a session can lift. Unfreezing is a deliberate act by a signed-in wallet, not a setting that quietly re-enables itself.
• An account-level pause, for when the problem is not one key.
• Alerts to a destination you configure, so a freeze is something you read about rather than something you discover later.

The detection runs on a schedule, five minutes apart, off the request path. That was deliberate: a customer's request must never fail because alerting failed, and a slow alert must never become a slow completion.

What this is not

It is not a security audit and it is not a guarantee. The limits deserve to be stated as plainly as the features:

• Velocity detection is a heuristic. Usage that ramps slowly enough, or that resembles ordinary traffic, can stay underneath it.
• A key without a cap is still bounded only by your balance. Set the cap.
• Alert delivery depends on the destination you give it. If that destination is wrong or unreachable, the freeze still happens and the alert does not arrive.
• A failed delivery is retried a small, bounded number of times and then abandoned. If the process dies mid-send, one alert can be lost. We would rather lose an alert than send the same one repeatedly.
• Caps are per key. They are not per model and not per application.

Where to see it

The Spend view shows each key's cap, the spend against it, any freeze currently in force, and the alert destination. Pricing is unchanged: usage is still charged from prepaid credits at the catalogue price, which is what the pricing page describes, and the request shapes are the ones the documentation already covers.

If a key of yours lives in a project you do not control, rotate it. A cap limits the damage. It does not undo a leak.