How to manage risk when you let an AI agent trade

Managing risk when you let an AI agent trade means placing hard, automated limits on what the agent can lose before it touches any capital. You keep full custody of the wallet, define scoped permissions and budget caps, and test every rule in paper mode before authorizing live keys. If the agent drifts outside its bounds, a kill switch flattens positions and revokes access automatically. These layers exist so that speed and automation do not turn a small error into a large, unrecoverable loss.

What does non-custodial risk management actually mean?

Non-custodial architecture changes the risk model from trust to verification. In a custodial setup, you send funds to a platform and hope its controls work and its employees are honest. With Felix, the funds stay in a wallet you control, whether that is a self-custodial crypto wallet or an account at a stock broker that you own directly. The agent receives a scoped key that can place orders and manage positions, but it cannot move money to an address you have not pre-approved. Even if the agent's logic is compromised, hallucinated, or manipulated by a clever prompt, the worst-case outcome is limited to the positions and budgets you explicitly allowed. The agent cannot pack its bags and leave with the deposit. The owner holds the only key that matters for withdrawals.

That structure shifts the focus from preventing every possible hack to containing the impact of any single failure. You are not trusting an AI with your seed phrase or your bank login. You are permitting it to trade inside a sandbox defined by dollars, markets, and time. The owner can inspect balances directly on chain or at a stock broker at any moment, independent of the agent's reporting or interpretation. This transparency is the first layer of risk management because it removes the possibility of hidden shortfalls, surprise withdrawals, or accounting errors that only surface after the damage is done. If the agent says it is flat but the wallet shows otherwise, you know immediately that something is wrong. You do not need to open a support ticket to verify your own money.

Which safety controls should you configure first?

Before the agent places its first order, define the boundaries that matter most to your capital. Start with a global budget cap that limits the total notional value the agent can deploy across all markets. This cap should reflect the maximum amount you are willing to lose in a worst-case scenario, not the amount you hope to invest. Then set per-market or per-strategy position limits so that no single trade, however confident the model sounds, can concentrate your entire allocation. These two numbers alone prevent the most common failure mode: an agent that scales into a losing position because it believes the edge is still present or because it is trying to recover earlier losses. A budget cap is not a target. It is a hard ceiling.

Next, scope the API key to the exact markets and actions the strategy requires. If the agent is meant to trade stocks and prediction markets, the key should not grant access to perps or options. This reduces the attack surface if the prompt is jailbroken or the model misinterprets intent. You should also configure a daily or weekly drawdown limit that pauses trading after a defined percentage of the budget is lost. Position sizing and spend caps are not optional extras; they are the primary load-bearing walls of the system. Without them, the agent is free to interpret your capital as a suggestion rather than a guarded resource.

Finally, set a kill switch or panic button that flattens all open positions and revokes the key instantly. This is not a sign of pessimism. It is a circuit breaker. The best time to decide when to stop is before the position exists, while you are still calm and the math is still theoretical. You should also think about correlation risk. If the agent can open multiple positions, ensure the limits prevent it from loading up on the same macro bet through different instruments or markets. Five separate trades that all lose together are effectively one large trade with extra steps.

How do exit plans prevent runaway losses?

An agent without exit rules is just a faster way to hope. Exit plans translate your risk tolerance into instructions that execute without hesitation, delay, or reinterpretation. A stop-loss order closes a position when the market moves against you by a defined amount. A take-profit order locks in gains at a predefined target. Time-based exits close trades that have not worked within the expected window, preventing capital from sitting idle in a stalled idea. Trailing stops can also be used to protect profits as a trend extends, though they require careful calibration so that normal volatility does not eject the agent prematurely. Together these rules form a contract between you and the agent that removes emotion from the closing decision.

These rules must be attached to the position at entry, not decided after the trade is underwater. Exit plans work because they remove the agent's discretion at the exact moment discretion becomes dangerous. When a position is losing, the model may generate a narrative about mean reversion, new information, or a temporary dislocation that justifies holding longer. The exit plan does not read the narrative. It reads the price and the clock. This is the difference between a managed loss and a runaway drawdown. The agent is allowed to be wrong, but it is not allowed to be wrong indefinitely.

Consider also whether your exit plan should scale out gradually or close entirely at once. Partial exits can reduce the sting of a stop being hit just before a reversal, but they also complicate the risk math because the remaining position still carries exposure. Whatever structure you choose, write it into the prompt and the API parameters so that the agent cannot override it with reasoning or creative interpretation. The goal is to make the exit as automatic and unchangeable as the entry. If the exit requires a second decision, it is not an exit plan. It is a new trade.

Why is dollar-based sizing both helpful and dangerous?

Felix sizes orders in plain US dollars rather than contract units or lot sizes. This abstraction helps agents reason about allocation intuitively. A directive to risk one hundred dollars means the same thing whether the venue is a stock broker, a perps venue, or an options platform. The API handles the conversion to shares, contracts, or notional exposure behind the scenes. This consistency reduces errors that come from venue-specific math, such as minimum lot sizes, tick values, or decimal precision. The agent thinks in terms of capital, which is how owners think.

But abstraction can hide leverage and nonlinear risk. One hundred dollars of margin on a perps venue might control five hundred dollars of notional exposure. One hundred dollars of premium in an options venue might represent a very different risk profile than one hundred dollars of stock, especially as expiration approaches or volatility shifts. Dollar-based order sizing can mislead an agent if the prompt does not account for the underlying instrument's sensitivity. You should tell the agent the maximum notional exposure it is allowed, not just the order ticket size, and you should verify that the venue's margin requirements fit inside the budget cap you set earlier. Options in particular can expire worthless, which means the entire premium is at risk even if the dollar amount seems small.

When writing prompts, separate the capital at risk from the position size. For example, instruct the agent to deploy no more than one hundred dollars of capital on a single trade while keeping total notional exposure under five hundred dollars. This distinction prevents the agent from interpreting a dollar limit as a license to take maximum leverage. Always cross-check the agent's intended size against the venue's margin and liquidation rules before the key is enabled. If the agent cannot explain the notional value of its intended trade, the prompt is not specific enough. You should also require the agent to state its intended leverage or contract multiplier before confirming any order, so that you have a final human checkpoint for sizing errors.

How do you test risk controls before going live?

Every control should fail in simulation before it is trusted with real money. Felix provides paper trading so that agents can place orders, hit limits, and trigger exits against live market data without touching capital. Use this mode to run the agent through scenarios that include bad fills, gap moves, repeated stop losses, and sharp rallies that might tempt the model to abandon its plan. Watch whether the budget cap actually halts new orders, whether the exit plan fires at the correct threshold, and whether the kill switch responds instantly. You should also simulate a scenario where the agent tries to trade a market outside its key scope to confirm that the API rejects the request cleanly.

Only after the agent has operated through a full cycle of wins, losses, and boundary hits should you authorize a live key. This authorization is a deliberate owner action, not a default setting. When you do move to live trading, start with a reduced budget cap that you scale upward only after the agent demonstrates consistent behavior over days or weeks. Paper trading proves the plumbing works. Live trading proves the agent behaves under pressure. They are separate tests, and skipping either one is a choice to discover problems with real capital instead of imaginary losses.

During live testing, monitor the agent more closely than you expect to in steady state. Check that position reports match the wallet or broker statement. Look for drift in strategy, such as the agent gradually increasing trade frequency or size as it gains confidence or tries to recover a small loss. The early days are when you catch the gap between intended design and actual behavior. Treat that gap as a bug and fix it before scaling. A agent that behaves for one day is lucky. An agent that behaves for two weeks is starting to earn trust. If the agent changes its own logic or prompt without your knowledge, that is a sign of a deeper issue that requires immediate investigation.

What should you do when something goes wrong?

Despite every precaution, markets move and models break. When they do, the correct response is mechanical, not strategic. Hit the kill switch. This flattens all open positions, cancels working orders, and revokes the agent's key in a single action. The goal is to stop the bleeding before you diagnose the wound. You can always review logs, adjust prompts, and redeploy later. The capital you preserve by stopping early is the capital you will need to test the fix. Hesitation in a crisis is usually more expensive than a false alarm.

After the agent is stopped, review what happened in this order. First, did the market move beyond the exit plan's ability to fill, or did the exit plan fail to trigger because of a parameter error? Second, did the agent ignore a limit because the prompt overrode it with reasoning, or because the limit was set incorrectly in the API? Third, did the loss exceed the budget cap because the cap was defined in ticket size rather than total exposure? Fix the control, rerun the scenario in paper trading, and only then restore live access. Each incident should leave the system stronger, not merely older.

Risk management is not a setup task. It is a loop of deployment, monitoring, interruption, and correction. The owner remains responsible for the capital even though the agent executes the trades. Accepting that responsibility means accepting that you will need to stop the agent, perhaps often, while you refine the rules. Over time, the controls become tighter and the interruptions become rarer, but the kill switch should always be within reach. The goal is not to build an agent that never fails. It is to build a system that fails small and fails safely. Every interruption is data, and every fix is a deposit in the account of future stability.