How AI agents trade across markets without taking custody of your funds

AI agents can trade across stocks, crypto, perpetual futures, options, and prediction markets without ever holding or withdrawing your funds. The agent receives a scoped key that authorizes only trades within limits you define, while your assets remain in a wallet or account that only you control. This arrangement separates execution authority from custody, so the agent can size positions in plain US dollars and send orders through a single API, but it cannot move money to an external address or exceed the boundaries you set.

What does non-custodial mean for an AI agent?

Non-custodial trading means the owner retains the private keys and withdrawal rights at all times. In a traditional setup, a bot or automated service might require API keys that permit withdrawals, or the user might deposit funds into a platform wallet the service controls. With an agentic infrastructure built for non-custodial access, the agent operates under a key that is scoped to trading actions only. The owner defines the maximum spend, the allowed instruments, and the maximum position size. The agent can place orders, manage exposure, and flatten positions, but it cannot initiate a withdrawal or change the approved withdrawal address. This is enforced by the key architecture and policy layer, not merely by a promise in the terms of service.

The distinction matters because AI agents reason in natural language and can interpret instructions in ways that are hard to predict. A non-custodial design means that even if the LLM generates an unexpected sequence of trades, the financial damage is bounded by the policy. The worst case is that the agent loses the budget allocated to it, not the entire balance of the wallet. This is a structural difference from custodial automation, where a breach or a bug can drain the entire account. The owner can revoke the key at any time without a waiting period, and the agent has no ability to lock funds or create withdrawal delays. Non-custodial trading for AI agents explains the underlying mechanism in more detail.

How does a single API work across five market types?

A unified API abstracts the contract math, lot sizes, tick sizes, and margin requirements of each venue. The agent sends an order in a common format, specifying the market, direction, and size in US dollars. The infrastructure translates that dollar amount into the correct number of shares, contracts, tokens, or units for the specific venue, then routes the order. The agent does not need to maintain separate integrations for a stock broker, a perps venue, an options venue, a crypto exchange, and a prediction market. It uses one key and one schema.

This normalization reduces complexity for the LLM. The model can reason about risk in dollars, not in basis points, tick sizes, notional calculations, or leverage multipliers. It does not need to know whether a stock supports fractional shares, whether a perp uses inverse or linear contracts, or how an options venue handles contract multipliers. The API handles the translation. A single API also means a single audit stream. Every action the agent takes is logged in one place with the same identity and key context, which simplifies monitoring and debugging. The agent can rebalance across asset classes without the owner managing fragmented API keys or fragmented risk controls. The owner sets one budget in dollars, and the system enforces it across every venue.

Prediction markets present a different structure than traditional financial instruments. They often use binary contracts with expiration dates and settlement conditions. The API still presents these as dollar-sized orders, so the agent can express a view in dollars without writing custom logic for event resolution, liquidity pools, or order book depth. The infrastructure handles the mapping.

Why are scoped keys and budget caps essential?

An agent that reasons in natural language can interpret instructions creatively, which is useful for strategy but dangerous for execution. Hard limits are the guardrails that prevent interpretation from becoming overspending. A scoped key carries a policy that enforces these limits at the infrastructure level, before the order reaches the market.

The owner should set a spend cap that reflects the maximum loss they are willing to accept in the agent's budget. A drawdown limit can force the agent to stop trading if the account value falls by a specified percentage. Position limits prevent the agent from concentrating too much capital in a single instrument. For leveraged products such as perpetual futures or options, the API enforces the notional limit in US dollars even if the venue offers high leverage. This prevents the agent from accidentally taking a position that is larger than intended because it misunderstood margin requirements. These controls are not suggestions. They are enforced by the key and cannot be overridden by the agent. How to set spend caps and drawdown limits for trading agents covers the practical configuration.

The agent can still operate within its lane. It can open and close positions, adjust size, and follow exit plans. But if it tries to exceed the cap, trade a disallowed instrument, or violate the drawdown rule, the API rejects the order. This is a safety mechanism that works even if the LLM is hallucinating, if the strategy code contains a bug, or if market volatility causes rapid losses. The policy is the floor, not the agent.

What happens when an agent hits a limit or you trigger a kill switch?

When the agent reaches a budget cap, the API returns a rejection. The agent cannot proceed with new orders until the owner adjusts the limit or the agent closes existing positions to free up budget. The owner remains in control of whether to raise the cap, pause the agent, or revoke the key entirely. The agent cannot appeal the limit or find a workaround.

A kill switch is a more forceful intervention. When activated, it flattens open positions and revokes the agent's access immediately. The agent does not negotiate or delay. Positions are reduced according to the pre-configured exit plan, and the key is disabled. This is useful when market conditions change suddenly, when the agent's behavior diverges from expectations, or when the owner simply wants to stop trading. The exit plan is itself a pre-approved set of instructions that the agent can execute without additional prompts, but it is bounded by the same policy that governs normal trading. How kill switches work from first principles for trading agents describes the design and timing considerations.

After a kill switch or cap breach, the funds remain in the owner's wallet. The agent cannot lock the assets or move them elsewhere. The owner can withdraw, redeploy, or restart the agent with a new key and revised limits. The interruption is immediate and complete.

How do you start without risking the full account?

Paper trading is the standard first step. The agent runs against live market data but executes simulated orders. The owner can observe how the LLM interprets prompts, how the system handles order sizing, and how the agent reacts to volatility. No capital is at risk during this phase. It is a useful way to catch logical errors, prompt ambiguities, and unexpected behavior before real money is involved.

When moving to live trading, the owner must explicitly authorize a live key. The authorization step is a deliberate barrier that prevents accidental deployment. The owner should allocate a small budget that reflects the maximum loss they are willing to accept during validation. The key is scoped to that budget only. The agent trades real money, but the maximum loss is bounded by the allocation. This is a safer way to validate behavior than deploying the full account at once.

After the agent demonstrates consistent behavior within the small budget, the owner can increase the cap in discrete steps. Each increase is a new authorization. The owner can also run multiple agents with separate keys and separate budgets, comparing strategies without letting one agent's losses affect another. This multi-agent architecture is only practical because the keys are scoped and isolated. The owner is never required to pool all funds under a single agent or a single policy.

It is important to remember that trading can lose money, including the entire allocated budget. Paper trading success does not guarantee live performance. Slippage, latency, and market impact are real. The owner should only allocate capital they are prepared to lose. Starting small and scaling limits gradually is a more sustainable approach than deploying a large budget on day one. How a single API changes safety for trading agents versus bots compares this model to older automation approaches.

What does the setup look like for developers?

Developers connect agents through MCP tools or the REST API. The exact request schema is in the docs; the shape looks like this:

curl -X POST https://api.felix.trade/v1/order \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{\n    "market": "perp",\n    "symbol": "BTC",\n    "side": "buy",\n    "size_usd": 500\n  }'

The response includes the order status, the remaining budget for the scoped key, and any limit violations. The agent can poll or subscribe to updates to track its positions and PnL. The key in the header is tied to the policy, so the server enforces caps before accepting the order. Every request is logged for audit, and the owner can trace every order back to the specific key and policy version that authorized it.

For MCP clients such as Claude or Cursor, the agent uses the provided tool definitions to build requests. The client does not store the key; it delegates the call to the infrastructure. This keeps the key out of the LLM context window and reduces the risk of accidental exposure. The agent focuses on strategy and prompts, while the infrastructure handles execution, translation, and enforcement.