The goal is to cap the damage from any single leaked key
If every strategy shares one full-permission key, a fault in any component exposes the whole account. Isolation is less about hiding keys and more about defining what each key can do and how much money it can touch. A practical test: if this key were fully leaked today, would the possible actions and reachable funds stay within a loss you decided in advance to accept? If the answer is the entire account, isolation has not been done yet.
Split permissions into read, trade and withdraw, and leave withdraw off
Most exchanges separate reading (market data, balances, order queries), trading (place and cancel orders) and withdrawal, though names and granularity differ, so follow the exchange's API management page. Market data collectors, backtest data pulls and dashboards should use read-only keys. Only the execution engine gets trade permission. Quant workflows rarely need withdrawal permission, so keep it disabled. If the exchange has separate toggles for derivatives, margin or transfers, enable only what the strategy actually uses. Move funds through a manual or separately verified process, never through a key the strategy process can reach.
Sub-accounts and IP allowlists cover different risks
Sub-accounts bound the money: give each strategy or capital pool its own sub-account and its own key, so a misbehaving strategy can only affect that balance. IP allowlists bound the caller: a stolen key is useless from an unlisted address. They complement each other and neither replaces the other. Allowlists require a stable egress address, so if your execution nodes run on dynamic IPs, put them behind a fixed-egress gateway first. Otherwise people end up disabling the allowlist to avoid constant edits. If an exchange lacks sub-accounts or gates them, use separate accounts or reduce the balance held in any one account.
Development, staging and production must not share keys
Keys usually leak through repositories, logs, screenshots and test configs rather than active attacks. Use at least three tiers: read-only or testnet keys for development and backtesting, a small-balance sub-account key for staging, and a dedicated trade key for production. Keep secrets out of code and images; inject them through environment variables or a cloud secret manager with restricted read access. Redact keys and signatures in logs, and avoid printing raw request headers in error messages. Production keys should never sit on a developer's laptop.
Per-strategy keys also isolate rate limits and failure modes
Exchanges typically apply rate limits per key or per IP. When strategies share a key, one retry storm can starve the others of order capacity or trigger a risk-control block. Separate keys contain that. On your side, add execution-layer controls: a per-order cap, a daily cumulative cap, and a kill switch for abnormal cancel rates. These should run in a module independent of strategy logic so strategy code cannot bypass them, rather than relying only on exchange-side risk controls.
Disable and rotate immediately when you see these signals
Do not wait for a full investigation if a key appears in a public repo or chat log, the exchange backend shows unfamiliar source IPs or calls, a team member leaves or a contractor handoff ends, or a server or CI account may be compromised. A sensible order: disable or delete the key at the exchange, cancel open orders and verify positions and balances, review logs to scope the impact, then resume with a new key and fresh source restrictions. Even without incidents, rotate on a schedule that fits your capital size and team turnover, and make rotation possible without downtime, or nobody will do it.