Respond to a leaked API key

A key gets committed to a public repository, pasted into a ticket, or shipped inside a client bundle. This is the procedure for the minutes that follow, and for the question that comes after them: what was done with it while it was exposed.

First: contain it

1. Identify the key and its gateway

   A Salyro key belongs to exactly one gateway. Establishing which gateway tells you the whole extent of the exposure straight away — which provider credentials the key could reach, and whose traffic and costs are affected.

2. Issue a replacement on the same gateway

   A gateway can hold more than one active key, so the replacement can be issued and deployed while the leaked key is still live. Its value is shown once, when it is issued.

3. Deploy the replacement

   Update the environment holding the key and confirm requests are succeeding with the new one.

4. Revoke the leaked key

   Revocation takes effect immediately and cannot be undone. The key stops working from that point, and nothing that held it keeps working.

The steps are in that order for continuity. If the exposure is public and current — a key in a public repository, or one you have reason to think is being used — invert the first two: revoke immediately, accept the interruption, and replace afterwards. An outage is recoverable; spend against your provider accounts is not.

What the leak could and could not reach

This is worth establishing before you write the incident up, because the answer is narrower than it first appears.

• It reached one gateway. Not the account, and not your other gateways. A Salyro key does not work against a gateway other than the one that issued it.
• It could spend against that gateway's provider credentials. This is the real cost of the leak: requests made with the key were served against your own provider accounts, and the provider will bill them.
• It could not read your provider keys. A saved provider credential is never returned by Salyro, through any path. Holding a Salyro key does not expose the OpenAI, Anthropic, Gemini or Grok key behind it.
• It could read nothing back from other gateways. Logs, conversations and usage belong to the gateway that produced them.

Then: establish what happened

The gateway's request log is the record of what the key did. Every request carries its time, the model and provider it went to, its token counts, its computed cost, its status and its latency, so the window between the leak and the revocation can be read directly rather than estimated.

Two things to know while you are doing this:

• Logging is asynchronous. Records are written on a separate path from the request itself, so a very recent request may take a moment to appear. This matters when you are reading the log during the incident rather than after it.
• A single view is bounded, the record is not. Nothing deletes a business log or a conversation on a schedule, so an exposure that began months ago is still readable. One view covers at most 30 days, so read a long exposure by moving the range back a window at a time rather than by widening it.

Your provider's own usage dashboard is the second source here, and the authoritative one for what you will actually be charged.

Afterwards

Two changes make the next one cheaper, and both are things this incident just demonstrated the value of:

• One key per environment and per deployment surface. The narrower a key's reach, the less a single leak costs you to contain.
• Split the gateway further if the blast radius was uncomfortable. If the leaked key reached traffic you would rather have kept separate, that is a gateway-modelling decision — see Separate your environments with gateways.