How kill switches protect trading agents from runaway losses in 2026

A kill switch is an owner-controlled emergency control that immediately flattens every open position and permanently revokes an agent's API access. It exists because an agent can misinterpret a signal, loop on a bad prompt, or encounter a market condition its logic does not handle, and it can do so across stocks, crypto, perps, options, and prediction markets at a speed no human can match. When triggered, the switch stops the agent from opening new trades and starts an orderly exit from existing ones, leaving the owner in full control of the funds. It is the last line of defense, not a substitute for budgets or position limits, but the mechanism that makes those limits enforceable when everything else fails.

What exactly does a kill switch do?

At its core, a kill switch performs two distinct actions that happen in sequence. First, it flattens positions, which means issuing exit orders for every open trade the agent has entered, whether that is a long stock position, a perpetual future, an option spread, or a prediction market bet. Flattening turns market exposure back into cash or stable value inside your own account, and it does so without asking the agent to agree. Second, it revokes the scoped API key that the agent uses to send orders, which cuts off all new instructions to the trading venues and renders the agent harmless. Because Felix is non-custodial by construction, the agent never held your assets in its own wallet; the funds always sat in a wallet you control. Flattening simply returns your portfolio to a neutral state within that wallet, and revocation ensures the agent cannot spend what remains or open new positions. The two actions together mean the agent is both disarmed and removed from the premises.

Some owners confuse a kill switch with a stop-loss order, but they are fundamentally different tools with different roles. A stop-loss is a rule the agent follows inside its strategy, a conditional order it places on a specific position. If the agent is malfunctioning, it may ignore that rule, fail to place the order, or place it on the wrong instrument. A kill switch is an external control that bypasses the agent entirely. It does not ask the agent to cooperate; it changes the state of the world around the agent by removing its access and closing its trades. This distinction matters because an agent that is looping on a bad prompt, hallucinating a trading signal, or interpreting a corrupted data feed will not save itself. Only an external authority with the power to override the agent can stop the damage. The stop-loss is a tactic inside the strategy; the kill switch is a strategic override of the agent itself.

How fast can a trading agent spiral out of control?

An agent connected to an API can evaluate data and send orders in milliseconds. In a single minute, it could submit dozens of requests across multiple market types, each one sized in plain US dollars but potentially compounding into a large directional exposure. A logic error that doubles position size on each iteration, a prompt injection that convinces the agent to ignore its budget, or a simple misinterpretation of a dollar-based sizing instruction can turn a small allocation into a significant loss before a human owner notices the first notification. The risk is not theoretical. Any system that can act faster than its operator can react needs a brake that operates at machine speed, not human speed. A kill switch is that brake, but it only works if it is wired to trigger automatically or if the owner is watching a dashboard with one-tap access.

The danger increases when an agent trades across correlated markets with a single API key. Suppose an agent is designed to hedge a stock position with an options contract, but a bug causes it to double down instead of hedge. It might then enter a perp market to offset the options error, creating a third layer of exposure that moves in the same direction as the original mistake. By the time an owner opens a dashboard to check the profit and loss, the agent may have built a fragile, cross-market position that is sensitive to small price moves. Without a kill switch, the only way to stop this is to manually log into multiple venues, find the positions, and close them one by one. That process is slow, error-prone, and often impossible to complete before the market moves again. The kill switch collapses that multi-step manual process into a single command that reaches every venue through the same API.

What should a kill switch flatten and revoke?

A kill switch should be comprehensive. When an owner triggers it, there is no time to diagnose which positions are good and which are bad. The switch should flatten everything across all five market types: stocks, crypto, perps, options, and prediction markets. It should also revoke the specific API key the agent is using, not just pause the process or mute alerts. Scoped keys make this precise; if you run multiple agents, revoking one key does not disable the others. After revocation, the agent should be unable to re-authenticate or obtain a new key without explicit owner approval. Some owners hesitate at the idea of closing good trades, but a switch that asks for confirmation per position is not a kill switch. It is a dashboard. The purpose of the switch is to end the emergency, not to manage the portfolio.

In addition to flattening and revoking, a well-designed kill switch should emit a clear audit trail. The owner needs a record of exactly when the switch was triggered, which positions were closed, at what prices, and what the resulting cash balance was. This is where audit logs and observability become essential. A log entry that says the switch fired at 14:03:22 with twelve exit orders is far more useful than a generic error message. The log should also capture the reason for the trigger, whether it was manual, automated, or part of a broader system shutdown. These logs are not just for post-mortems; they are evidence that your safety controls functioned as designed, and they help you refine thresholds for future automated monitors.

How do you build a kill switch that actually works?

The most important principle is independence. The kill switch must not depend on the agent to detect its own failure or to initiate its own shutdown. If the agent is the component that decides whether it is misbehaving, a serious bug may disable that decision logic along with the trading logic. Instead, the switch should be wired to an independent monitor, a separate process, or a manual owner control that watches the agent from the outside. This monitor can track simple metrics like the number of orders per minute, total dollar exposure, or the rate of change in position count, and it can fire the switch when those metrics cross thresholds that the owner defines in advance. The monitor does not need to understand the strategy; it only needs to understand what normal looks like, and it needs permission to stop everything when normal is violated.

Manual kill switches are necessary even when automated monitors exist. An owner may see news, a market structure change, or a personal reason to exit immediately, and no automated rule will capture that context. The manual switch should be accessible from a single action, not buried in menus or behind multiple confirmation screens. Every second of delay is a second the agent can continue trading. For developers building on Felix, the kill switch is available as a first-class operation through the same API that handles orders, so it can be triggered programmatically or bound to a physical button, a chat command, or an external monitoring service. The consistency of the API means you do not need custom integrations for each venue; one call reaches every market type.

The exact request schema is in the docs; the shape looks like this for a programmatic trigger via an MCP tool or a direct REST call.

{
  "action": "flatten_and_revoke",
  "scope": "all_positions",
  "reason": "owner_triggered",
  "agent_key": "YOUR_KEY"
}

This payload tells the system to exit every position tied to the specified key and to disable that key permanently. The response should confirm the number of exit orders submitted and the revocation status. You should never hardcode a real key into a script that triggers the switch; instead, reference it through environment variables or a secure secret store so that the switch itself cannot be triggered accidentally by a leaked configuration file. If you are using an MCP client like Claude or Cursor, the same operation can be exposed as a tool that the owner invokes directly, keeping the human in the loop even when the agent is autonomous.

How do you test a kill switch before going live?

Testing a kill switch in paper trading is mandatory. Paper trading lets you simulate a runaway agent without risking capital, and it lets you verify that the switch behaves exactly as you expect. You should deliberately create an agent that sends orders too quickly, exceeds a budget, or enters conflicting positions, and then trigger the switch while observing the results. Check that all positions flatten, that the key is dead, and that the agent cannot resume trading by reconnecting. You should also measure how long the flattening takes; if it is too slow for your comfort, you may need to reduce position count or simplify the strategy before going live. Repeat the test after any major change to the agent logic, because a new prompt or a new market type can alter the order flow in ways that affect switch performance.

Testing should also include your manual trigger mechanism. If you plan to stop the agent from a mobile device, a chat interface, or a dashboard, practice the exact sequence until it is muscle memory. Panic is not a good time to learn a new interface. Document the steps and keep them accessible, because the moment you need a kill switch is usually the moment you least want to search through documentation. Our guide on how to execute orders safely with an AI agent in 2026 covers the broader safety workflow that includes kill switch testing as a standard step. Treat the test like a fire drill: it is inconvenient, but it proves the exits work.

What are the limits of a kill switch?

A kill switch cannot recover money that has already been lost. It can only stop future losses. There will always be a gap, however small, between the first bad trade and the moment the switch engages. This is why kill switches work best alongside hard limits that agents cannot cross, such as budget caps, position size restrictions, and scoped keys that prevent the agent from accessing markets you never intended it to trade. These limits narrow the window of damage so that the kill switch, if ever needed, is closing a small hole rather than a flood. The switch is the emergency brake, but the guardrails are what keep you from needing it.

Kill switches also cannot fix bad strategy logic. If an agent has a flawed edge but stays within its budget, the switch will not fire because there is no technical malfunction to detect. The owner still loses money slowly through poor trades. Trading can lose money, including everything, and the switch protects you from the agent, not from the market or from your own design errors. It is a safety net, not a performance filter.

How do kill switches fit into a multi-agent system?

In a multi-agent setup, each agent should have its own scoped key and its own kill switch. This prevents a bug in one agent from forcing you to shut down an entire portfolio of unrelated strategies. However, you should also consider a master switch that monitors the aggregate exposure of all agents. If three agents are each within their individual limits but collectively create a dangerous concentration in a single asset, a system-level switch can flatten everything. This layered approach gives you fine-grained control over individual agents and coarse-grained protection against systemic errors. You can read more about architecture in our multi-agent trading system guide. The same principle applies: independence, testing, and clear records of every trigger event.

A kill switch is not an admission of failure. It is a recognition that autonomous systems operate at a speed and complexity that exceeds human reaction time, and that ownership means retaining the power to stop what you started. The best agents are built with the assumption that something will go wrong, and the best owners are prepared to act when it does. Build the switch, test it in paper, keep it independent, and know exactly how to reach it. The few seconds it takes to flatten and revoke are the most valuable seconds in agentic trading.