Where an MCP server keeps your API keys
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.
An MCP server is the only component in the chain that actually talks to your exchange. The model does not have your keys and the client does not use them. The server holds them, and the server is usually code somebody else wrote.
That is worth a few minutes of attention before the ten-minute install.
Who publishes these things
The first question, and the one most easily answered: is this from the venue?
It varies, and by more than people expect. Alpaca and OKX both publish their own MCP servers, and Interactive Brokers offers a hosted connector. For Binance, Bybit and Hyperliquid, what we found is community code — capable, sometimes very thoughtfully built, but not shipped by the party whose account it accesses.
Worth checking the venue’s own documentation rather than assuming either way: this landscape is moving, and “no official server surfaced in a search” is not the same as “none exists”.
This is not a reason to avoid them. Plenty of good infrastructure is third party. It is a reason to make the trust decision explicitly rather than by assuming that because a server is named after an exchange, the exchange stands behind it.
The three questions a README should answer
If you check nothing else, check these.
1. Where are credentials read from? Environment variables and a config file are both normal. What matters is that you know which, because it determines who else can read them — other processes, backup software, a shell history, a synced dotfiles repo, a screen share.
2. Are they ever written to logs? This is the one that catches people. A server logging full request objects for debugging will log the credential along with everything else, into a file with ordinary permissions that nobody thinks of as sensitive. Verbose or debug modes are where this usually lives.
3. Does anything leave the machine other than exchange API calls? Telemetry, crash reporting, update checks. Each is defensible on its own and each is a channel. The answer you want is “no”, and the answer you should be able to find is some answer.
A server whose documentation does not address these is not necessarily mishandling your keys. But you are being asked to assume rather than verify, on a credential that can place orders.
What the protocol does and does not do here
MCP itself has nothing to say about credential storage — it is a protocol for tool exposure, not a secrets standard. The server’s practices are the server’s.
What the specification does say is relevant in an adjacent way:
Servers MUST:
- Validate all tool inputs
- Implement proper access controls
- Rate limit tool invocations
- Sanitize tool outputs
“Sanitize tool outputs” is the one that touches secrets. A tool that returns a raw API error can return a response body containing the request that produced it. Error paths are where credentials leak, because error paths get less attention than success paths.
Reducing what a leak costs
You cannot fully audit every server you install. What you can do is make the credential worth less if it escapes.
- Use a key that cannot trade unless you have decided it should. A leaked read-only key is an information disclosure, not a financial event.
- Set an IP whitelist. It reduces a leaked key to something usable only from one address.
- One key per consumer. If the MCP server, a bot and a dashboard share one key, a leak means revoking all three and you cannot tell which leaked.
- Never enable withdrawals on a key used by automation. On some venues this is structurally enforced — Binance will not enable withdrawals on a key without IP restriction at all — but do not rely on the venue to make the decision for you.
- Know how to revoke, before you need to. Find the page once, calmly. The moment you need it is not the moment to go looking.
The pattern: a credential that can only read, only from your IP, and only for one purpose is not much of a prize.
Storage patterns, ranked
Environment variables — the common default. Fine, with the caveats that they are visible to child processes and to anything that can read the process environment, and that they often end up in shell profiles that get committed.
A config file with restricted permissions — good, if the permissions are actually restricted and the file is outside any directory you sync or version.
An OS keychain — best, and rare in practice. Worth preferring when offered.
Hardcoded in a config you copied from a README — this happens more than it should, usually by pasting a real key into an example. Check your client’s MCP config file for literal credentials before sharing a screen.
A note on convenience defaults
Servers that ship fully armed on first run are making a choice about priorities,
and it is worth reading it as such. The better-designed ones do the opposite:
one Bybit community server keeps trading disabled until an explicit
TRADING_ENABLED=true, offers a hard read-only mode, and caps order notional.
Another is read-only by construction and tells you in its README to use a
read-only key.
That posture correlates with the kind of care you want in something holding your credentials. It is not proof of anything, but it is signal, and it is free to notice.
FAQ
Can the model see my API keys?
Not through normal operation. The credentials live in the server process; the model sends tool calls and receives tool results. The leak path is indirect — a tool that returns a raw error containing the request, or a debug output that includes headers. That is why “sanitize tool outputs” appears in the specification’s requirements for servers.
Is it safer to write my own MCP server?
It removes the third-party trust question and replaces it with your own implementation risk, which is not obviously smaller — credential handling and error sanitisation are easy to get subtly wrong. A reasonable middle path is to use a well-maintained server and bound the credential: read-only key, IP whitelist, single purpose.
What if the server is open source — does that settle it?
It makes an audit possible, not automatic. The practical questions are whether anyone has read it, whether you are running the version that was read, and whether it updates on its own. Pinning a version you looked at is worth more than the abstract availability of source you did not.
How do I check whether a server is logging my keys?
Run it against testnet credentials with verbose logging on, then search the log output for the key string. This takes two minutes and answers the question directly, which is better than inferring from the README.