Exchange API Key Security: Why Your Trading Bot Can't Drain Funds

Giving a third party access to your exchange account sounds risky. In the worst-case scenario you can imagine, the platform gets hacked, your API keys are stolen, and your funds disappear. That scenario is real — but it is also completely preventable with one setting that costs you nothing to enable: withdrawal-disabled API keys. This post explains what that restriction actually does, the additional layers VolatiCloud enforces on top of it, and how to generate keys that even a full database breach cannot turn into stolen funds.

What Exchange API Keys Actually Grant

When you connect an exchange account to a trading bot, you generate an API key and secret on the exchange. That key is a scoped credential: it proves you authorized something on your behalf, but the specific permissions depend entirely on what you checked when you created it.

Most exchanges offer a permission model like this:

Permission	What it allows
Read	View balances, positions, order history
Trade	Place and cancel orders
Withdraw	Transfer funds to external addresses
Transfer	Move funds between sub-accounts or wallets
Margin	Manage margin positions

A trading bot needs exactly one of these: Trade. Everything else is either unnecessary or actively dangerous to grant to an automated system you don't control every second.

The withdrawal permission is the dangerous one. An API key that can withdraw can drain your entire balance to an external wallet in seconds — one API call, no 2FA prompt, no email confirmation on most exchanges. If that key is compromised, the window between an attacker getting your key and your funds being gone can be measured in seconds.

The Withdrawal-Disabled Standard

The industry convention for trading bot API keys is simple: never generate a key with withdrawal permissions.

A withdrawal-disabled key can trade on your behalf but cannot move funds off the exchange. Even if the key is leaked in a database breach, exposed in a log file, or intercepted in transit, an attacker holding it can do exactly one thing: place and cancel orders. They can't drain your account. They can't transfer funds to their wallet. The worst they can do is make bad trades — which your bot's stop-loss settings will contain.

warning

This is not an optional best practice. It is the minimum viable security posture for any API key you share with a third party. If you're connecting keys to any platform — VolatiCloud or anyone else — verify withdrawal permissions are off before you paste the key.

How VolatiCloud Enforces This

Until recently, most platforms in this space recommended withdrawal-disabled keys. VolatiCloud now enforces them.

When you connect a Binance API key, VolatiCloud automatically checks whether the key has withdrawal permissions. If it does, the connection is rejected with a clear error before the key is ever stored. You cannot create an exchange connection with a withdrawal-capable Binance key — the UI and API both block it.

This enforcement removes the human error vector. You don't have to remember to disable withdrawal. You don't have to read a security guide buried in the documentation. The platform catches the misconfiguration at connection time and tells you exactly how to fix it.

We are rolling this out across all supported exchanges. Binance is live today; the remaining exchanges follow in the next wave.

A Second Layer: Egress IP Allowlisting

Withdrawal-disabled keys prevent fund drainage. IP allowlisting prevents unauthorized use of the key even for trading.

Every runner pod in VolatiCloud egresses from a small, published set of IP addresses. Your exchange account can whitelist those specific IPs in its API security settings, which means the key only works when requests come from those addresses. A stolen key originating from an attacker's IP is rejected by the exchange before it can place a single order.

You can find the current list of VolatiCloud egress IPs in Security → Egress IPs. Copy those addresses into your exchange's IP restriction field when you generate your API key.

The combination of withdrawal-disabled keys and IP allowlisting means that even in the most pessimistic scenario — full database exfiltration — an attacker would hold keys that:

1. Cannot withdraw funds
2. Only work from VolatiCloud's own IP addresses
3. Are encrypted at rest (see below)

That's a substantially contained blast radius.

At-Rest Encryption for Every Key You Store

API keys you connect to VolatiCloud are encrypted before they reach the database. The current implementation uses AES-256-GCM with a per-field initialization vector, backed by a managed KMS (HashiCorp Vault). Raw key material is never stored in plaintext.

Every read of an encrypted field is logged: who requested it, which resource, from what IP, at what time. Organization admins can view the audit log under Settings → Security. The audit log is also exportable to CSV if you want to pipe it into your own SIEM.

The detailed encryption design is in Security → Encryption.

How to Generate the Right API Keys

Here's the pattern for each major exchange. The exact UI varies by exchange but the principles are the same.

Binance

1. Log in → Profile → API Management → Create API
2. Choose System-generated or Self-generated key type
3. Under permissions, check only Enable Reading and Enable Spot & Margin Trading
4. Leave Enable Withdrawals unchecked (it is unchecked by default — keep it that way)
5. Under IP access restrictions, select Restrict access to trusted IPs only and paste the VolatiCloud egress IPs
6. Copy the API key and secret, then connect them in VolatiCloud

VolatiCloud verifies the key at connection time and rejects it if withdrawal is somehow enabled.

Bybit

1. Account → API → Create New Key
2. Select System-generated API keys
3. Under API Key Permissions, select Read-Write for the Spot or Unified Trading section
4. Do not enable Assets (this controls transfers and withdrawals)
5. Under IP restriction, paste the VolatiCloud egress IPs

Kraken

1. Settings → API → Add key
2. Under Key Permissions, check Query Ledger Entries, Query Open Orders & Trades, Create & Modify Orders, Cancel/Close Orders
3. Leave Withdraw Funds unchecked
4. Under Nonce Window and IP whitelisting, add the VolatiCloud egress IPs

The same logic applies to OKX, KuCoin, and every other supported exchange: trading permission on, everything else off. The supported exchanges doc lists each integration; the security setup follows the same pattern across all of them.

What VolatiCloud Can (and Cannot) Do on Your Behalf

Understanding the permission boundary matters for your own mental model.

With a read + trade API key, VolatiCloud can:

• View your balances and open positions (needed for portfolio calculations)
• Place market, limit, stop, and OCO orders
• Cancel open orders
• Read your trade history for P&L tracking

VolatiCloud cannot:

• Withdraw funds to any external address
• Transfer funds between your exchange sub-accounts
• Change your exchange account settings
• Access other exchanges (each connection is scoped to its own key)

This boundary is enforced at the exchange, not just at VolatiCloud. Even if a bug in our software tried to issue a withdrawal request, the exchange would reject it because the key doesn't have that permission.

The Trust Roadmap: What Comes Next

Withdrawal-disabled enforcement and at-rest encryption address the external threat — a leaked database or compromised infrastructure component. The remaining challenge is the insider threat: VolatiCloud employees with legitimate database access can currently decrypt sensitive fields as part of normal operations.

We are honest about this gap, and we are closing it in phases.

Trust Tier 1 (in progress) — customer-supplied passphrase encryption. You set a passphrase for your organization. Your exchange keys are encrypted with a key derived from your passphrase via Argon2id, combined with our KMS-held key through envelope encryption. Neither your passphrase alone nor our KMS key alone can decrypt the data — both are required.

Trust Tier 2 (Wave 2) — passkey-backed end-to-end encryption. Your exchange keys and strategy code are encrypted in your browser, with the wrapping key bound to your hardware passkey (Face ID, Windows Hello, a FIDO2 key). We mathematically cannot decrypt without your explicit authorization.

Trust Tier 3 (Wave 2) — Bring Your Own Key. Your organization brings its own master key hosted in your AWS KMS, GCP Cloud KMS, Azure Key Vault, or HashiCorp Vault. You can revoke our decryption access with a single IAM policy change.

The full roadmap is in Security → Threat Model. Each tier ships as a discrete product change with its own public announcement, so you can see exactly what's changing and when.

Connecting Your First Exchange

Ready to connect? Here's the path:

1. Generate a withdrawal-disabled, IP-restricted API key on your exchange (steps above)
2. Open console.volaticloud.com → Exchanges → Add Exchange
3. Select your exchange, paste the key and secret, and click Connect
4. VolatiCloud validates the key's permissions in real time. If withdrawal is enabled, you'll see an error with instructions to fix it before the key is stored

From there, the exchange appears in your bot configuration, Strategy Builder, and backtest pair picker. Everything is scoped to trading — withdrawal never enters the picture.

If you haven't set up a bot yet, the getting started guide covers the full flow from exchange connection to first live trade in about 15 minutes.

The best security controls are the ones you can't accidentally skip. Enforcement at connection time — rather than a checkbox in a security guide — means every exchange connected to VolatiCloud is already safe by default. Withdrawal-disabled keys, IP allowlisting, and at-rest encryption aren't features you have to remember to enable; they're the only way the platform lets you connect.