How to let an AI trading agent spend real money without giving up custody

Taking an AI trading agent live with real money means the agent can place orders that lose capital faster than a human can react. Non-custodial infrastructure prevents this from becoming a total loss by keeping funds in a wallet you control, while the agent operates through scoped keys that cannot withdraw or move money to unapproved addresses. You remain the final authority over every dollar, and you can revoke access or flatten positions instantly if the agent behaves unexpectedly.

What does it mean to trade with an agent without giving up custody?

In a custodial setup, you send funds to a platform and trust that platform to honor your API instructions. If the platform freezes withdrawals, misreports balances, or the API key leaks, your capital is exposed. Non-custodial agent trading flips this model. Your funds stay in a wallet that you control through standard cryptographic keys. The agent receives a scoped API key that authorizes it to place orders, cancel orders, and read balances, but it cannot withdraw funds or add new withdrawal addresses. Those addresses must be pre-approved by you alone, and the agent cannot change them.

This separation of duties matters because the agent is software that interprets natural language or code logic, and software can fail in ways that are hard to predict. A custody layer that requires your explicit approval for any outbound movement ensures that even a compromised or hallucinating agent can only trade within the boundaries you set. The agent can lose money on bad trades, which is a real risk you must accept, but it cannot steal the remaining balance or move it to an unknown destination. You hold the keys, and the agent holds only a narrow permission to trade. control risks without giving up custody

What are the main risks when an AI trading agent starts using real money?

The first risk is model error. A large language model can misinterpret a prompt, hallucinate a ticker symbol, or generate a trade size that exceeds your intent. Suppose you instruct an agent to maintain a five percent position in a stock and the model rounds incorrectly or omits a zero. The resulting order could be ten times larger than planned, and because the agent acts autonomously, it may submit the order before you notice.

The second risk is logic fragility. The code that parses model output into API calls may assume a market is open, assume a ticker exists on a given venue, or assume that margin requirements are static. Any of these assumptions can fail when a market halts, a symbol changes, or a perps venue adjusts leverage limits. The API normalizes some of this math, but the agent still needs to handle edge cases that paper trading may not reveal. A symbol that resolved cleanly yesterday may point to a delisted instrument today.

The third risk is market structure. Live markets have slippage, partial fills, and liquidity gaps. An agent that backtests on idealized data may send orders that move the market against it, or it may place stop orders that execute far from the intended price during a volatility spike. Trading can lose money, including everything, and autonomous agents do not pause to reconsider when conditions change. They follow instructions literally, and the market does not care about their intent.

Finally, there is operational risk. Network latency, venue downtime, or a stale API key can leave an agent blind while markets move. If the agent is supposed to hedge a position and the connection drops, you may be exposed longer than expected. These risks do not disappear with better code; they require hard limits that constrain the agent even when connectivity or logic fails. You cannot eliminate failure, but you can limit its cost.

How do scoped keys and budget caps keep an agent inside its lane?

Felix uses one API and one key to reach stocks, crypto, perps, options, and prediction markets, but that key does not grant unlimited power. You scope the key to specific markets, order types, and maximum sizes before the agent ever connects. For example, you might allow the agent to trade stocks and perps but not options, or you might cap any single order at one thousand dollars and any total position at five thousand dollars. These constraints are enforced at the API level, not inside the agent, so a misbehaving model cannot talk its way around them. The limits are part of the infrastructure, not part of the prompt.

Budget caps work the same way. You set a maximum notional exposure or daily loss limit in plain US dollars. The API normalizes venue-specific contract math, so a perps position and a stock position are both counted in the same currency unit. If the agent tries to submit an order that would breach the cap, the API rejects it. The agent can read the error and adjust, but it cannot override the limit. This normalization removes the need for you to manually convert contract sizes, leverage factors, or tick values across different venues.

The exact request schema is in the docs; the shape looks like this:

{
  "auth": "YOUR_KEY",
  "constraints": {
    "markets": ["stocks", "perps"],
    "max_order_usd": 1000,
    "max_position_usd": 5000,
    "allow_withdrawal": false
  }
}

This pattern means that even if the agent is compromised or hallucinates a strategy, it can only lose what you have already decided you can afford to lose. You can tighten these limits over time as you gain confidence, or you can relax them if the strategy proves stable. The key point is that the boundary lives outside the agent. It does not depend on the model being honest or correct. trade every market through one API with hard limits

Why does every live agent need a panic switch?

A panic switch, or kill switch, is the final layer of defense. It does two things immediately: it flattens open positions and it revokes the agent's key. Once revoked, the key is useless. The agent cannot read balances, place orders, or even check if the market is open. It becomes a spectator with no credentials. The revocation is permanent, and creating a new key requires your explicit authorization.

You should think of the panic switch as a circuit breaker for autonomy. If the agent enters a loop of losing trades, if a market crashes beyond your risk tolerance, or if you simply lose confidence in the model's reasoning, you trigger the switch and the agent stops. The flattening is not guaranteed to execute at a profit, and in fast markets you may close at a worse price than you hoped. Trading can lose money, including everything, and the panic switch is about stopping further damage rather than locking in gains. It is a safety mechanism, not a profit tool.

Some traders automate the panic switch by linking it to a drawdown threshold. If the portfolio drops by a preset percentage, the system revokes the key and sends a notification. This removes the need for you to watch every tick. Whether manual or automated, test the switch in paper mode before going live. You need to know that it works when you are not paying attention.

What should you verify before moving from paper trading to live trading?

Paper trading exists for testing. It lets you validate the agent's logic, confirm that it parses symbols correctly, and check that your scoped keys and budget caps behave as expected. Live trading requires explicit owner authorization of a key. Before you grant that authorization, walk through a checklist that covers logic, symbols, safety, and market reality.

1. 01Verify that the agent's sizing logic is deterministic. If you give the same prompt twice, does it produce the same order size? Non-deterministic output is a warning sign that the model is improvising rather than following rules.
2. 02Confirm that the symbols it uses map to the instruments you intend. A generic name might resolve to a different contract on a perps venue than it does on a stock broker. Symbol mapping should be explicit, not left to the model's interpretation.
3. 03Test the panic switch during paper trading. Trigger it mid-strategy and confirm that the agent stops and that positions are flattened according to your exit plan. If the switch fails in paper mode, it will fail in live mode.
4. 04Review the difference between paper fills and live execution. Paper trading assumes ideal liquidity. Live markets have slippage, especially for larger orders relative to available volume. An agent that looks profitable on paper may lose money live simply because it pays the spread on every entry and exit.
5. 05Start with a reduced budget cap for the first live session. Treat the initial live period as a second round of testing, not as a launch. The goal is to confirm that the boundaries you set actually contain the agent when real money is at stake.

You should also monitor the agent closely during its first live trades. Watch for unexpected orders, delays, or error loops. The transition from paper to live is a process of gradually increasing exposure while confirming that each protection layer works under real conditions.

How does an exit plan protect you once the agent is running?

An exit plan is a set of predefined rules that close positions automatically when certain conditions are met. These include stop losses, take profits, and time-based exits. The plan should be configured at the API level rather than buried in a prompt, because prompts can be forgotten or misinterpreted by the model. When the API enforces the exit, the agent cannot argue or delay. The order to close is infrastructure, not suggestion.

Stop losses are particularly important for autonomous agents because the model does not feel fear. It may continue to hold a losing position based on a narrative it generated, long after a human would have cut the trade. A hard stop loss at the API level closes the position regardless of what the agent believes. Similarly, a take profit locks in gains before the agent decides to get greedy and reverse the position.

If you run agents across multiple markets, correlations can amplify your risk. A move in macro conditions might hit your stock position and your perps position at the same time. An exit plan that considers total portfolio heat, not just individual trades, prevents a synchronized drawdown from wiping out your budget cap. build an exit plan that automates take profits and stop losses

You should also review the plan regularly. Market volatility changes, and a stop that made sense last month may be too wide today. The agent does not know when to update its own safety rails; that is your job as the owner. Review, adjust, and test again. keep a multi-market portfolio safe