API key security for trading bots: what the 3Commas incident taught
Connecting a bot to an exchange means handing a credential to software, and the permissions you grant at that moment decide what a compromise costs you. The rule that matters most is short: a trading bot never needs withdrawal permission. The 2022 3Commas episode demonstrated the rest — that attackers can drain an account through trading alone, that two-factor authentication does not protect API keys, and that a platform's own security is only one of several ways a key can end up somewhere else.
Published 27 August 2026 · Updated 28 August 2026 · AI Trading Book Editorial · Reading time about 12 minutes
- Never enable withdrawal on a trading key. This single setting decides whether a compromise is a trading loss or a total one.
- Trade-only is not zero risk. In 2022 attackers drained accounts through deliberately bad fills on illiquid pairs.
- IP allowlisting is the strongest control — a stolen key simply fails from anywhere else.
- 2FA does not apply to API keys. They are built to work without a human present.
- Isolate funds in a sub-account so the blast radius is the strategy allocation, not the portfolio.
What an API key actually grants
An exchange API key is a credential pair — a key and a secret — that allows software to act on your account without your password. When you create one you choose its permissions, and those permissions are the entire security boundary. Everything else on this page is about narrowing that boundary and limiting what sits inside it.
Most exchanges offer three scopes. Read access retrieves balances, positions and history. Trade access places and cancels orders. Withdrawal access moves funds off the exchange. A trading bot needs the first two and never the third.
The 3Commas incident, in sequence
3Commas is a widely used crypto trading bot platform that connects to exchange accounts through API keys. In late 2022 it was at the centre of the most instructive public episode in this area. The sequence below is drawn from contemporaneous reporting and 3Commas' own published updates.
| Date | Event |
|---|---|
| 20 October 2022 | 3Commas is alerted to unauthorised trades placed on FTX accounts using connected API keys |
| 21 October 2022 | Support escalates to the technical team; malicious orders identified as designed to drain balances through counter-trades |
| October 2022 | Investigation identifies websites imitating the 3Commas interface, used to capture keys through phishing |
| December 2022 | 3Commas publishes an update stating many affected keys had never been connected to its platform, and that a database leak was almost certainly not the cause |
| 28 December 2022 | Binance's chief executive publicly warns users to disable any API key ever entered into 3Commas |
| 28 December 2022 | 3Commas confirms a circulated dataset of keys is genuine and asks Binance, KuCoin and other exchanges to revoke all connected keys |
Attribution remained contested. 3Commas maintained the keys were obtained outside its systems, pointing to phishing sites and noting that a significant number of the keys involved had never been used with the platform, while separately confirming that the leaked file circulating publicly contained real credentials. We report the sequence rather than adjudicating the cause, because the operational lessons hold either way — and that is the point worth taking from it.
How accounts were drained without withdrawal access
This is the detail most often missed, and it is why trade-only permission is a limit rather than an answer. Attackers did not need to move funds off the exchange. They placed orders from the victim's account on low-liquidity pairs while taking the other side of those trades themselves, so the victim's balance was converted into worthless positions at deliberately terrible prices. The money left the account through the order book.
Trade permission alone therefore permits near-total loss of whatever is reachable from that key. What limits the damage is not the permission scope by itself but how much is sitting in the account the key can reach — which is the argument for sub-account isolation below.
What the episode establishes
- Your key can leak without the platform being breached. Phishing sites imitating a platform's interface, browser extensions and malware all capture keys before they reach anyone's database.
- Trade-only is not safe, only safer. The attack method required no withdrawal rights.
- Exchanges generally did not reimburse. Losses arising from a user-issued API key were largely treated as the user's responsibility.
- Detection was slow. Months passed between the first incidents and the general warning; individual users noticed only after their balances moved.
- Revocation is the only reliable response, and it works only if you do it before the key is used.
The controls, in order of effectiveness
| Control | What it prevents | Cost to implement |
|---|---|---|
| No withdrawal permission | Total loss of exchange balance | None — a checkbox at key creation |
| IP allowlist | Use of a stolen key from anywhere else | Requires a stable IP; usually a small server |
| Sub-account isolation | Exposure beyond the strategy's allocation | None where the exchange supports sub-accounts |
| Separate key per bot and per exchange | One compromise reaching several systems | Minor administrative overhead |
| Secrets manager or environment variables | Keys leaking through code, repos or screenshots | Small one-off setup |
| Scheduled rotation | A quietly stolen key remaining useful indefinitely | A recurring calendar entry |
| Activity review | Compromise going unnoticed for months | A few minutes on a regular schedule |
| Exchange-side order limits, where offered | Rapid draining through abnormal orders | Varies by exchange |
| Setting | Correct value | Why |
|---|---|---|
| Withdrawal permission | Off | The only setting that turns a trading loss into a total one |
| Trade permission | On, if the bot places orders | Leave off for read-only analytics tools |
| Margin or futures permission | Off unless the strategy uses them | Unused permissions only add blast radius |
| IP restriction | Set to your server's address | Renders a stolen key unusable elsewhere |
| Account scope | A sub-account, funded with the strategy allocation only | Caps exposure at the amount you chose to risk |
| Key label | Names the bot and the date issued | Makes rotation and targeted revocation possible |
| Storage location | Environment variable or secrets manager | Keeps the secret out of code, repos and screenshots |
| Rotation date | In your calendar at creation time | Rotation only happens if it is scheduled |
IP allowlisting
Restricting a key to specific IP addresses is the most effective single control after permissions, because it makes a stolen credential useless anywhere but your own infrastructure. Its cost is architectural: your bot needs a stable address, which in practice means a small cloud server rather than a home connection with a changing IP.
Where a third-party platform runs the bot on its own infrastructure, allowlisting is only available if that platform publishes its outbound addresses. That it does so is a reasonable signal about how seriously it takes this; that it does not is worth weighing.
Sub-account isolation
Fund a sub-account with the capital allocated to one strategy and issue the key against that sub-account only. A compromise then costs the allocation rather than the portfolio. This converts an unbounded risk into a budgeted one, and it costs nothing where the exchange supports it.
It also makes performance attribution trivial. The sub-account balance is the strategy's result, with no need to disentangle it from other activity — which matters for the staged-deployment discipline described on our strategy building page.
Storing keys
Use environment variables or a dedicated secrets manager. Never place keys in source code, in configuration files committed to version control, in spreadsheets, in chat messages, or in screenshots shared while asking for help. Automated scanners find credentials committed to public repositories within minutes of the commit.
Two habits cause most accidental exposure: pasting a key into a support conversation or forum post to demonstrate a problem, and committing a config file that was working locally. Both are ordinary mistakes rather than security failures, which is why the storage discipline has to be in place before the mistake happens.
Rotation and revocation
Rotate on a schedule you actually keep — quarterly is a common choice — and immediately on any of the following: a device compromise, an incident report from a platform you use, a person leaving a team with access, or any suspicion that a key was exposed. Rotation limits the useful lifetime of a credential stolen quietly, which is the case where you have no other signal.
When revoking, delete the key rather than disabling it. Disabled keys are sometimes re-enabled during account recovery or support processes, and a deleted key cannot be.
Two-factor authentication does not cover this
A common and costly assumption is that an account with 2FA enabled is protected from API key misuse. It is not. Two-factor authentication protects interactive logins — a human at a browser. API keys exist specifically so that software can act without a human present, so they bypass the second factor by design.
This is why the security model for automated trading rests on permissions, IP restrictions and account isolation rather than on login protections. Keep 2FA on your exchange login regardless; just do not count it as covering the key.
Detecting misuse
Review on a schedule rather than after a loss. Most exchanges expose API key activity separately from interactive sessions, which makes the check quick.
- Orders your system did not place — reconcile the exchange's trade history against your own order log rather than reading it in isolation.
- Unfamiliar trading pairs, particularly illiquid ones your strategy does not touch. This was the signature of the 2022 attacks.
- Activity while your bot was idle or stopped.
- API access from unexpected addresses, where the exchange records this.
- Changes to withdrawal addresses or account settings, which suggest a broader compromise than a single key.
If a key is compromised
- Delete the key at the exchange. Do this first, before investigating anything. Delete rather than disable.
- Cancel all open orders on the affected account.
- Review recent trades and record timestamps, pairs and order IDs before anything ages out of the interface.
- Check account settings and withdrawal addresses for changes indicating a wider compromise.
- Rotate every other key that could share the exposure — same machine, same platform, same password manager.
- Contact exchange support with the timestamps and order IDs, understanding that reimbursement for user-issued key losses has historically been rare.
- Establish how it happened before issuing a replacement key. A new key on a compromised machine is compromised on creation.
- Expect a recovery approach. Unsolicited offers to recover stolen crypto for an upfront fee are a second fraud, covered on our scams page.
What to ask a bot platform before connecting
- Does it ever request withdrawal permission? If yes, do not connect.
- Does it publish outbound IP addresses so you can allowlist them?
- How are keys stored at rest, and who internally can access them?
- Does it support connecting a sub-account rather than a main account?
- Has it had a security incident, and what did it publish about it?
- Can you revoke access from within the platform as well as at the exchange?
- Is there an audit log of actions taken with your key?
A platform that answers all seven clearly is unusual. The pricing and limits for the platforms we have documented are on our platforms page, with the caveat that security posture changes more often than pricing does.
What we could not establish
- A verified total loss figure for the 2022 episode. Estimates circulated in reporting and from independent researchers, but no audited total was published. Data not found.
- A definitive attribution of the leak. The platform's account and third-party analyses differed, and no regulatory finding resolving it was identified. Data not found.
- Any rate of API key compromise across bot platforms generally. No cross-platform incident dataset exists. Data not found.
Key takeaways
- Withdrawal permission is the one irreversible decision. No trading bot needs it; a request for it is disqualifying.
- Trade-only limits the damage, it does not prevent it. Accounts were drained through the order book in 2022.
- IP allowlisting neutralises a stolen key and is worth restructuring your setup to obtain.
- Sub-accounts turn an unbounded risk into a budgeted one at no cost.
- 2FA does not apply to API keys. Do not treat the login protection as covering automated access.
- Delete, do not disable, and check activity on a schedule rather than after a loss.
Frequently asked questions
What is an exchange API key?
A credential pair — a key and a secret — that lets external software act on your exchange account without your password. Permissions are set when you create it, and those permissions define exactly how much damage someone can do if the key is obtained by anyone else.
Should a trading bot ever have withdrawal permission?
No. A trading bot needs to read balances and place orders. It never needs to move funds off the exchange. Enabling withdrawal turns a compromised key from a trading problem into a total loss of the account balance, and no legitimate bot requires it.
What happened in the 3Commas incident?
In October 2022, unauthorised trades were placed on FTX accounts using API keys linked to 3Commas. In December 2022, after a dataset of keys circulated, 3Commas confirmed the leaked data was genuine and asked Binance, KuCoin and other exchanges to revoke all connected keys. 3Commas maintained the keys were not taken from its own systems.
How were the keys used to steal money without withdrawal access?
Through trading itself. Attackers placed orders on low-liquidity pairs from the victim account while taking the other side, so the victim's balance was drained through deliberately bad fills. Trade-only permission limits the blast radius but does not eliminate it.
Was 3Commas responsible for the leak?
Attribution was contested. 3Commas said the keys were obtained outside its platform, pointing to phishing sites imitating its interface, and noted that many affected keys had never been connected to 3Commas. It later confirmed that a circulated dataset of keys was genuine. We report the sequence rather than adjudicating the cause.
What is an IP allowlist?
A restriction that makes an API key work only from specified IP addresses. It is the single most effective control available, because a stolen key used from anywhere else simply fails. It requires your bot to run from a stable address, which usually means a server rather than a home connection.
Why use a separate sub-account for a bot?
To limit what a compromise can reach. A sub-account funded with only the capital allocated to that strategy means a compromised key cannot touch the rest of your holdings. It also makes performance attribution straightforward, since the sub-account balance is the strategy's result.
How often should API keys be rotated?
On a schedule you set and keep — many operators use quarterly — and immediately whenever a device is compromised, a platform reports an incident, someone leaves a team, or a key may have been pasted somewhere insecure. Rotation limits how long a quietly stolen key stays useful.
Where should API keys be stored?
In environment variables or a dedicated secrets manager, never in source code, configuration files committed to version control, spreadsheets, chat messages or screenshots. Keys committed to a public repository are found by automated scanners within minutes.
How do I know if my key has been used by someone else?
Check the exchange's trade and login history for orders your system did not place, unfamiliar trading pairs, activity at times your bot was idle, and access from unexpected addresses. Most exchanges show API key activity separately, and this is worth reviewing on a regular schedule rather than only after a loss.
What should I do immediately if a key is compromised?
Delete the key at the exchange first — not disable, delete — then cancel open orders, review recent trades, check whether withdrawal addresses or account settings were changed, and rotate every other key that could share the exposure. Contact the exchange's support with timestamps.
Are third-party bot platforms safe to connect?
Connecting to any third party moves your key outside your control, so the question is what you can limit rather than whom you trust. Grant trade-only permission, restrict by IP where the platform supports it, isolate funds in a sub-account, and prefer platforms that never ask for withdrawal rights.
Does two-factor authentication protect an API key?
No. Two-factor authentication protects interactive logins. API keys are designed to work without human interaction, so they bypass it entirely. That is precisely why permissions, IP restrictions and account isolation carry the security weight for automated trading.
What is the single most important rule?
Never enable withdrawal permission on a trading key. Everything else on this page reduces risk; this one rule determines whether a compromise costs you part of a trading balance or all of the funds on the exchange.
Compiled by AI Trading Book Editorial from 3Commas' own published updates and contemporaneous reporting of the October and December 2022 events. Attribution of the leak was contested at the time and no regulatory finding resolving it was identified, so this page reports the documented sequence and marks the unresolved points as such. Items we could not verify are marked "data not found". Published 27 August 2026; last updated 28 August 2026. Corrections are logged on the corrections page.
Sources
- 3Commas blog — update on the investigation into API keys and attacks on exchanges, December 2022 — escalation on 21 October 2022; malicious counter-trades draining balances; a significant number of affected keys never connected to 3Commas; database leak assessed as almost certainly not the cause.
- Contemporaneous reporting, October 2022 — unauthorised trades on DMG pairs on FTX using API keys linked to 3Commas; phishing sites imitating the 3Commas interface identified during investigation.
- Contemporaneous reporting, 28 December 2022 — Binance's chief executive warning users to disable any API key entered into 3Commas; 3Commas confirming a circulated key dataset was genuine and requesting revocation by Binance, KuCoin and other exchanges.
Informational research only. Nothing on this page is personal financial, legal, tax, security or investment advice. Security practices described here reduce risk; they do not eliminate it. Exchange features, permission models and platform security posture change — verify current settings with your exchange and platform.