What people get wrong when they let LLMs trade with real money

Most losses from LLM-powered trading agents do not come from the model itself. They come from owners who skip hard limits, misunderstand scoped permissions, or deploy an agent to live markets without testing how it behaves when data is ambiguous or delayed. Keeping custody of your funds is necessary but not sufficient. You also need to configure the agent so it cannot spend beyond a strict ceiling or hold positions that violate your risk plan, because an LLM with unrestricted access can lose money faster than a human can intervene.

Why do LLM trading agents lose money before they place a single trade?

Many owners believe that a non-custodial setup is safe by default. They connect an LLM through MCP tools or the REST API and grant it a key that can read balances and send orders, but they never scope the key to specific markets, budget caps, or allowed actions. The result is an agent that can trade across stocks, crypto, perps, options, and prediction markets even if the owner only intended it to operate in one. This is a configuration error, not a model failure. The agent is not misbehaving; it is doing exactly what the key allows. Why most people misunderstand scoped API keys explains how keys should restrict the agent to a single market type, a maximum position size, and a daily spend limit. Without these constraints, the agent is effectively given a blank check within the wallet. The owner still holds the keys, but the agent can lose everything inside the account through normal trading losses before the owner notices. Suppose you connect an agent through an MCP client and give it a key that can trade all five market types. The prompt says 'trade crypto.' The LLM might interpret that as permission to trade perps because it views them as crypto derivatives. A scoped key prevents this by restricting the key to spot markets only, regardless of what the prompt says. The exact request schema is in the docs; the shape looks like this.

{
  "budget_cap_usd": 500,
  "allowed_markets": ["stocks", "prediction_markets"],
  "max_position_usd": 100,
  "panic_flatten": true
}

Setting these scopes before the agent starts is the only way to ensure the infrastructure enforces your intent when the LLM interprets language creatively. It also protects against prompt injection or accidental commands from other tools in the MCP context. A scoped key is a physical limit that the model cannot talk its way around.

How does bad prompt design turn safe strategies into dangerous orders?

An LLM does not understand intent. It understands tokens. When an owner writes a prompt like 'trade based on the news and maximize returns,' the agent has no boundary to define what a valid trade looks like. It may interpret a minor headline as a signal to size up aggressively, or it may confuse a ticker symbol because the prompt did not specify exact identifiers. Worse, if the prompt lacks negative instructions, the agent does not know what it is forbidden to do. It might trade options when the owner only wanted stocks, or it might hold a leveraged perp position overnight because no one told it to flatten before a certain hour. How to set guardrails for a trading agent covers the prompt patterns that reduce this risk. The safest approach is to treat the prompt as a strict contract. Specify the exact conditions for entry, the maximum dollar size per trade, the markets it is allowed to access, and the specific events that should trigger a halt. If the prompt is vague, the agent will fill the gaps with whatever pattern it learned during training, which may not match your risk tolerance. Imagine a prompt that says 'buy when sentiment is bullish.' The LLM might scan social media, find a bullish comment about a small cap stock, and calculate a position size based on its own confidence score. Because the API normalizes venue-specific contract math and sizes orders in plain US dollars, the number it sends might be exactly what it intended, which makes an oversized order even more dangerous. The prompt must define the dollar amount, and the system must cap it. Leaving either to the model is a mistake. Even a well-intentioned prompt that says 'be careful' is useless because the model has no shared definition of carefulness. You must translate risk tolerance into rules that can be expressed in code and checked by the API before an order reaches a venue.

Why is paper trading not enough to prove an agent is safe?

Felix offers paper trading for testing, and many owners treat a profitable week in simulation as proof that the agent is ready for live markets. This is a mistake. Paper environments do not replicate the latency, slippage, partial fills, or downtime that occur at real venues. An agent that looks brilliant in simulation may fall apart when an API response is delayed by five seconds and the LLM retries the order three times. Paper trading also does not stress test the safety layer. The kill switch, spend caps, and drawdown limits may never be triggered in a calm simulation. You need to intentionally test what happens when the agent hits its budget cap mid-trade, or when the panic switch is activated while positions are open. The goal of testing is not to prove the strategy makes money. It is to prove the agent cannot lose money in ways you did not anticipate. Live trading requires explicit owner authorization of a key, and that authorization should only happen after you have observed the agent fail safely in paper. Failure in paper is valuable. It teaches you where the guardrails need to be tighter. If you only watch profitable days, you learn nothing about how the agent behaves when the market moves against it or when the data feed lags. You should also introduce artificial errors during paper trading. Feed the agent stale prices, simulate a rejected order, and watch whether it retries responsibly or spirals into repeated attempts. An LLM that does not handle failure gracefully in paper will not handle it gracefully when real money is at stake.

Why do people confuse self-custody with safe automation?

Non-custodial infrastructure means the funds sit in a wallet the owner controls, and the agent can never withdraw to itself or steal. Withdrawal addresses are owner-approved only. This is a strong security property, but it is not the same as trading safety. An agent that cannot steal funds can still lose them through bad trades. Self-custody protects you from the infrastructure provider, not from the agent's decisions. The owner must still set budget caps, position limits, and drawdown thresholds that constrain what the agent can do with the money inside the wallet. How spend caps and drawdown limits work for AI trading agents describes how these controls interact. If you skip them because you believe non-custodial equals non-risky, you have misunderstood the difference between custody and control. One key and one API give you access to five market types, which is convenient but also means that a single oversight can expose your capital across multiple asset classes. A multi-market agent that trades stocks and prediction markets simultaneously might concentrate risk in ways that look uncorrelated in a backtest but move together in a crisis. The only way to prevent this is to set hard limits per market and per agent. The wallet is yours, but the agent can empty it legally, one bad trade at a time, if you do not configure the rails. Think of self-custody as the lock on your front door. It keeps strangers out, but it does not stop a guest you invited from knocking over a candle. The guest is the agent, and the candle is an oversized position in a volatile market.

What makes a kill switch useless even when it exists?

A panic switch that flattens and revokes access is only effective if it is wired correctly and tested under realistic conditions. Some owners configure a kill switch but never activate it during paper trading, so they do not know whether it closes positions fast enough or whether it leaves orphaned orders in the market. Suppose the agent holds an options spread and the kill switch sends market orders to exit. In a fast-moving underlying, those market orders may fill at prices far worse than expected, turning a controlled loss into a catastrophic one. The kill switch must be paired with an exit plan that defines how to flatten each position type. It also needs to revoke the agent's API access immediately so the LLM cannot place new orders while the positions are being wound down. If the switch only stops new commands but leaves existing orders open, the agent is not truly stopped. The safety controls include scoped keys, budget caps, position limits, exit plans, and the panic switch. Each layer is important, but the kill switch is the last line of defense. If you have not tested it with open positions in paper, you do not know whether it protects you or accelerates your losses. Test it when the market is calm and again when paper trading shows volatility. Observe not just whether the positions close, but how they close. You should also verify that the kill switch works if the MCP client or the LLM itself is in a loop. If the agent is retrying a failed order and you hit the switch, the retry logic must stop immediately. A kill switch that only halts new reasoning but not pending tool calls is incomplete.

How should position sizing work when the LLM decides the trade?

The Felix API normalizes venue-specific contract math so that orders are sized in plain US dollars. This removes a common source of error, but it does not remove the need for human-defined limits. Owners often make the mistake of letting the LLM compute position size based on its own confidence score or on a vague percentage of the wallet. This is dangerous because the model has no intuition for risk. How to size positions for an AI trading agent from first principles explains why the size should be derived from a fixed rule set, not from the LLM's reasoning. The owner should set a hard maximum position size in dollars, a maximum number of concurrent positions, and a total exposure limit. The LLM can then select which instrument to trade, but the dollar amount should be clamped by the system. If the LLM requests a trade that exceeds the cap, the API should reject it. This prevents the model from overconcentrating in a single position because it misread a headline or misunderstood a signal. Suppose the agent sees a large move in a perps venue and decides to increase size to capture the trend. If the prompt allows variable sizing and the system does not enforce a hard cap, the agent might place a position that represents most of the wallet. Normalizing orders in US dollars helps, but only if the upper bound is set by the owner before the agent starts. Sizing is a risk decision, not a prediction task. The LLM should predict direction or select instruments. The owner should decide how much money is allowed to be wrong. When you let the model size positions, you are letting it decide how much to lose on its next mistake. That is not a strategy. It is a gamble with a chat interface.