Guides · Guides
Respond to a leaked key
Every key is refused everywhere from the next request after its revocation, with no way back. The right gesture depends on which key leaked.
| Leaked | Do this | Then |
|---|---|---|
A secret key (sk_) | Revoke it: revoke_key from the agent, or the API keys screen — no human needed, no grace | Create a new one from the API keys screen (a human) and update your server |
A publishable key (pk_) | It is public by design; leaking it exposes nothing that the access presets do not already allow. If it is being abused (rate limit, form spam), rotate it with revoke_previous: true — rotate_key from the agent — or revoke it and create a new one from the API keys screen | Update the front end |
The account key (ak_) | Account → Revoke, then Generate | Put the new value in your agent's configuration; if the remote connector held it, install the connector again |
| A function's key | Revoke its fn:<slug> entry from the key list: it is refused from the next request on, and the function loses its data access | rotate_function_secret: a new key is injected for you. Used alone, it lets the old key be accepted for up to 10 minutes |
| A provider key set as a secret (Anthropic, Stripe…) | Revoke it at the provider: that is where the old value stops working | Set the new value where the old one was — the account's Secrets screen, then Apply the rest until every function has it; or a project's Manage → Secrets |
| A browser identifier | Account → Browsers → Unlink that browser | Sign in again on that browser if it is yours |
| A dashboard session | Sign out; if the account's e-mail is at risk, turn on two-factor authentication | — |
What to check afterwards#
The request log records every request under the id of the key that made it (key_id), never its value — for a project key, the id the key list shows. Filter the Logs screen or get_logs on the period of the leak: the management plane for an account key, data for a project key; get_logs also filters on the key_id. Rotations create a new key id, so the two values of a rotating key are two ids. Entries written before the fix of 2026-09-19 carry an id the key list does not show.
What a leak cannot do#
A leaked sk_ opens one project, not the account. A leaked ak_ opens the projects in its scope, but cannot: read a secret key's value, create one, delete a project or a user, export, change an app URL, open a non-empty table to the public, set a secret's value or manage the account's shared secrets — every one of these needs a signed-in human. A leaked key cannot fabricate a dashboard session.
Keep the account key in your agent's configuration only — never in an app, never in a repository. The GitHub deployment workflow needs no key at all.