How to control the risks of non-custodial trading with real money

Non-custodial trading keeps your funds in a wallet you control while an agent places orders on your behalf. The agent cannot withdraw to itself or any unapproved address, so theft by the agent is impossible. Market risk, leverage, and prompt errors remain, and trading can lose everything. You control these risks through scoped keys, budget caps, position limits, exit plans, and a kill switch that flattens positions and revokes access.

What does non-custodial really mean for agent trading?

In a custodial setup, you deposit funds into a third-party account and grant a bot access to trade there. The bot operator or platform holds the assets, and your recourse depends on their internal controls and solvency. In Felix’s model, the agent receives a scoped key that can sign orders against venues where your wallet is already connected, but the key cannot initiate withdrawals. The owner approves every destination address in advance, and the agent itself never holds the seed phrase or private key to the underlying wallet. This means compromise of the agent, the API, or the model provider does not lead to direct theft of the wallet. However, it does not mean the agent is harmless. An attacker who gains control of the agent could still burn through the trading budget by placing losing trades, or open massive leveraged positions that liquidate. Non-custodial architecture shifts the threat from theft to unauthorized spending, which is why spending limits are as important as withdrawal blocks. The distinction is subtle but critical: you are protected from external theft, but not from internal error. How a Claude trading agent trades without taking custody of your funds explains the wallet architecture and key scoping in more detail.

What risks remain even when the agent cannot steal funds?

Removing custody removes one threat model, but several others remain. Price gaps can move against a position faster than an agent can react, especially in leveraged perpetual futures or thin options markets. A prompt that is slightly ambiguous can cause the model to size an order incorrectly, hedge the wrong leg, or interpret a stop-loss instruction as a market entry. Connectivity drops can leave orders unmonitored, and venue API changes can cause unexpected errors that the agent interprets as signals. Model drift is another concern: a prompt that behaved conservatively in testing may become aggressive when confronted with new market language or unusual volatility. There is also the risk of overfitting to historical patterns that the agent treats as rules, leading it to take positions in conditions it has never encountered. Even with perfect code, trading can lose money, including the entire budget allocated to the agent. These risks are not bugs; they are inherent to autonomous execution in volatile markets. The fact that the agent cannot run away with your wallet is cold comfort if it loses the same amount through a sequence of poorly timed entries or leveraged liquidations.

How do scoped keys and budget caps limit exposure?

The first layer of control is the key itself. A live trading key should be scoped to specific venues and specific action types, so an agent that is supposed to trade prediction markets cannot accidentally or maliciously route orders to a perps venue. Budget caps set a hard ceiling on the notional value the key can deploy over a given period, while position limits restrict the maximum exposure in a single market or across correlated markets. These are not suggestions enforced by the agent; they are enforced by the infrastructure before the order reaches the venue. You can think of the key as a prepaid card with merchant and transaction limits, rather than a blank check. The exact request schema is in the docs; the shape looks like this:

{
  "key": "YOUR_KEY",
  "budget_cap_usd": 5000,
  "max_position_usd": 2000,
  "allowed_venues": ["stocks", "prediction_markets"],
  "withdrawal_addresses": []
}

Budgets reset on a schedule you choose, and once the cap is hit, the key refuses additional orders until you manually raise or reset the limit. This turns a potentially unbounded loss into a known, pre-approved maximum. Position limits also prevent concentration risk, which is especially important when an agent trades multiple markets through a single API. You should set both values conservatively relative to your total portfolio, because the goal is to survive mistakes, not to optimize for speed. How the safety model for trading agents differs from trading bots covers why static bots rarely offer this kind of granular, owner-controlled policy enforcement.

What is an exit plan and why does every agent need one?

An exit plan defines the conditions under which the agent must flatten all positions and stop trading. Common conditions include:

• ·A drawdown threshold measured against the session budget.
• ·A time-of-day window that forces a flat state outside trading hours.
• ·A correlation spike that indicates the agent is overexposed to a single macro factor.
• ·A simple timer that flattens all positions after a set interval unless explicitly renewed.

The plan is a prompt-level instruction, but it is also backed by infrastructure-level enforcement. If the agent breaches a hard limit or if you trigger the panic switch, the kill switch flattens positions and revokes the key within seconds. The revocation is immediate and does not depend on the agent agreeing or even being online. You remain the owner of the funds, but the agent loses all access. This is the final layer when softer controls fail. An exit plan is not a vague intention to sell if things go badly; it is a specific, pre-authorized set of instructions that the system executes automatically. Without it, an agent can hold a losing position through a weekend gap or a news event, turning a manageable drawdown into a total loss. The kill switch is not a substitute for thoughtful position sizing, but it is the backstop that makes thoughtful position sizing survivable.

Why is paper trading not enough before going live?

Paper trading lets you test integrations, prompt logic, and order sizing without capital at risk. It is a necessary step, but it does not simulate slippage, partial fills, or the psychological pressure of real losses. More importantly, paper environments do not test the authorization flow. Moving to live trading requires explicit owner authorization of a specific key, which is a deliberate human action that should be paired with a checklist. Before you authorize, you should verify that scoped keys, budget caps, position limits, and a kill switch are all active and configured for the intended market regime. You should also test the kill switch during paper trading to confirm it flattens positions and revokes access as expected. How trading changes when you switch from manual execution to an autonomous agent discusses the mindset shift that accompanies this step. Treat paper trading as a syntax check and a logic test, not a proof that the strategy is safe or profitable. The real test begins when capital is at risk, and the only thing that makes that transition reasonable is the presence of hard, infrastructure-enforced limits that you have verified in advance.

How does plain dollar sizing remove one source of complexity?

Different venues use different contract sizes, tick values, and margin formulas. When an agent has to compute these internally, the risk of a decimal place error or unit mismatch increases. Felix normalizes this by accepting orders sized in plain US dollars and handling the venue-specific contract math internally. This removes one class of error, but it does not remove the risk of price gaps or liquidations. An agent can still be liquidated if it holds a leveraged position that moves against it, and a stop order does not guarantee execution at the desired price. Dollar sizing simplifies the interface; it does not simplify the market. It is a guardrail against configuration mistakes, not a strategy against adverse price movement. You should still set leverage limits at the key level and ensure the agent understands the notional exposure it is requesting, because a one thousand dollar order in a highly leveraged perpetual future can represent a very different risk profile than the same nominal amount in a stock. The agent may think in dollars, but the market thinks in contracts, and the translation layer is there to protect you from math errors, not from market forces.

How should you think about monitoring and audit logs?

Safety controls are only effective if you can verify they are working. Audit logs record every order attempt, rejection, and limit breach, whether the agent is trading through an MCP client or the REST API. Rejections are as important as fills, because a pattern of rejected orders may indicate a prompt that is drifting outside its intended scope. You should review logs regularly, not just for profit and loss, but for policy adherence. If an agent is repeatedly bumping against position limits, the strategy may be scaling too aggressively, or the prompt may be misinterpreting the market context. Logs are the feedback loop that lets you tighten controls before a small error becomes a large loss. Monitoring should also include the health of the MCP connection or API endpoint, because a silent disconnect can be as dangerous as a bad trade. Set up alerts for limit breaches and for any authorization change, so you know immediately when an agent transitions from paper to live or when a budget cap is raised. How to build a trading agent that handles real money safely includes a pre-flight checklist for reviewing these logs and settings before the first live order.