What beginners get wrong about kill switches for trading agents

A kill switch is a safety mechanism that forces a trading agent to close open positions and stop placing new orders when behavior drifts outside acceptable bounds. Beginners often imagine it as a single red button they can press during an emergency, but that mental model overlooks how the switch actually interacts with markets, permissions, and infrastructure. The most common mistakes involve assuming one switch is enough, placing it where the agent can reach it, and testing it only in calm conditions that do not resemble real failure modes. If you have never automated a trade before, it is worth understanding these pitfalls before you connect an agent to a live account.

What does a kill switch actually do?

In practice, a kill switch is a control that triggers two distinct actions. The first action is flattening, which means issuing orders to close any open positions so the agent is not exposed to continued market movements. The second action is revocation, which means removing the agent’s credentials or permissions so it cannot place new orders, reopen closed positions, or continue spending. Beginners sometimes assume the switch is simply a pause command that tells the agent to take a break, but a pause command only works if the agent is still listening and behaving cooperatively. A true kill switch must work even when the agent is misbehaving, unresponsive, or acting on a corrupted prompt.

Because Felix is non-custodial by construction, the kill switch operates at the level of permissions and scoped keys rather than by seizing funds from a shared pool. The owner retains control of the wallet, and the agent can only spend within predefined limits. When the switch triggers, it does not need to recover money from the agent; it only needs to remove the agent’s authorization to trade. This is a subtle but important distinction. If you are learning how to set guardrails for a trading agent, it helps to think of the kill switch as the final layer in a stack of limits, not as the entire safety system itself. You can read more about building that stack in our guide on how to set guardrails for a trading agent. The switch is not a substitute for thoughtful constraints, but it is the backstop that makes those constraints enforceable.

Why is one kill switch never enough?

New builders often install a single manual kill switch and assume the problem is solved. This is understandable if you are coming from manual trading, where your own judgment serves as the primary filter and your hands are already on the wheel. An automated agent, however, can place orders faster than you can react, and it can interpret a prompt in ways you did not intend. A single switch that relies on human reaction time creates a window of exposure that can last seconds or minutes. In fast markets, that window is enough to breach a budget cap, open an oversized position, or enter a market you did not mean to trade.

Layered controls are more reliable than one emergency lever. A proper safety stack includes pre-trade controls such as budget caps and position limits, per-trade controls such as maximum order size and allowed instruments, and post-trade controls such as the kill switch itself. Each layer catches a different class of error. Budget caps stop the agent before it spends too much. Position limits prevent concentration in a single instrument or market. Allowed instrument lists keep the agent away from complex products you are not ready to trade. The kill switch is the last resort when those earlier layers fail, or when market conditions change so quickly that the strategy itself becomes dangerous.

Relying on the kill switch alone is like installing a fire sprinkler but removing the smoke detectors. The sprinkler will eventually put out the fire, but by then the damage may already be severe. A beginner who automates for the first time often underestimates how quickly an agent can compound a small error into a large drawdown. The kill switch should exist, but it should be the least frequently used tool in your safety kit. If you find yourself reaching for it often, your guardrails are too loose.

What is the difference between flattening and revocation?

One of the most common beginner mistakes is treating flattening and revocation as the same thing. They are not. Flattening is the process of closing open positions so the agent is flat and no longer exposed to price movements. Revocation is the process of removing the agent’s credentials or permissions so it cannot trade again. If you flatten without revoking, the agent may immediately reopen the same position if its strategy logic is still running and it still holds valid credentials. If you revoke without flattening, the agent stops trading but your existing positions remain open, exposed to losses, funding costs, or liquidation.

The order matters. In most cases, you want to flatten first and revoke second, or you want both actions to occur as close to simultaneously as the infrastructure allows. If you revoke first, the agent may lose the ability to send the very orders needed to close its positions. This is especially important in derivatives such as perpetual futures, where an open position can accumulate funding costs or approach liquidation while you are scrambling to close it manually. A well-designed kill switch should handle both actions in a single flow, and it should not depend on the agent’s internal state machine to cooperate.

Scoped keys make revocation granular. You can revoke trading permissions while preserving read-only access for audit logs or portfolio tracking. This is one reason why AI agents need scoped API keys when trading real money. A scoped key lets you disable the dangerous permissions without destroying the integration entirely, which means you can inspect what the agent was doing even after you stop it. Beginners who use all-or-nothing keys often find themselves blind after a revocation because they destroyed the only credential that could read the account state.

Where should the kill switch live?

Beginners often embed the kill switch inside the agent’s codebase or host it on the same server. This is a mistake. If the agent crashes, the switch may crash with it. If the agent encounters a runaway loop or a memory leak, the switch may starve for resources. If the agent is compromised, an attacker can simply disable the switch before continuing to trade. The kill switch must live outside the agent’s control sphere.

In an MCP or REST API setup, the switch should be implemented at the infrastructure or key-management level. The agent should not be able to reach the mechanism that revokes its own credentials. For example, the switch might be a separate process that monitors account state and calls a revocation endpoint, or it might be a hardware security module rule that expires a key. The exact architecture depends on your setup, but the principle is constant: the entity that can kill the agent must not depend on the agent to stay alive.

This separation also applies to human interfaces. A dashboard that displays a big red button is useful, but if the dashboard is served by the same process that runs the agent, a failure in that process removes both the agent and your ability to stop it. Externalize the control. Use a different host, a different key, and a different notification path so that a failure in one system does not silently disable the other.

Some beginners ask whether they should put the kill switch inside their prompt, telling the agent to stop if it loses too much money. A prompt instruction is not a kill switch. It is a suggestion that the agent may ignore, misinterpret, or override if the logic path is corrupted. The switch must be external and enforced by the infrastructure, not by the agent’s willingness to follow advice.

Why do manual tests give false confidence?

New builders frequently test their kill switch by pressing it during a quiet afternoon while the agent is idle or placing occasional small orders. The switch works, the agent stops, and the builder concludes the system is safe. This test proves almost nothing. A real failure is rarely calm. It often involves the agent placing orders rapidly, across multiple markets, in response to a misinterpreted signal or a loop in the strategy logic.

A manual test in low-activity conditions does not exercise the sequencing of flattening and revocation under load. It does not reveal whether the close orders will be accepted by venues when volatility is high. It does not test whether the agent can reopen a position faster than the revocation takes effect. It also ignores the human element. In a real emergency, you may be distracted, asleep, or dealing with latency on your phone. The switch needs to be automated, not manual.

If you want to test safely, use paper trading to simulate a stressed agent that is placing orders at high frequency, then trigger the kill switch. Observe whether positions flatten completely, whether the agent manages to slip in new orders after revocation, and whether any orphaned orders remain open. Only after the switch behaves correctly under synthetic stress should you consider it ready for live trading. Remember that paper trading cannot perfectly replicate live market conditions, but it is far better than a quiet manual click.

Even after passing a stress test, you should treat the first live trading period as a continued test. Start with a small budget that you can afford to lose entirely. Trading can lose money, including everything, and a kill switch does not change that fundamental risk.

How does non-custodial design change the kill switch?

In many traditional setups, a trading bot operates within an account that the service controls. Stopping the bot may require withdrawing funds to a separate wallet, which adds steps and time. Felix is non-custodial by construction, which changes the logic of a kill switch entirely. The funds sit in a wallet you control, and the agent only has permission to trade within bounds. When you revoke that permission, the agent is instantly defanged. It cannot withdraw to itself, and it cannot steal funds.

This means the kill switch is about permission revocation, not asset recovery. You do not need to rush to pull money out of a shared account. You simply remove the agent’s ability to spend. The funds stay where they are, in your wallet, and you can move them at your convenience through an owner-approved withdrawal address. This architecture removes an entire category of custodial risks, but it also means you must design the switch around scoped keys rather than around account freezes.

Because the agent cannot steal, the kill switch can focus on stopping new harm rather than reversing past harm. That is a simpler and faster problem to solve. You can learn more about this architecture in our article on non-custodial trading for AI agents. The key insight is that non-custodial infrastructure lets you treat the kill switch as a precise surgical tool instead of a blunt emergency weapon.