How to let an AI agent place orders without taking custody of your funds

You can let an AI agent execute trades across stocks, crypto, perpetual futures, options, and prediction markets without ever transferring custody of your funds. The agent receives scoped permissions to place orders within dollar limits you define, but it cannot withdraw funds, change ownership, or exceed your budget. This is done through a single API and a wallet you control, with the agent connecting via MCP tools or the REST API. The model is designed so that the agent acts as an operator, not an owner.

What does non-custodial agent trading actually mean?

Non-custodial trading means your funds remain in a wallet or account that you control. The agent does not hold your private keys, receive deposits, or gain ownership of your capital. Instead, it receives a scoped API key that can only perform actions you allow, such as placing orders or reading positions. If the agent is compromised, the attacker cannot withdraw funds because the key lacks withdrawal permissions and the destination addresses are owner-approved only. This architecture is non-custodial by construction, not by policy. The platform never pools your funds, and the agent never takes possession. Even when trading through a stock broker, a perps venue, or a prediction market, the underlying ownership chain remains with you. The distinction matters because many trading setups require you to deposit funds into an intermediary account. In those models, you are exposed to the intermediary's solvency, security, and operational risk. Here, the funds stay in your wallet. The API key is merely a spend authorization that is limited in scope, duration, and amount. You can audit the permissions at any time, and you can revoke them instantly. The agent cannot move funds to an unknown address, cannot change the withdrawal whitelist, and cannot open new accounts in your name. This applies equally whether you are trading equities through a stock broker, leveraged contracts through a perps venue, event contracts through a prediction market, or derivatives through an options venue. The custody model is uniform across all five market types. How non-custodial trading keeps your money safe when an AI agent trades.

How do scoped API keys let an agent trade without taking your funds?

A scoped API key is a credential with restricted permissions. When you create a key for your agent, you decide exactly what it can do. Typically, this includes placing orders, canceling open orders, and reading account balances or positions. It explicitly excludes withdrawals, address changes, and key management. The key is bound to a budget cap, so even if the agent sends a large order, the system rejects it if the total exposure exceeds your limit. Because the funds stay in your wallet, revoking the key instantly cuts off all access. The agent cannot trade, cannot see your data, and cannot touch your capital. This is fundamentally different from granting an agent direct blockchain access or exchange login credentials. In a traditional setup, an API key might grant broad access, including transfers, account settings, or withdrawals. A scoped key is different. It is created with a narrow purpose, and the infrastructure enforces those boundaries at the network level. The key might be valid for only one market type, or it might be valid for all five, but it will still be limited to order execution and data reading. The budget cap is attached to the key itself, not to the agent's logic. This means a bug in the agent's reasoning cannot bypass the cap. If the agent repeatedly tries to place orders after reaching the limit, the system continues to reject them. You can also set time-based limits, such as daily or weekly budgets, which further constrain the agent's ability to accumulate risk. If you need to pause the agent, you delete or disable the key. The agent has no alternative path to your funds because the wallet architecture requires owner approval for any outbound movement. How scoped API keys let an agent trade without taking custody of your funds.

What controls should you set before the first order?

Before the agent places its first order, you should configure several hard limits. These controls exist at the infrastructure level, not inside the agent's prompt or code, so they execute even if the agent behaves unexpectedly.

1. 01Set a total budget cap that defines the maximum notional value the agent can deploy across all positions.
2. 02Set per-market position limits so the agent cannot concentrate everything in a single instrument.
3. 03Define a drawdown limit that triggers automatic flattening if losses exceed your threshold.
4. 04Configure an exit plan that specifies how the agent should close positions, either through take profit levels, time-based exits, or manual override.
5. 05Confirm the panic switch is active. This kill switch flattens all positions and revokes the API key in one action.

The budget cap should reflect money you are prepared to lose, because trading can lose money, including everything. The drawdown limit should be set at a level where you want the system to intervene before the agent can dig a deeper hole. Position limits prevent concentration risk. Even if the agent has high confidence in a single trade, the infrastructure will block it from allocating more than your preset maximum to any one position. The exit plan is equally important. An agent without clear exit rules might hold a losing position indefinitely or take profits too early. By defining the exit plan in the control layer, you ensure the agent closes positions according to your risk parameters, not its own shifting logic. The panic switch is your last line of defense. If market conditions change suddenly or the agent begins acting outside expected parameters, you can trigger the switch and know that all positions will be flattened and the key revoked within seconds. You do not need to trust the agent to stop itself. How to set spend caps and drawdown limits for trading agents.

How does dollar sizing work across different market types?

When you send an order through the API, you size it in plain US dollars. The system normalizes the amount into the correct units for each venue. If the agent wants to open a one hundred dollar position, the API converts that into the appropriate number of shares, tokens, contracts, or lots, depending on whether you are trading through a stock broker, a crypto venue, a perps venue, an options venue, or a prediction market. The agent does not need to know contract multipliers, tick sizes, or margin requirements. This reduces errors and prevents the agent from accidentally submitting oversized orders because it misunderstood the denomination of a particular instrument. You define the risk in dollars, and the infrastructure handles the translation. Dollar sizing is particularly important when an agent trades across multiple market types in a single strategy. A share of stock, a perpetual futures contract, and an options lot have very different notional values and leverage structures. If the agent had to calculate these manually, it would need access to real-time contract specifications and leverage ratios. By abstracting this away, the API lets the agent focus on signal generation and portfolio logic while the execution layer handles the mechanical details. For example, if your strategy allocates five percent of the portfolio to a single position, the agent sends a dollar amount equal to five percent of the total budget. The API then calculates the exact quantity for the venue in question. Whether that venue deals in hundred-dollar lots or thousand-dollar contracts, the agent is shielded from the complexity. The conversion is transparent to you. You can audit the filled notional in the response to confirm that the dollar amount was translated correctly. If the market lacks sufficient liquidity to fill the desired dollar amount, the order is partially filled or rejected according to the rules you set. This consistency means you can run the same strategy across a stock broker and a crypto venue without rewriting the sizing logic.

What does the setup look like in practice?

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

POST /v1/orders
Authorization: Bearer YOUR_KEY
Content-Type: application/json

{
  "market": "example-market",
  "side": "buy",
  "dollar_amount": 100,
  "key_id": "YOUR_SCOPED_KEY"
}

The response returns the order status and the actual filled notional. The key ID ensures the order is checked against your scoped permissions and budget cap before it reaches the market. For testing, you use a paper trading key that routes to simulated execution. When you are ready, you authorize a live key with identical scope but real settlement. The setup is the same across all five market types, so you do not need to rewrite integration logic when moving from a stock broker to a perps venue or a prediction market. The MCP approach is useful if you want the agent to reason about trades in natural language and then call tools to execute. The REST approach is useful if you want precise programmatic control. In both cases, the authentication layer is the same scoped key. You generate the key in the dashboard, copy the credential into your agent's environment, and the agent begins trading within the limits you defined. There is no need to share private keys or seed phrases. There is no need to deposit funds into a separate pool. The wallet remains yours, and the key is simply a permission to trade. When you rotate or revoke the key, the agent loses access immediately. This makes operational security straightforward. If you suspect the key has leaked, you revoke it and issue a new one without moving funds or changing wallets. A practical checklist for building your first LLM-powered trading agent.

How do you move from paper trading to live execution?

Paper trading exists for testing. It uses live market data and the same API paths, but orders clear against simulated liquidity. This lets you verify that your agent interprets signals correctly, sizes positions in dollars, respects budget caps, and handles errors without risking capital. Live trading requires explicit owner authorization of a key. You create the scoped key, review the permissions, set the budget, and then authorize it for real settlement. Once live, the same controls apply. The agent can still lose money, including everything you have allocated to the budget cap. There is no guarantee of profit, and the speed of agent execution can compound losses as quickly as it can compound gains. You should only authorize live trading after you have observed stable behavior in paper mode for a period you are comfortable with. The transition from paper to live is intentionally simple because the API surface is identical. You do not need to change code, update endpoints, or retrain the agent. You simply swap the paper key for a live key. This reduces the risk of introducing bugs during the transition. However, the psychological and financial difference is significant. In paper mode, a drawdown is a data point. In live mode, it is a realized loss. You should start with a small live budget even if the paper results are encouraging. Markets change, slippage differs between simulated and real liquidity, and the agent might behave differently when it encounters real execution delays or partial fills. Some developers choose to run paper and live agents side by side for a time, comparing fills and slippage. This can reveal whether the agent's logic makes assumptions about execution that do not hold in real markets. Once you are satisfied that the live behavior is predictable, you can gradually increase the budget cap. Monitor the first live trades closely. Verify that the dollar sizing matches your expectations and that the budget cap is triggering correctly. Keep the panic switch accessible. If the live behavior diverges from paper behavior, revoke the key and investigate before increasing the budget.

Frequently asked questions