How to add a kill switch to your MCP trading agent

A kill switch for a trading agent is a control that immediately flattens all open positions and revokes the agent's ability to place new orders. When you implement this through MCP, the agent itself can invoke the switch if it detects an internal error, or you can trigger it manually from the same chat interface where you monitor the agent. Felix exposes this as a scoped tool that operates independently of the trading strategy, so a bug in the agent's reasoning cannot disable the shutdown path. Trading with real money can lose everything, including the full balance, so the kill switch exists to limit the damage when software fails. The goal is not to optimize exits, but to stop the agent completely before a small error becomes a large loss. This article covers how to design, place, and test that switch using MCP and Felix safety controls.

What does a kill switch actually do for a trading agent?

A kill switch does not merely pause the agent or cancel its next order. It forces a full exit from every open position across all five market types, converts the resulting value back to cash or stablecoin, and then disables the scoped API key that authorizes trading. This is fundamentally different from a stop loss, which closes a single position when price moves against you, or a budget cap, which prevents new spending once a daily limit is reached. The kill switch is an emergency brake for the entire agentic system. It exists because an agent can misinterpret a data feed, loop on a corrupted prompt, or encounter an edge case in a perps venue or an options venue that its strategy logic never anticipated. When the switch triggers, trading stops immediately and the agent cannot restart until the owner explicitly generates and authorizes a new scoped key. Because Felix is non-custodial by construction, the funds remain in the owner's wallet throughout the entire process. The agent never held the assets in its own account, and the kill switch does not move money to any external address. Instead, it simply removes the agent's permission to spend. In practice, a well designed kill switch also logs the reason for shutdown, the timestamp, and the state of each position before flattening. That log becomes the starting point for any post incident review and helps you distinguish between a market event and a software bug.

How does MCP make kill switches easier to implement?

MCP, the protocol that connects agents like Claude or Cursor to external tools, turns a kill switch from a separate monitoring script into a native function call inside the agent's own context. Instead of building a dedicated server that watches the agent from outside and tries to intercept API traffic, you register the kill switch as an MCP tool that the agent can call directly. This design means the agent can halt itself when it notices its own confusion, such as when it generates an order size that exceeds a hard limit, or when it receives contradictory market data from a prediction market and a stock broker simultaneously. The operator can also type a natural language command in the same chat window to trigger the tool manually, without switching to a dashboard or writing a custom curl request. Because Felix normalizes order sizing in plain US dollars and abstracts venue specific contract math, the kill switch tool does not need custom logic for each market type. One standardized call tells the system to flatten across stocks, crypto, perps, options, and prediction markets. The agent does not need to know how a perps venue handles margin or how an options venue handles delta; it simply calls the tool. If you want to understand how the agent normally places orders through this same path, you can read our overview of how an AI agent executes orders through MCP. The kill switch uses the same normalized request shape, but targets the emergency exit flow. The result is that safety and execution share one protocol, which reduces the surface area for misconfiguration.

Where should the kill switch sit in your agent architecture?

The most important architectural decision is separation. The kill switch must live outside the agent's core strategy loop. If the strategy code contains a bug, an infinite loop, or a memory leak, the kill switch should still respond without depending on the strategy's internal state. In the Felix model, this means the kill switch is a system level MCP tool that the orchestration layer exposes, not a function defined inside the strategy prompt or the agent's reasoning chain. The agent can call it, but the tool itself is executed by the Felix infrastructure, not by the agent's own logic. This mirrors the security architecture we describe in the architecture that keeps AI trading agents secure in 2026. The scoped API key has distinct permission levels: one for trading within limits, and one for self revocation. The kill switch uses the revocation path, which means even if the agent's strategy prompt is compromised, the infrastructure layer can still disable the key. When designing your setup, place the kill switch in a lightweight monitor that watches either an explicit signal, a cumulative budget threshold, or a heartbeat timeout. If the agent fails to check in within a configured interval, the monitor triggers the switch. This avoids the scenario where a frozen agent leaves positions open indefinitely while the market moves. You should also consider giving the monitor its own lightweight notification channel, such as a webhook or a simple status page, so that a human operator knows the switch fired without having to watch the MCP chat continuously.

What are the practical steps to test a kill switch before going live?

Testing must happen in paper trading first. Paper trading on Felix simulates the full order lifecycle without real money, but it still exercises the same API paths, key revocation logic, and flattening sequence. Begin by creating a scoped key with intentionally tight limits. Then run your agent and force a condition that should trigger the switch. Suppose you configure a maximum position size of one hundred dollars and instruct the agent, through a deliberate prompt injection or direct command, to attempt a two hundred dollar position. The kill switch should flatten any partial fill and revoke the key before the agent can continue. Next, test the manual trigger. While the agent holds a small simulated position in an options venue or a perps venue, type the kill command into the MCP client. Verify that the positions close and the key becomes invalid within seconds. After that, test the heartbeat timeout. Stop the agent process abruptly and confirm that the watchdog triggers the switch automatically. Document the latency for each test. Live markets move while positions are closing, so the test should reveal how long the flattening takes across multiple venues. If you observe that an options venue takes noticeably longer than a crypto spot market, you can adjust your expectations and perhaps tighten position limits in the slower market. If you are preparing your first agent for real money, our guide on how to start an AI trading agent with hard limits covers the complementary controls that reduce the odds you ever need the kill switch. Remember that paper trading is not a guarantee of live behavior, but it is the only safe way to validate the mechanics before capital is at risk.

How do you keep a kill switch reliable without over-engineering?

A kill switch fails when it is too complex to maintain or too slow to execute. Resist the urge to add machine learning based anomaly detection or sentiment analysis to the trigger logic. The switch should respond to clear, quantifiable thresholds: total exposure exceeds a dollar limit, a single position violates a size cap, the agent generates an order for an unrecognized venue, or a human sends an explicit command. Use a simple state machine with three states: armed, triggered, and revoked. The armed state monitors the thresholds. The triggered state initiates flattening. The revoked state disables the key and notifies the owner. Do not attempt to make the kill switch smart enough to predict market crashes or judge whether a trade is fundamentally sound. Its job is to stop the agent, not to time the market or validate macroeconomic thesis. Keep the code path short. The MCP tool should make a direct call to the Felix API without intermediate message queues, databases, or third party services that could stall under load. If you run multiple agents, give each its own scoped key and its own kill switch. Sharing a switch across agents creates coupling; a false positive on one agent would shut down others unnecessarily. Review the switch logic quarterly. Prompts drift, and what looked like an abnormal trade six months ago may be normal today. Adjust the thresholds, but keep the mechanism simple. The best kill switch is one that you understand completely, because you will need to trust it during a crisis.

The exact request schema is in the docs; the shape looks like this.

curl -X POST https://api.felix.trade/v1/emergency/flatten \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"reason": "manual_kill", "scope": "all_positions", "revoke_key": true}'

How should you document and maintain a kill switch over time?

Documentation is part of the safety system, not an afterthought. Write a short runbook that lists the exact command or button that triggers the switch, the expected latency for flattening in each market type, and the steps to re authorize the agent after shutdown. Include a decision tree: if the switch triggers, does the operator investigate first, or does the owner rotate the key immediately? Store this runbook outside the agent's context, in a document or wiki that the human operator can read even if the MCP client is offline. Schedule a paper trading drill every month. During the drill, trigger the switch without warning and measure how long it takes for the agent to acknowledge the revocation. If the latency grows, investigate whether a new market integration or a larger portfolio is slowing the flattening process. When you upgrade the agent's strategy or add a new market type, such as prediction markets, revisit the kill switch to confirm it covers the new venue. The switch is only as current as your last test. Finally, make sure that everyone who has access to the MCP client knows how to trigger the switch. A kill switch that only the developer can find is not a safety tool; it is a hidden debug function.