How to give an AI agent a trading account

If you want an AI agent to trade, the first question is not which model to use. It is what account the agent trades from. A general-purpose brokerage credential can grant far more authority than an agent needs. Use an isolated account and the minimum owner-authorized trading scope, with exact caps, expiry, and a separate withdrawal path.

This guide shows the full flow with Felix, a trading API built for agents. The same principles apply to any setup you build yourself: one account model, normalized symbology, owner-controlled funds, and explicit limits.

Step 1: Create an isolated child account

An existing parent account with the manage scope can provision an isolated child account and a read-only onboarding bootstrap with one authenticated call. The child cannot read the parent or sibling accounts, and the raw bootstrap is returned only once.

curl -X POST https://api.felix.trade/v1/accounts \
  -H "Authorization: Bearer $FELIX_MANAGE_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{"accept_terms":true,"label":"research agent"}'

# First response only: { "account_id":"...", "key_id":"...",
#   "bootstrap_key":"fk_...","mode":"onboarding" }

The first response hands back a read-only bootstrap once. An exact idempotent replay returns metadata without repeating the secret. The client completes wallet onboarding and mints an owner-signed live key. Execution stays unavailable until that separate owner authorization is complete.

Step 2: One interface, normalized instruments

The reason a single account works is a single symbology. The agent does not learn one integration for stocks and another for crypto and a third for options. It uses one format for everything, and sizes every trade in plain US dollars, with no contract math.

# read-only starting workflow
GET /v1/status
GET /v1/quotes/BTC
GET /v1/research/BTC?interval=1h&bars=500
POST /v1/backtests {"strategy":"momentum","instrument":"BTC"}

Those starting requests do not move money. Owner-authorized execution requires a unique idempotency key, and prediction-market orders use a separate prepare, local-sign, checkpoint, relay, and commit flow. We go deeper on the unified model in One API for every market.

Step 3: Fund it without giving up custody

This is an important authority boundary. In a custodial setup, you transfer control to a third party. The non-custodial pattern keeps owner custody separate from narrower agent permissions. A trade-scoped key can spend an authorized balance on real trades but is not the withdrawal path; owner-key, contract, integration, venue, software, operational, and market risks remain.

With Felix you send USDC to the deposit address and it becomes spendable trading cash. Withdrawals are a separate, guarded path: they require transfer scope, an owner-signed destination authorization, and a local signature over the exact transaction. A trade-scoped agent key is not the withdrawal path. Full detail in Non-custodial trading for AI agents.

Step 4: Scope the key and cap the downside

A key is not all-or-nothing. Grant only what the agent needs:

• ·read: market data and account state.
• ·trade: place and cancel orders.
• ·manage: create accounts and handle funding.
• ·transfer: withdrawals, off by default and rarely given to an agent.

On top of scopes, set owner-signed order, daily-notional, daily-loss, and expiry limits. These are enforced outside the agent's prompt. The deployed control reports its exact blocking and position-handling behavior.

Step 5: Preview, then understand the emergency stop

Before a large trade, the agent can preview it: the API returns the estimated fill price and fee before anything is committed. The emergency stop cancels managed activity where possible and revokes the calling key. It does not automatically close positions or revoke existing token allowances, which remain separate owner actions.

POST /v1/orders/preview {"instrument":"BTC","side":"buy","size_usd":50}
# -> { "est_fill_price":61825.5, "fee":{"fee_usd":0.04,"bps":8} }

POST /v1/panic   # cancels managed activity where possible and revokes the calling key

That is the model: an authorized parent provisions an isolated agent account, the owner authorizes bounded real-money access, and the agent submits actions through one API while owner and agent authority remain separate. After the respective public gates open, supported MCP clients or custom code can use that account. See MCP and direct API integration paths.