What to do if an exchange API key leaks
Figures on this page are as of 2026-09. Fees, limits and margin tiers change — check the venue's own docs before acting on a number.
Revoke first. Investigate afterwards. A key you are unsure about is a key you replace — rotation costs minutes, and the alternative is reasoning about exposure while it is still live.
Everything below assumes you have done that.
The first five minutes
1. Revoke or disable the key. Not “change its permissions” — remove it. A key with reduced permissions is still a key someone else has.
2. Check for open orders you did not place. Cancel anything unexpected. This matters before position review, because a resting order is still capable of filling while you work.
3. Check positions and balances against what you expect.
4. Check withdrawal history, including pending withdrawals. If withdrawals were possible on this key, this is the one that decides how bad the day is.
5. Check transfer history. Internal and universal transfers do not send
funds off-exchange but they do move value, and they are governed by separate
permission flags from withdrawals — enableInternalTransfer and
permitsUniversalTransfer on Binance.
Venue-specific things that will surprise you
Hyperliquid — revoking is not the same operation
There is no API key to revoke. A master account approves an API wallet (agent wallet) to sign on its behalf, so the action is deregistering the agent.
The documentation carries a warning that matters during an incident: once deregistered, nonce state may be pruned, potentially allowing previously signed actions to be replayed. Its guidance is to generate new wallets for future use rather than reusing addresses.
So the incident procedure differs from a CEX: deregister, and then do not reuse that address. Treat it as burned.
IBKR — the credential is not the boundary
There is no API key on the TWS path; the socket inherits the logged-in desktop session. So “revoke the key” has no direct equivalent.
What you can do immediately is re-enable Read-Only API (Global Configuration → API → Settings), which blocks all API trading while leaving reads working, and untick “Enable ActiveX and Socket Clients” to refuse API connections entirely. Then address the account credentials themselves.
Trusted IP addresses in the same panel are worth reviewing during an incident — a trusted address connects without challenge.
Binance — check whether the key could withdraw at all
If the key had no IP restriction, it could not have had withdrawal permission — Binance requires the IP Access Restriction filter before withdrawals can be enabled. That is a meaningful narrowing of the blast radius and worth establishing early rather than assuming the worst.
Confirm rather than recall: GET /sapi/v1/account/apiRestrictions returns the
flags, though you will need a working key to call it — which is an argument for
recording each key’s configuration when you create it.
Bybit — expect the codes to change meaning
After revocation, existing clients will start failing. Under a Unified Trading
Account, an invalidated key surfaces as 10003 on spot or 33004 on
derivatives, both documented as “Your api key has expired”. On classic accounts
10003 means something else entirely — too many sessions under the same UID —
so do not use it to confirm the revocation took.
Where keys usually leak
Worth knowing, because the investigation is mostly a list of places to look:
- Committed to a repository. Including a private one, including in history after being removed from the current file.
- In logs. A handler that logs full request objects logs headers. Debug and verbose modes are the usual culprits.
- In a synced config. Dotfiles repositories, cloud-synced folders, MCP client config files.
- In a screen share or screenshot. Config files opened in an editor during a call.
- In third-party software. Any MCP server, bot or dashboard holding the key. Community-maintained trading MCP servers are worth an explicit thought here — most exchange servers are not published by the venue.
- In a support conversation. Pasted while debugging.
- On a compromised machine, which changes the scope from one key to everything on that machine.
After the immediate response
Rotate everything that shared the machine or the repository. If one key leaked through a path, other credentials on that path are suspect.
Work out which consumer it was. If you cannot tell, that is the finding: one key per consumer exists precisely so that this question has an answer.
Fix the path, not just the key. A key rotated without changing how it leaked will leak again.
Reduce what the next one is worth. Read-only where possible, IP restriction where supported, a sub-account with bounded funds for anything you do not fully control.
Write down what you did. The next incident will be handled by someone with less context — possibly you, at 3am.
The uncomfortable one
If the key had trading permission and was live for a while, the damage may not look like theft. It may look like trades. Positions opened and closed, small losses spread over time, nothing dramatic enough to notice in isolation.
Check the fills against your own records rather than eyeballing the balance. This is one of the concrete reasons to keep a decision log: without a record of what you intended, you cannot identify what you did not.
FAQ
Should I revoke immediately or investigate first?
Revoke. Rotation takes minutes and costs you a restart; investigating a live credential means reasoning about exposure while the exposure continues. You can investigate perfectly well after the key is dead.
Can someone withdraw funds with a leaked Binance key?
Only if it had withdrawal permission, which on Binance requires an IP access
restriction to enable at all. A key with no IP whitelist could not have had it.
Check the withdrawal and transfer history regardless — enableInternalTransfer
and permitsUniversalTransfer are separate flags that also move value.
How do I revoke access on Hyperliquid?
Deregister the API wallet rather than revoking a key. Then generate a new wallet rather than reusing the address: the documentation warns that once deregistered, nonce state may be pruned and previously signed actions could be replayed.
What if I am not sure whether a key leaked?
Rotate it. The cost is a restart and a config change; the cost of being wrong in the other direction is unbounded. “Not sure” is not a state worth maintaining for a credential that can trade.