How an AI agent executes orders while you keep full custody

An AI agent can discover opportunities, size positions, and route orders across stocks, crypto, perpetuals, options, and prediction markets without ever taking custody of your assets. You retain the private key to the wallet that holds your funds. The agent receives scoped API credentials that let it spend within limits you define, but it cannot withdraw to itself or override your controls. If you revoke the key, the agent loses access immediately, while your capital remains untouched.

This article walks through the full execution path, from the moment the agent decides to trade to the moment the position settles in your account. If you are new to the model, what is agentic trading? gives a high-level overview.

What does non-custodial execution actually mean?

In a custodial setup, you deposit funds with a third party and grant that party full discretion. Here, the opposite is true. Your funds remain in a wallet that only you control. The agent connects through an API that normalizes interactions with a stock broker, a crypto exchange, a perps venue, an options venue, or a prediction market. The agent never sees your private key, your seed phrase, or your login credentials. Instead, it receives a scoped key that can only place orders within constraints you configure. Withdrawal addresses are owner-approved only. Even if the agent code is compromised, the attacker cannot move funds to an unauthorized address. This design is non-custodial by construction, not by policy. The API acts as a translation and control layer, not as a custodian. Execution and custody are separate concerns. The agent handles execution, while you retain custody. Because the agent never holds the funds, you do not need to trust its code with your wealth. You only trust it to make decisions within the boundaries you set. If the boundaries are too loose, the risk is yours, but the funds themselves are not exposed to the agent's infrastructure.

How does the agent prepare an order before it reaches the market?

Before any network request leaves the agent, it runs its strategy logic. It may process price feeds, volatility signals, or portfolio drift calculations. Once it decides to trade, it constructs an order in a simple format. On Felix, orders are sized in plain US dollars. The agent does not need to compute contract multipliers, margin ratios, lot sizes, or token decimals. It sends a notional dollar amount. The API handles the translation into venue-specific units. Suppose the agent wants to buy five hundred dollars of an asset. It sends five hundred, and the API translates that into the correct number of shares, contracts, or tokens based on current prices and venue rules. This removes a common source of error and makes the agent logic easier to audit. The simplicity of dollar sizing also makes backtesting and paper trading more consistent. You can reason about risk in familiar terms rather than in contracts or lots.

The agent also checks its guardrails before submitting. Budget caps, position limits, and allowed markets are enforced. These checks happen both in the agent's own logic and in the API layer. If the agent tries to exceed a cap, the API rejects the order. The agent can then log the rejection and adjust its plan. You can read more about configuring these in how to run an AI trading agent with real money, safely.

What happens when the agent submits an order?

The agent sends a request through the REST API or via MCP tools from Claude, Cursor, or another MCP client. The request includes the market identifier, side, notional dollar size, and order type. The exact request schema is in the docs; the shape looks like this.

# The exact endpoint is in the docs
curl -X POST ... \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "market": "example-market-id",
    "side": "buy",
    "notional": "500.00",
    "type": "limit"
  }'

The API receives the request and validates the scoped key. It checks that the key is authorized for this market, that the notional size fits within the remaining budget cap, and that the position limit would not be exceeded. It also checks rate limits and order type permissions. If any check fails, the API rejects the order before it reaches the venue and returns a clear error. The agent can log this and decide whether to retry or halt. This validation layer protects you from bugs in the agent logic. The API also logs every request for audit, so you can review exactly what the agent attempted and why an order was allowed or denied.

If all checks pass, the API translates the dollar size into venue-specific units, constructs the appropriate transaction or order message, and routes it to the market. The agent does not handle venue-specific authentication, session management, or contract math. It simply asks to trade a dollar amount, and the execution layer handles the rest. When the venue accepts the order, the API returns a confirmation with a tracking identifier. The agent can use this to poll for fills or updates. The key point is that the agent initiated the action, but the API controlled whether it was allowed, how it was sized, and where it went. The agent has execution intent, but the API has execution authority.

How does settlement work if the agent never holds the funds?

When a trade fills, the resulting asset or cash stays in your wallet or your account. If the trade is on a decentralized venue, settlement occurs on-chain to your address. If the trade is through a broker or centralized venue, the API manages the venue connection, but the account is registered to your identity and your wallet. The agent never takes delivery of the asset. It can request a new trade, but it cannot transfer the proceeds to itself. Withdrawal addresses are owner-approved only. You must explicitly whitelist where funds can go, and the agent cannot modify that whitelist. For decentralized settlement, this means your wallet signs or approves the transaction, or a pre-approved execution module acts within strict limits. In either case, the final beneficiary is your address.

This means the agent can trade, rebalance, or flatten positions, but it cannot exit with the money. Suppose the agent builds a position over several days. If you decide to stop, you can revoke the API key. The positions remain in your account. You can then close them manually or through another authorized agent. The agent had execution power, not ownership power. This distinction is what keeps the funds under your control even while an automated system is actively managing them. Rebalancing, for instance, is simply a set of sell and buy orders. The cash and assets never leave your account.

What safety checks run during execution?

Safety is layered and enforced at multiple points.

• ·The first layer is the scoped API key. The key is limited to specific markets, order types, and maximum notional amounts. A key authorized for prediction markets might not be authorized for options.
• ·The second layer is budget caps. You set a total spending limit for the key. Once reached, the key cannot place new orders, even if the strategy logic requests them.
• ·The third layer is position limits. The API tracks exposure across venues and rejects orders that would exceed your preset threshold. This prevents concentration risk.
• ·The fourth layer is the exit plan. You can define conditions under which the agent must flatten and stop, such as a drawdown limit or a time-based halt.
• ·The fifth layer is the panic or kill switch. At any time, you can flatten all positions and revoke the key. This is immediate. The agent does not get a grace period.

You can learn more about designing these controls in how to build guardrails for a trading agent. Trading can lose money, including everything, and these layers exist to contain risk, not to eliminate it. No guardrail can guarantee profitability or prevent all losses.

How do you test this flow without risking capital?

Before live trading, you run the agent in paper trading mode. Paper trading uses the same API, the same order sizing logic, and the same safety checks, but it simulates execution against market data without real money. You can test signal logic, guardrail behavior, error handling, and retry policies. You can see exactly what orders would be generated and whether they would pass or fail the budget and position checks. It is a safe environment to discover bugs in sizing or market selection.

When you are ready to trade live, you create a new scoped key and explicitly authorize it for live trading. The authorization step requires your explicit approval. There is no automatic graduation from paper to live. You control when the agent touches real capital. If you are building your first system, your first automated multi-market portfolio provides a broader setup guide. Remember that live trading can result in losses, including the loss of your entire budget. Paper results are hypothetical and do not guarantee future performance. Market conditions, liquidity, and slippage can differ between simulation and reality.

Common questions about non-custodial execution