Contain a leaked key before it drains the budget
Enterprise Tier
A leaked credential lands in a public repository, and an attacker spends a few hours mining it before the security team notices. A runaway integration is doing the same damage with no attacker at all. Either way, money is leaving right now, and the response has two halves: bound the damage immediately, then cut the credential off entirely.
Persona: Platform operator, usually paged by a spend alert, a usage-review surprise, or a security notification.
Estimated time: Minutes; this is an incident runbook, not a project.
Outcomes
By the end of this guide:
- A compromised or runaway key is revoked, immediately and irreversibly.
- The role of a pre-set rate limit as a damage bound before revocation lands is understood.
- A workload can be paused deliberately, short-term or long-term, without ambiguity about the mechanism.
Prerequisites
- Administrator access to the Admin Dashboard, with permission to manage API keys and users.
- The key-revocation mechanics from Onboard developers and issue keys.
Revoke the key
The fastest response is to revoke the key from the Admin API Keys surface; the mechanics are covered in Onboard developers and issue keys. Revocation is immediate and irreversible: the very next request on the credential is rejected. Reissue a replacement key to the owning team once the incident is understood.
Why the rate limit already mattered
A rate limit set at the key's normal traffic level is the damage bound that holds before anyone is paged: even if the revocation is delayed by minutes or hours, the limit caps the worst-case burn in the interim to a multiple of normal traffic instead of an unbounded mining run. Setting limits proactively on every production key, not just experimental ones, is partly a cost story and partly a security story; the practice is covered in Stop runaway workloads before they burn the budget.
Pause a workload deliberately
Not every containment is an emergency. For a planned pause (a maintenance window, a vendor escalation, or a budget freeze), the mechanism is the same: revoke the API key and reissue when the pause ends. There is no "disable temporarily" state on a key; revocation is the available mechanism, and the developer team coordinates with the operator on the timing.
For longer-term pauses, the user account itself can be marked inactive in the Users surface, which prevents further activity until the account is reactivated.
Close the loop
After containment, two follow-ups keep the incident from repeating: confirm the revocation and any limit changes are visible in the audit trail (Audit Agent Router activity) with the incident reference attached, and check whether an alert would have caught the spike earlier than it was actually caught; if not, the missing rule is described in Get alerted to cost spikes as they happen.
Where to go next