How a Claude trading agent trades without taking custody of your funds

A Claude trading agent connected to Felix can place orders across stocks, crypto, perps, options, and prediction markets without ever taking custody of your funds. The agent operates through scoped API keys that can spend within owner-defined limits but cannot withdraw funds or change withdrawal addresses. Your capital remains in a wallet you control, and the system rejects any request that falls outside the safety boundaries you set before the agent starts. This architecture separates trading permission from asset ownership, so the agent can execute strategy while you retain final control over the capital.

What does non-custodial agent trading actually mean?

In most automated trading setups, you give your capital to a platform or a bot operator. The operator holds your funds in their accounts, pools them with other users, and promises to trade on your behalf. This is custodial. If the operator fails, freezes withdrawals, or suffers a breach, your capital is at risk. You are dependent on their solvency and their security practices.

Felix takes a different approach. The funds sit in a wallet that you control through standard cryptographic keys. The trading agent, whether it is Claude, Cursor, or another MCP client, receives an API key that can instruct the system to place orders, but it cannot move assets to an external address. Withdrawal addresses are owner-approved only, and the agent lacks permissions to add new ones. This means the worst-case scenario is not a total loss of funds to an external thief, but rather poor trading performance within the budget you allocated. Non-custodial trading for AI agents explains the full architecture, but the essential point is that the agent is an operator, not a custodian.

The agent sees markets and sends instructions. The Felix layer validates those instructions against your policy, translates them into venue-specific formats, and submits them. The agent never holds the private keys to your wallet, and the API key it holds is incapable of initiating a withdrawal. This separation is enforced by the infrastructure, not merely by a promise or a terms of service clause. Even if the agent is compromised, the attacker cannot extract funds. They can only place trades within the existing limits, which you can revoke at any time.

How do scoped keys create a hard boundary for the agent?

An API key in Felix is not a master password. It is a scoped credential created with specific constraints attached to it. When you provision a key for your Claude agent, you define a budget cap, a list of allowed markets, maximum position sizes, and whether the key may use leverage. These constraints are stored in the policy layer and checked on every request. The key is generated for a specific purpose, and it carries that purpose in its permissions.

You can also set time-based limits, such as daily or weekly budgets, and market-specific restrictions, such as allowing stocks and crypto but prohibiting options or leveraged perps. This means you can give an agent a narrow mandate and expand it only after you see consistent behavior. The key scope acts like a sandbox around the agent.

This is different from giving an agent a login to a brokerage account. A brokerage login often grants broad permissions, and you rely on the agent to behave correctly. Scoped keys flip the model. The agent can only do what the key allows, and the key cannot do what you forbid. The enforcement happens at the API gateway, not inside the agent's reasoning loop. Claude may reason about a trade, but the trade only executes if the key's scope permits it. The agent's reasoning is advisory; the key's policy is authoritative.

Suppose you set a $10,000 budget cap and the agent has already deployed $9,800. A new $500 order is rejected. The agent does not get to override this. The rejection is a hard stop from the infrastructure. Scoped API keys for trading agents covers the configuration options, but the core idea is that the boundary is cryptographic and policy-based, not social. The agent cannot talk its way out of the limit.

You can also rotate or revoke a key without moving funds. If you suspect the agent is behaving erratically, you delete the key. The underlying wallet is untouched. This means the lifecycle of the agent's access is completely separate from the lifecycle of your capital. You can decommission an agent without decommissioning your portfolio.

What happens when an order breaks the safety rules?

Every order the agent submits passes through a validation layer before it reaches any market venue. This layer checks the order against the scoped key's budget, position limits, allowed instruments, and any other constraints you configured. If the order violates any rule, the API returns an error and the order dies at the gateway. The market never sees it. No position is opened, no margin is consumed, and no fee is paid.

This validation is not a suggestion. It is a structural rejection. The agent cannot catch the error and retry with a different parameter to bypass the limit, because the limit is tied to the key, not the request payload. The agent would need a different key to act outside the scope, and you are the only party that can create one. The policy is enforced by the infrastructure that sits between the agent and the market.

This design matters because AI agents can make mistakes. They can hallucinate a ticker symbol, misinterpret a unit, or loop into a repeated action. Without a hard boundary, an agent could burn through a deposit in minutes. With the Felix safety model, the agent's mistakes are contained. It might generate losing trades within its budget, but it cannot exceed the budget or access markets you excluded. Trading can still lose money, including the entire amount you allocated to the agent, but the loss is bounded by the cap you set in advance. The system does not prevent losses; it prevents unbounded losses.

How does the panic switch recover control?

Even with scoped keys and budget caps, you may want an emergency brake. Felix includes a panic switch that flattens open positions and revokes the agent's key immediately. When you trigger it, the system submits closing orders for any open positions and disables the API key before the agent can place another trade. The action is atomic. The key is dead while the positions are being closed.

The flattening is not guaranteed to execute at a profit. Markets move, and closing a position quickly may result in losses, especially in leveraged products or thin markets. The panic switch prioritizes cutting exposure over price optimization. It is a safety tool, not a profit protection tool. You may exit at a worse price than you hoped, but you will exit.

After the switch is thrown, the agent has no access. You keep full custody of whatever funds remain in the wallet. You can then inspect the trading history, adjust the strategy, and issue a new scoped key if you want to resume. The important point is that you never lost control of the wallet itself. You only lost the agent's permission to trade, which you can restore or withhold as you see fit.

This mechanism is useful not only for malicious behavior but also for simple bugs. If Claude enters a loop and starts overtrading, the kill switch stops the bleeding. You do not need to contact support or wait for business hours. The control is immediate and unconditional. You can revoke access faster than any agent can exploit it.

Why does paper trading come before live authorization?

Before an agent touches real capital, Felix requires a deliberate transition from simulation to production. You start in paper trading mode, where the agent connects to live market data but its orders are simulated. The agent experiences fills, slippage, and portfolio changes, but no actual money moves. This lets you observe how Claude behaves under real market conditions without risking the wallet balance.

Paper trading reveals issues that are hard to predict in theory. The agent might misinterpret a signal, size a position incorrectly relative to your intent, or struggle with multi-market correlations. Watching the simulation for days or weeks gives you confidence that the strategy is coherent. It also lets you verify that the scoped key limits are configured correctly.

Moving to live trading requires explicit owner authorization. You must generate a live key and approve it for real money. This is not a default setting that you might forget to disable. It is an opt-in step. The explicit authorization step also creates a natural pause. You must review the key settings, confirm the budget, and acknowledge that trading can lose money. This friction is intentional. It prevents accidental live deployment during a quick experiment. Once authorized, the key remains live until you revoke it, but the initial activation is a deliberate act. How to set spend caps and drawdown limits for trading agents describes the parameters you should tune during this transition. The caps you set in paper mode carry over, so the safety boundary is already tested when you go live.

How does plain dollar sizing prevent unit confusion?

One subtle risk in multi-market trading is unit math. A crypto perps venue might use contracts, an options venue might use lots and multipliers, and a stock broker might use fractional shares. If the agent reasons in native units, it can easily create orders that are ten times too large or ten times too small.

Felix normalizes this by accepting orders sized in plain US dollars. You or the agent specify the desired exposure in dollars, and the API converts that into the correct number of contracts, lots, or shares for the specific venue. The agent does not need to know the contract size of a crude oil future or the lot size of an options contract on a tech stock.

This normalization reduces a major class of agent errors. It also makes cross-market portfolio management simpler. The agent can think in terms of dollar allocation, rebalancing, and risk budgets, while the infrastructure handles the mechanical translation. How an AI agent executes orders while you keep full custody walks through the execution path, but the relevant detail here is that the agent reasons in a common language and the system handles the dialects.

The result is that a Claude agent can manage a multi-market portfolio without mastering the idiosyncrasies of each venue. The safety model extends beyond permission boundaries to the actual shape of the orders, ensuring that a misunderstanding of units does not become a misunderstanding of risk.