Common mistakes running Claude trading agents with self custody

Traders who connect Claude to real markets through MCP tools often assume that non-custodial infrastructure alone will prevent losses. The reality is that keeping control of your funds only protects you from theft by the agent or the platform. It does not protect you from poorly scoped permissions, missing kill switches, or ambiguous prompts that cause the agent to trade outside your intent. The most common failures come from treating the custody model as a substitute for active risk controls rather than as a foundation that still requires careful configuration.

Understanding the difference between custody and control is the first step toward running an agent that does not put your capital at unnecessary risk.

Why does non-custodial access not eliminate trading risk?

Non-custodial trading means the owner retains the private keys and approves withdrawal addresses. The agent receives scoped spending authority within limits set by the owner, but it can still place orders, open leveraged positions, or accumulate exposure across multiple venues. A common mistake is to conflate the safety of the funds with the safety of the trading strategy. The custody model ensures the agent cannot withdraw your money to itself or to an external address you have not approved. This is a meaningful protection against theft, but it offers no protection against losses generated by the agent's own decisions.

When you authorize a live key, you are giving the agent the ability to commit your capital to the market. If the agent buys an asset that then declines in value, that loss is real and permanent regardless of who holds the keys. The same applies to leveraged products on a perps venue or short-dated options contracts. The agent may close the position and crystallize the loss, or it may hold and allow the loss to deepen. Either way, the non-custodial architecture does not intervene. It simply ensures that the agent cannot run away with what remains.

Some operators believe that because the funds sit in their own wallet, they can always recover if the agent behaves badly. This is partially true in the sense that you retain the ability to revoke the key and flatten positions manually. Revocation stops future actions. It does not undo past trades. If the agent has already spent half your budget on a losing position, that capital is gone. The custody model is explained in non-custodial trading for AI agents, but architecture alone does not constrain behavior. You must still define what the agent is allowed to do, how much it can spend, and under what conditions it must stop. Without these constraints, a well-meaning prompt can lead to real losses that no custody model can reverse.

What happens when API scopes are too broad?

Another frequent error is granting the agent broad API permissions because the setup feels simpler. A key that can trade stocks, crypto, perps, options, and prediction markets from a single prompt is powerful, but power without boundaries is dangerous. If your prompt asks the agent to rebalance a portfolio and the key has access to every market type, the agent may execute trades on venues you did not intend to use or in instruments you do not understand.

The problem compounds when the key has both read and write access across all markets. The agent might monitor a stock broker for signals, then decide to express that view through a leveraged perp contract on a different venue because the API normalizes order sizing in dollars and the agent does not distinguish between a cash equity and a derivative. The result is unintended leverage, different margin requirements, and exposure to funding rates you never considered. You might have intended a simple long equity position and instead find yourself holding a perpetual future with a liquidation price.

Scoped keys exist to prevent this. You can read about narrowing permissions in scoped API keys for trading agents. The principle is simple: the agent should only have access to what it needs, and nothing more. If you are testing a strategy on a perps venue, the key should not simultaneously hold authority over an options venue or a stock broker. If the agent only needs to read market data from a prediction market to inform decisions elsewhere, that portion of the key should be read-only.

Broad scopes also make debugging harder. When the agent takes an action you did not expect, you must trace through a larger permission surface to understand what happened. Narrow scopes limit the blast radius when a prompt is misinterpreted or when market conditions change faster than the agent can adapt. They also make it easier to reason about worst-case loss. If the key is scoped to a single market with a fixed dollar cap, you can calculate the maximum possible damage. If the key is global, your downside is much harder to bound. Developers who build their own key management often overlook this because they focus on authentication rather than authorization. An agent-ready API separates these concerns so you can grant trading authority without granting full account access.

How do ambiguous prompts create unintended positions?

Language models interpret intent from text, and text is inherently ambiguous. A prompt like trade the breakout or manage my risk can be executed in dozens of ways depending on how the model weights recent context, market data, and its own training. One common mistake is to assume that Claude understands your risk tolerance because you described it in plain English. It does not. The model understands tokens and probabilities, not your personal financial situation.

Suppose you tell the agent to buy when the market looks weak. The model must interpret what weak means, which timeframe to check, and how much capital to deploy. Without explicit dollar limits, time bounds, and instrument definitions, the agent may open a position that is far too large, hold it too long, or trade an asset you never mentioned. The API normalizes venue-specific contract math so orders are sized in plain US dollars, but the agent still decides what that dollar amount should be. If the prompt implies urgency, the model may increase size to match its interpretation of the opportunity.

Another subtle issue is temporal ambiguity. If you say hold until the trend reverses, the agent must decide what constitutes a reversal. It might use a five-minute candle on one execution and a daily candle on another. It might average into a falling position because it interprets the dip as temporary weakness rather than a structural reversal. These are not bugs in the model. They are the natural consequence of giving a probabilistic system an underspecified task.

You should treat prompts as function specifications, not conversations. Define the input data, the decision logic, the maximum spend, and the exit conditions in concrete terms. Specify the exact market, the maximum dollar size, the time window for evaluation, and the precise criteria for entry and exit. Vague instructions produce vague results, and vague results in live trading can erase capital quickly. The non-custodial model keeps the agent from stealing your funds, but it cannot keep the agent from following a poorly written prompt to its logical conclusion.

Why is a kill switch not enough without an exit plan?

Many operators install a panic button and believe they have covered the safety requirement. A kill switch that flattens positions and revokes the key is essential, but it is a reactive tool, not a risk management strategy. The mistake is to rely on the kill switch as the primary form of protection rather than as a last resort. By the time you hit the switch, the agent may have already crossed your drawdown limit, opened illiquid positions that cannot be closed instantly, or triggered fees and funding costs that continue to accrue.

An exit plan should be defined before the agent starts trading. This means setting hard budget caps, position limits per instrument, and automated stop criteria that trigger before human intervention is needed. The process for setting these boundaries is covered in how to start an AI trading agent with hard limits. The kill switch should exist to catch failures that automated limits miss, not to replace those limits entirely.

Consider a scenario where the agent is trading options on a volatile underlying. The kill switch can revoke the key and attempt to flatten, but options markets may lack liquidity at the exact moment you need to exit. The automated exit plan, configured with position limits and delta caps, would have prevented the agent from entering the oversized position in the first place. Similarly, a perps position with high leverage can be liquidated by the venue before your kill switch even fires. The kill switch stops the agent from adding more risk, but it does not stop the market from moving against an existing position.

Effective safety layers work in sequence. The first layer is prompt clarity and scoped keys. The second layer is automated limits on budget, position size, and drawdown. The third layer is continuous monitoring with alerts. The kill switch is the final layer. If you skip the first three and rely only on the last, you are essentially driving without brakes and hoping the emergency parachute deploys in time. It might, but the damage is usually already done. Building multiple layers takes more time, but it is the only way to keep a probabilistic system within boundaries that protect your capital.

How should you test before authorizing live keys?

Paper trading exists for a reason, yet many users rush to live trading because the non-custodial model feels safe. The custody model prevents theft, but it does not prevent bad strategy. Paper trading lets you observe how the agent interprets your prompts, how it handles data delays, and whether it respects the scoped limits you configured. Common testing errors are discussed in common mistakes developers make with paper trading for AI agents.

You should run the agent in paper mode long enough to see it encounter at least one volatile session or data anomaly. Watch whether it retries failed orders aggressively, whether it misreads a stale price as a signal, and whether it stays within the dollar budgets you set. Paper trading on Felix uses the same API paths and normalization logic as live trading, so behavior should be consistent. The only difference is that no real money moves. This makes it the ideal environment to discover that your prompt causes the agent to double position size when it is confused, or that it ignores your stop criteria because they were phrased as suggestions rather than hard rules.

Live trading requires explicit owner authorization of a key. This step is a deliberate speed bump, not a formality. Use it as a checkpoint to review your prompt, your scopes, your budget caps, and your exit plan. If you cannot articulate why the agent is ready for real money, it is not ready. Start with the smallest possible budget cap and increase it only after the agent demonstrates consistent adherence to your rules across different market conditions.

One common testing mistake is to treat paper profits as evidence of live readiness. Paper results show that the agent can execute the mechanics of your strategy. They do not show that the strategy is profitable, that it handles real slippage, or that your psychology will allow you to let the agent run unattended. Trading can lose money, including everything, and paper success can create false confidence. Test for behavior, not for returns. Verify that the agent does what you intend, that it stops when it should, and that it fails safely when data is bad. Only then should you authorize the live key. Remember that authorization is reversible. You can revoke the live key at any time and return to paper trading to refine your approach. The goal is not to prove the agent can trade, but to prove it can stop.