MCP trading security checklist
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.
Connecting a model to an exchange takes about ten minutes. Working out what you just authorised takes longer, and most guides skip it entirely.
This is ordered by what survives things going wrong. The items near the top hold even if the software is buggy, malicious, or updated into something else. The items near the bottom are good practice that depends on components behaving.
1. Key permissions — the layer that does not depend on software
☐ Use a key that cannot do what you have not decided to allow. This is the only boundary enforced by a party with no stake in your configuration being correct. A key without trade permission cannot be talked into placing an order by any prompt, any server bug, or any mislabeled tool. Start read-only and widen deliberately.
☐ Confirm withdrawals are off — and understand how your venue enforces it. On Binance the constraint is stronger than a checkbox: withdrawals cannot be enabled on a key without IP access restriction at all. The IP filter is a precondition for the permission, not an option beside it. Knowing that is more useful than remembering to untick something.
☐ Set an IP whitelist. It bounds the damage from a leaked key to traffic from one address. On Binance it has a second effect worth knowing: a key with no IP whitelist has its spot trading permission automatically switched off after a period, by design. If your automation mysteriously stops trading, this is a strong first suspect.
☐ Verify the key’s permissions by asking, not remembering.
Binance exposes GET /sapi/v1/account/apiRestrictions, returning ipRestrict,
enableReading, enableWithdrawals, enableFutures and others. One request
tells you what a key can actually do. Do this after setup, not instead of it.
☐ One key per purpose. A key shared between your MCP server, a bot and a dashboard means three paths to one set of permissions and no way to tell which was used. Separate keys make revocation surgical.
☐ If the venue has no API keys, learn its model before assuming. Hyperliquid has none — a master account approves an API wallet (agent wallet) to sign on its behalf. The documentation states plainly that “API wallets are only used to sign” and that querying account data requires the master’s actual address. Whether an agent wallet can withdraw is not stated by Hyperliquid; its official SDK shows that fund-moving actions are user-signed and carry no account address field, so there is no way to express moving the master’s funds in an agent signature. Treat that as a structural property to verify on your own setup, not a guarantee to rely on.
2. Server trust — you are installing something that holds your keys
☐ Know whether it is official. Alpaca and OKX publish their own MCP servers, and IBKR offers a hosted connector. For Binance, Bybit and Hyperliquid, what is widely used is third-party code. That is not a reason to avoid it, but it is a different trust decision from installing something the venue shipped, and worth making with your eyes open. Check the venue’s own documentation rather than assuming — this landscape moves.
☐ Read how it handles credentials. Where are keys read from — environment, config file, somewhere else? Are they ever logged? Does anything leave the machine? A README that cannot answer those three questions is a reason to look at another server.
☐ Prefer default-off trading.
The better-designed servers ship with mutation disabled. One Bybit community
server requires an explicit TRADING_ENABLED=true before mutating tools work at
all, offers READONLY_MODE=true to hard-block mutations, and caps estimated
order notional via MAX_ORDER_SIZE_USDT. That is the pattern to look for. A
server that is fully armed on first run is telling you about its priorities.
☐ Check for a testnet flag.
Servers that expose one (for example a BINANCE_TESTNET setting) make the safe
path the easy path.
☐ Pin the version.
notifications/tools/list_changed exists in MCP precisely because a server’s
tool set can change. A server you audited as read-only can gain an
order-placement tool in an update you did not read.
☐ Re-check the tool list after any update. Same reason. This takes thirty seconds and is the item most likely to be skipped.
3. Client behaviour — where the approval actually happens, or does not
☐ Find out whether your client asks before executing a tool call.
The MCP specification says “there SHOULD always be a human in the loop with
the ability to deny tool invocations” — SHOULD, not MUST, and it explicitly
declines to mandate any interaction model. Whether you are asked is a property
of your client, not of the protocol. Test it with a harmless mutating call
before you assume.
☐ Confirm you see tool inputs, not just tool names.
The spec recommends clients “show tool inputs to the user before calling the
server”. For an order, the inputs are the trade: symbol, side, quantity, price.
A prompt that says “Claude wants to use place_order. Allow?” without showing
the arguments is not an approval step in any meaningful sense.
☐ Watch for approval fatigue. A client that asks about everything trains you to click yes. If read-only calls are also prompting, the prompt has stopped carrying information. Separate the tools that change state from those that do not.
4. Limits in code — the part nobody else can do for you
☐ Do not express limits as prompt instructions. A limit in a prompt is a strong input to a probabilistic process. It holds most of the time, which is why you stop checking, and fails unpredictably in exactly the unusual situations that motivated it.
☐ Enforce a per-trade size cap. Evaluated before submission, as a function that can return false.
☐ Enforce a daily-loss breaker. The arithmetic argument: recovering from a loss requires a larger gain than the loss itself, and the gap widens fast. A breaker is worth more than the trades it prevents.
☐ Enforce a cooldown after consecutive losses. The point at which discipline is weakest is the point at which it matters most. This is precisely the kind of rule that should not depend on how you feel.
☐ Exempt closing orders from your breakers. A breaker that prevents you from closing a position is worse than no breaker. Check this explicitly — it is an easy thing to get wrong and an expensive thing to discover live.
5. Operational
☐ Start on testnet. Every parameter mistake you will make is cheaper there. ☐ Log tool calls. The spec recommends clients “log tool usage for audit purposes”. For trading it is also your review material. ☐ Do not let the model read untrusted text while holding order tools. News pages, scraped forums and other tools’ output land in the same context as your instructions, and the architecture does not distinguish them. ☐ Know how to revoke. Practise it once. The moment you need it is not the moment to find the page. ☐ Set a calendar reminder to re-audit. Permissions drift, servers update, and the setup you reasoned about carefully in March is not the one running in September.
What this does not cover
Exchange-side account security (2FA, withdrawal address whitelists, anti-phishing codes) — necessary, well covered elsewhere, and not specific to MCP. Nor does it cover whether any particular server is trustworthy: we have not audited any of them, and a checklist cannot substitute for that.
FAQ
What is the single most important item here?
Key permissions. Everything else depends on software behaving as expected; the permission set on your API key is enforced by the exchange regardless of what your machine does. A read-only key makes most of the rest of this list precautionary rather than load-bearing.
Is it enough if the MCP server has a read-only mode?
It helps, and prefer servers that have one. But it is a control inside the component you are trying to bound, configured by whoever wrote it. It protects you from the model; it does not protect you from the server being buggy or updated. Set the key permission as well — the two guard against different failures.
How do I know if my client asks for approval before a tool call?
Test it rather than assume it. Trigger a harmless mutating call — cancel a non-existent order, or place an order on testnet — and watch what happens. The MCP specification recommends a human be able to deny tool invocations but does not require it, so behaviour varies between clients.
Do I need all of this for read-only access?
No. Read-only access is genuinely low risk, and sections 1 and 2 largely cover it — use a key that cannot trade, and know whose code is holding it. The approval and limit machinery exists for the small number of calls that move money.