Secrets management for trading automation
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.
Assume the credential will leak. Design so that the leak costs you an information disclosure rather than your account.
That framing is more useful than trying to make a leak impossible, because most leaks come from places people do not think of as credential stores.
Where they actually leak
Ranked by how often they catch people:
Logs. A handler that logs full request objects logs headers, and headers
carry X-MBX-APIKEY, X-BAPI-API-KEY, OK-ACCESS-KEY. Debug and verbose modes
are where this lives, and log files have ordinary permissions because nobody
thinks of them as sensitive.
Shell history. export BINANCE_API_KEY=... typed once sits in
~/.bash_history indefinitely.
Synced dotfiles. A dotfiles repository is a public credential store waiting for one careless commit — and the commit stays in history after being removed from the current file.
MCP client config files. claude_desktop_config.json, ~/.cursor/mcp.json,
.vscode/mcp.json. These hold environment blocks with live credentials and are
opened in editors during screen shares. Check yours before your next call.
Third-party code. Any MCP server or bot holding your key is a place it can leak from, and most exchange MCP servers are community projects — see where an MCP server keeps your API keys.
Error messages and support conversations. A raw API error can include the request that produced it. Pasted into an issue tracker, it is now public.
.env committed once. Gitignored later does not remove it from history.
Reducing what a leak is worth
This is where the leverage is, because it does not depend on preventing anything.
Scope the credential. A read-only key is an information disclosure, not a financial event. Start there and widen deliberately.
Bind an IP. A leaked key usable only from one address is worth much less.
Enforced on Binance and Bybit — Bybit’s 10010 is its signature.
Know your venue’s withdrawal model. On Binance, withdrawals cannot be enabled on a key without IP access restriction. So an unrestricted key structurally cannot withdraw, which is a stronger statement than remembering to leave a box unticked — see disabling withdrawals on a Binance API key.
One key per consumer. A key shared between a bot, a dashboard and an MCP server gives you three leak paths and no attribution. Separate keys make revocation surgical.
Use a sub-account with bounded funds for anything you did not write. It limits damage from correct-but-wrong behaviour as well as from compromise, which no permission flag does.
Storage, ranked
OS keychain — best, and rarely offered. Prefer it where available.
A config file with restricted permissions, outside anything synced or versioned — good.
Environment variables — the common default, and acceptable. Caveats: visible to child processes and to anything reading the process environment, and they tend to end up in shell profiles that get committed.
A .env file — fine if gitignored before it ever existed, and if you have
verified it is not in history.
Pasted into a config from a README example — happens more than it should. Check your MCP client config for literal credentials.
Venue-specific things to record
OKX has a passphrase — a third credential you chose at key creation, sent as
OK-ACCESS-PASSPHRASE, and not recoverable. Lose it and the key must be
replaced. Store it with the same care as the secret, not in a comment.
Alpaca shows the secret once at generation, with no retrieval afterwards.
Hyperliquid has no API key — an agent wallet signs. If a private key leaks, deregister the agent, and do not reuse the address: the documentation warns that pruned nonce state may allow previously signed actions to be replayed. See Hyperliquid API setup.
Operational hygiene
Verify nothing logs them. Run against testnet credentials with verbose logging on and grep the output for the key string. Two minutes, and it answers the question directly rather than by inference.
Assert permissions at startup. On Binance,
GET /sapi/v1/account/apiRestrictions returns the live flags. A process that
refuses to run when enableWithdrawals is true converts a silent exposure into
an immediate failure.
Rotate on any suspicion. Rotation is minutes; investigating a live credential is not. “Not sure” is not a state worth maintaining.
Practise revocation once, calmly. The moment you need it is not the moment to go looking for the page.
Remove keys for decommissioned services. Orphaned credentials with live permissions are a standing risk nobody owns.
Re-audit on a schedule. The setup you reasoned about carefully in March is not the one running in September.
The rule underneath
Prefer boundaries that are properties of the system over records of your intentions.
A permission that cannot be granted beats one you turned off. A key scoped to one purpose beats a key you are careful with. A sub-account with bounded funds beats a position limit you remember. Each difference shows up at the same moment: when something unexpected happens and nobody is watching.
FAQ
Where should I store exchange API keys?
An OS keychain where available, otherwise a permission-restricted config file outside anything synced or versioned. Environment variables are acceptable and common, with the caveat that they are visible to child processes and tend to migrate into shell profiles that get committed.
Can an MCP server leak my API keys?
It can, and most trading MCP servers are community code holding live credentials. The questions worth answering before installing: where are keys read from, are they ever written to logs, and does anything leave the machine. A README that cannot answer those is asking you to assume.
How do I limit the damage if a key leaks?
Scope it read-only unless you need trading, bind it to an IP, use one key per consumer, and consider a sub-account with bounded funds for anything you did not write. On Binance a key without IP restriction cannot have withdrawals enabled at all, which caps the worst case structurally.
Should I rotate keys regularly?
Rotate on any suspicion without hesitation, since the cost is a restart. Routine scheduled rotation matters less than scoping and attribution — a read-only key bound to one IP and used by one service is a small prize regardless of its age.