If your crypto exchange API key was leaked, revoke or delete that exact key through the exchange's official site or app immediately. Then stop every bot or integration that used it, record the key's permissions, inspect account activity, and rotate any related credentials before reconnecting anything.

Key Takeaways

Treat the secret or passphrase as compromised even when the public key alone appears in a leak.

Revoke first; investigating first leaves the credential usable.

Permission scope determines what the attacker may have viewed or changed.

A password change does not prove that an API key was revoked.

Preserve logs without copying the secret into tickets, chat, or screenshots.

What should you do first when a crypto exchange API key was leaked?

Use a trusted device and open the exchange independently, not through a link in an alert. Navigate to API management, identify the exposed key by its label, public identifier, creation time, IP allowlist, or connected service, and revoke or delete it. If identity is uncertain, disable every nonessential API key and rebuild access later.

Kraken warns that API credentials can permit sensitive account actions and recommends minimal permissions plus deletion of keys that are no longer needed.［1］ Coinbase documents separate View, Trade, Transfer, and Manage permissions; its Transfer permission can move value and may bypass ordinary two-step confirmation.［2］ The exact labels differ by exchange, so record the actual scope before removing the key if that can be done without delaying revocation.

Use this order:

Revoke the exposed key in the official exchange account.
Pause bots, portfolio tools, tax connectors, scripts, and servers that used it.
Save the key label, public identifier, permissions, allowlist, and timestamps, but never the secret.
Check orders, trades, withdrawals, deposits, address-book changes, API logs, sessions, and security notices.
Contact official exchange support from the authenticated help channel if unauthorized activity or an unknown permission appears.
Rotate downstream credentials and create a replacement key only after the environment is trusted.

If the account itself shows an unfamiliar session or recovery change, follow the broader account takeover checklist as a parallel incident. API containment and account recovery overlap, but neither substitutes for the other.

Which part of an API credential was exposed?

An exchange integration may use several values. Their names are not interchangeable.

Exposed material	Typical role	Safe response
Public API key or identifier	Selects the credential and may appear in requests or dashboards	Check whether the platform treats it as sensitive; use it to locate and revoke the key
Secret key	Authenticates or signs API requests	Assume compromise, revoke immediately, and never paste it into support
API passphrase	Additional value required by some exchanges	Treat it as compromised with the secret and replace the entire key set
QR code or config file	May encode several credential values together	Assume every embedded value was disclosed
IP allowlist	Restricts where requests may originate	Preserve it as evidence, but do not rely on it as the sole containment measure

Coinbase states that the public key, secret, and passphrase are all required for its Exchange API key, while the secret and passphrase are shown only once.［2］ A screenshot, environment file, shell history, CI log, browser extension, shared notebook, or repository commit can therefore expose more than the filename suggests.

Do not spend the first minutes debating whether the attacker obtained every required component. Revocation is cheaper than proving a negative while a potentially valid credential remains active.

How does API key permission scope change the incident?

Build an exposure matrix from the exchange's actual configuration. Do not infer permissions from what the connected app normally did; a bot that only displayed balances may have been granted trading or transfer access unnecessarily.

Permission	Potential impact to investigate	Immediate evidence
Read or View	Balances, positions, history, addresses, or personal trading patterns disclosed	API access log, export history, unusual data queries
Trade	Orders placed or canceled, positions changed, liquidity or price manipulation attempts	Order IDs, fills, canceled orders, timestamps
Transfer or Withdraw	Assets sent, withdrawal addresses changed, or internal transfers initiated	Withdrawal ledger, address-book changes, confirmation messages
Manage	Settings, portfolio structure, or other credentials altered	Security history, configuration diff, new keys or delegates

A read-only leak is still a privacy incident. Holdings and trade history can support targeted phishing, extortion, impersonation, or later social engineering. A trading key may create losses without a withdrawal, while a transfer-capable key creates the most urgent asset-movement risk.

If withdrawals are disabled or the entire account becomes restricted during review, keep those states separate. Use the account restriction guide for an account-wide control and the withdrawal-disabled guide for a narrower withdrawal decision.

What evidence should you preserve without leaking the key again?

Create an incident record that another reviewer can understand without possessing the secret. Include:

exchange name, account or portfolio identifier, and official case number;
key label and public identifier, partially masked if the exchange treats it as sensitive;
creation, last-used, revocation, and discovery timestamps with timezone;
permissions, IP allowlist, and connected integration name;
relevant API, order, trade, withdrawal, security, and server access logs;
where the exposure appeared, who could access it, and when that copy was removed;
screenshots that exclude secrets, seed phrases, recovery codes, and unrelated personal data.

Store original exports read-only where practical. Record timezone and source system because an exchange log in UTC, a server log in local time, and an email timestamp can otherwise look inconsistent.

Never paste a secret into a support ticket to prove that it leaked. Support can identify the credential by account context, public identifier, label, or timestamp. If anyone asks for the secret, recovery phrase, one-time code, or remote screen control, stop and reopen support through the official exchange channel.

What else should you rotate after revocation?

Revoking the exchange key stops future use of that credential, but it does not clean the system that disclosed it. OWASP treats rotation, revocation, auditing, and incident response as distinct parts of a secret lifecycle.［3］ Find the exposure path before creating a replacement.

Check these locations:

environment variables, .env files, deployment settings, and secret managers;
source repositories, commit history, issue attachments, paste sites, and chat exports;
CI/CD logs, build artifacts, crash reports, terminal history, and monitoring output;
trading-bot hosts, portfolio tools, spreadsheets, browser storage, and backups;
vendor dashboards, team accounts, API gateways, and shared password managers.

Remove the exposed value from active systems, but preserve incident evidence under controlled access. If the secret entered version history or a backup, deletion from the latest file does not erase older copies. Rotation is what invalidates the old credential; history cleanup only reduces accidental rediscovery.

Secure the exchange login, primary email, and connected third-party accounts with unique passwords and strong MFA. Review recovery methods and active sessions. If the leak came from malware or an untrusted host, rebuild or remediate that host before installing the replacement key.

How should you create the replacement API key?

Create it only when the exchange account and integration environment are under control. Give it the smallest permission set that supports one named workload. A reporting tool should not receive trade or transfer access, and a trading bot should not receive withdrawal permission unless the business requirement is explicit and independently controlled.

Use a unique key per integration so that future revocation does not break unrelated services. Apply an IP allowlist when the integration has stable trusted egress, set expirations or rotation reminders where supported, and store the secret in a dedicated secret manager rather than source code or a shared document.

Test the replacement with a low-risk read operation first. Re-enable automation gradually while watching API, order, and withdrawal logs. Do not copy the old key's permissions blindly; the incident is an opportunity to remove accumulated access.

How can you check if a leaked API key was misused?

Absence of an obvious withdrawal is not proof of safety. Compare the key's last-used data with your integration logs and review all actions its scope allowed. Look for new source IPs, unusual request volume, canceled orders, unexpected trades, new withdrawal addresses, configuration changes, and activity while your integration was offline.

Ask the exchange what audit data it can provide and whether it has applied temporary controls. Do not interpret a temporary freeze as proof of theft; it may be a preventive response. Conversely, do not treat normal balances as proof that read-only information was not copied.

Write the conclusion in layers: confirmed actions, plausible actions permitted by scope, and actions ruled out by authoritative logs. That keeps the response evidence-based without minimizing an unknown exposure.

Summary

Revoke the exact API key before investigating the leak source.
Record permissions because read, trade, transfer, and management access create different risks.
Pause integrations and inspect both exchange-side and host-side logs.
Rotate related secrets and remediate the system that disclosed the credential.
Rebuild access with one integration per key, least privilege, and monitoring.
Keep secrets out of evidence packages and support conversations.

Frequently Asked Questions

Is changing my exchange password enough after an API key leak?

No. A password change does not prove that separately issued API credentials were revoked. Delete or revoke the key in API management and verify its status independently.

What if only the public API key leaked?

The risk depends on the exchange's authentication design and whether another component was also exposed. Use the public identifier to locate the key, inspect its use, and revoke it when you cannot confidently bound the disclosure.

Should I withdraw all assets immediately?

Do not rush into a new transfer without checking addresses, networks, account restrictions, and device trust. First revoke the key and contact the exchange if transfer-capable access or unauthorized activity is present.

Can an API key trade without withdrawing funds?

Yes, when it has trading permission. Unauthorized orders can still create losses, fees, unwanted positions, or market exposure even if withdrawals are disabled.

Should I publish the leaked key so others can test it?

No. Public testing increases exposure and can harm the account. Share only masked identifiers and necessary evidence through authenticated official channels.

Can an IP allowlist make a leaked secret harmless?

It can reduce reachable attack paths, but it is not proof of safety. The allowed host may also be compromised, network controls can change, and the secret should still be revoked.

When is it safe to reconnect my trading bot?

After the old key is revoked, the leak path is remediated, account activity is reviewed, and a least-privilege replacement is stored securely. Reconnect gradually and monitor its first actions.

What if unauthorized withdrawals already occurred?

Contact the exchange immediately through its official incident channel, preserve transaction and account evidence, and follow applicable reporting instructions. No private party can guarantee recovery.

Disclaimer: This article provides general security information, not financial, investment, trading, tax, legal, or professional incident-response advice. Exchange features, logs, deadlines, and recovery options vary by service and jurisdiction.

Sources:

Kraken — API Key Security — https://support.kraken.com/articles/api-key-security
Coinbase Exchange — How to create an API key — https://help.coinbase.com/en/exchange/managing-my-account/how-to-create-an-api-key
OWASP — Secrets Management Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html

Sources checked 8 September 2026.

Related reading:

Crypto Exchange API Key Was Leaked: What to Do