How to trade perpetual futures with an AI agent using real money

An AI agent can trade perpetual futures with real money once you create a scoped API key, define a hard budget cap, and authorize the key for live trading. The agent connects through MCP tools or the REST API and places orders sized in plain US dollars, while the infrastructure normalizes margin calculations for the underlying venue. Funds stay in a wallet you control, and the agent cannot withdraw or exceed the limits you set. You must explicitly approve the key for live trading because paper trading is the default for all new agents.

What do you need before an AI agent can trade perps with real money?

Perpetual futures differ from spot markets because they do not expire and they trade with margin. An agent holding a perps position must monitor funding rates, mark prices, and margin requirements continuously. Before you deploy an agent, you should understand the venue's margin model, whether it uses isolated or cross margin, and how liquidations are priced. You do not need to hand the agent unrestricted access.

• ·A wallet you control with sufficient margin for the budget cap you intend to set.
• ·A scoped API key restricted to perpetual futures and approved symbols only.
• ·A defined budget cap, position limit, and exit plan enforced by the API.
• ·A period of paper trading to observe the agent's behavior under volatile conditions.
• ·Explicit owner authorization before the key is permitted to access live markets.

If the agent has never traded live before, run it in paper trading mode first to observe how it reacts to volatility, lag, and partial fills. Paper trading mirrors live market data and execution logic without capital risk. When you are ready to trade with real money, the authorization step is a deliberate toggle that requires your explicit approval. The agent cannot graduate itself from paper to live. You should decide whether the venue uses isolated margin, where each position has its own collateral, or cross margin, where all positions share a single collateral pool. An agent trading in cross margin must account for total wallet exposure, while an agent in isolated margin can treat each position independently. You should also check whether the venue uses linear or inverse contracts, because the P&L calculation differs. However, the API abstracts most of this away from the agent by reporting everything in USD. Still, you should know the underlying mechanics so you can set sensible limits.

How do you build a scoped key and set hard limits?

The first concrete step is to create a scoped API key that restricts what the agent can touch. How to build scoped API keys for a trading agent step by step covers the mechanics, but the principle is simple: the key should permit trading on perpetual futures venues and reading market data, while blocking withdrawals and access to other market types if your strategy does not need them. You can scope by market type, by total budget, by maximum position size per symbol, and by approved trading hours. After scoping, you set hard limits. A budget cap defines the total US dollars the agent can deploy across all perps positions. A position limit defines the maximum dollar value the agent can hold in a single symbol. These limits are enforced by the API, not by the agent's own code, so a bug or prompt injection cannot override them. You should also define an exit plan. This can be a take profit level, a stop loss level, or a time limit that forces a flat position before a known event. The exit plan can be automated through the API or executed manually via the panic switch if the agent's behavior diverges from your intent. You can also restrict the agent to specific symbols. If your strategy is designed for major markets only, there is no reason to let the agent trade obscure contracts with thin liquidity. Symbol scoping prevents the model from hallucinating a trade on a market you never intended. You can also restrict the agent to long-only or short-only if your strategy has a directional bias. Each restriction reduces the attack surface and the chance of an unintended position.

How to control the risks of LLM-powered trading without giving up custody explains how these controls fit together. The key point is that the agent operates within a sandbox created by the key. Even if the underlying model generates a dangerous instruction, the infrastructure blocks it. The panic switch sits outside the agent loop. You can press it at any time to flatten all positions and revoke the key permanently. Because the system is non-custodial, the funds never sit in a pool controlled by the API provider. They remain in your wallet, and the agent can only spend within the approved scope.

How does dollar-based sizing normalize perps contracts?

Perpetual futures venues use different contract sizes, margin tokens, and tick increments. Some quote in lots, some in coins, and some in notional USD. An AI agent should not be forced to learn each venue's contract math. How to start trading with dollar-based order sizing in 2026 describes why this matters. The Felix API accepts order sizes in plain US dollars. When the agent requests a $500 long position on a BTC perpetual, the API translates that into the correct number of contracts, rounds to the venue's tick size, and handles the margin requirement. The agent sees the world in dollars, which simplifies strategy logic and reduces errors caused by decimal mismatches or unit confusion. You still need to set a leverage ceiling in your scoped key, because the dollar size is the capital the agent allocates, but the notional exposure depends on the leverage setting you choose. Keep leverage conservative until you have validated the agent's behavior under live conditions. This abstraction is especially useful when the agent trades across multiple perps venues. One venue might require minimum order sizes of $100, while another might allow $10. The API enforces the venue's minimums and rejects orders that are too small, returning a clear error to the agent. The agent can then adjust its next signal rather than crashing on a formatting error.

How does the agent open and track a position?

Once the key is scoped and the strategy is defined, the agent enters a loop. It fetches market data, evaluates its strategy, and decides whether to open, hold, or close a position. For perpetual futures, the agent should also track the funding rate, because holding a position through funding intervals can erode or add small amounts of profit over time. The agent places an order by specifying the symbol, side, and dollar size. The API returns a fill confirmation and updates the position balance. The agent should store the fill price and timestamp to calculate running profit and loss. It should also check the position against the scoped limit after each fill to ensure it has not breached the cap. If the agent uses MCP tools, it can run inside Claude, Cursor, or another MCP client and call trading tools as functions. If it uses the REST API directly, it runs as a standalone script or service that polls and posts to the endpoints. The agent should also log the mark price at the time of each fill. This helps you audit whether the agent received fair execution. If the fill price is far from the mark price, you may be trading on a venue with low liquidity or wide spreads. In that case, you should reduce position size or choose a different symbol. The agent should not assume that all perps contracts behave like liquid spot markets.

The exact request schema is in the docs; the shape looks like this:

{
  "api_key": "YOUR_KEY",
  "symbol": "BTC-PERP",
  "side": "buy",
  "dollar_size": 500,
  "time_in_force": "gtc"
}

This is a generic illustration. The actual field names, authentication headers, and endpoint paths are documented at /docs. The key point is that the agent sends a human-readable dollar amount and the system handles the rest. After placing the order, the agent should poll for fill status or subscribe to execution reports. It should update its internal state only after receiving a confirmed fill, not after merely sending the order. Latency, partial fills, and rejections are all real possibilities that the agent must handle. A robust agent checks for errors, logs them, and pauses rather than retrying blindly.

What happens when the position needs to close or the strategy fails?

Every position eventually closes, either through the agent's strategy, the exit plan, or your intervention. The exit plan should be defined before the trade opens. Suppose you set a rule that the agent must close if the mark price drops 5 percent from entry. The API can enforce this as a stop loss, or the agent can monitor the price and issue a close order. If the agent is supposed to hold for a fixed duration and then flatten, the exit plan enforces that time limit. When the strategy fails, meaning the agent starts placing orders that do not match your intent, the panic switch is the final layer. It immediately sends close orders for all open positions and revokes the API key. The agent loses all access within seconds. You retain custody of the wallet, and any remaining funds are safe from further agent activity. You should also consider what happens if the agent loses network connectivity. A good safety setup does not rely on the agent to close positions during a crash. The API-level exit plan or stop loss should remain active even if the agent's server goes offline. This prevents a disconnected agent from leaving a leveraged position exposed to market moves while it is unable to respond.

Trading perpetual futures with leverage can lose money quickly, including your entire budget. Liquidation is a real risk if the position size is too large relative to the margin in your wallet. The scoped limits and conservative leverage are designed to keep the agent far from liquidation territory. You should size the initial budget as an amount you are willing to lose entirely. Treat the first live deployment as an experiment with strict capital controls. The goal is to validate the agent's execution behavior, not to generate large returns on the first attempt. If the agent survives a week of live trading within its limits, you can review the logs and decide whether to adjust the strategy or keep the current parameters. You should also monitor the funding rate history for the symbols your agent trades. If funding is consistently negative for longs, holding a position overnight may cost more than the strategy expects. The agent can read funding rates through the API, but you should verify that it actually does so. Some strategies ignore funding and assume that price movement alone will generate profit. On perpetual futures, funding is a real cost that compounds over time.

How do you audit and revoke access after a trading session?

After a trading session, review the agent's activity through the API logs or dashboard. Look at the total number of orders, the fill rate, the average slippage, and the net profit or loss in US dollars. Because orders are sized in dollars, the accounting is straightforward. You do not need to convert from venue-specific units. Compare the live results against the agent's paper trading history. Common mistakes developers make with paper trading for AI agents explains why paper results often diverge from live results. Factors like latency, partial fills, and market impact can change the outcome. If the live performance differs significantly from paper, investigate whether the agent's assumptions about liquidity or execution speed were wrong.

If you decide to stop the agent, revoke the API key. If you want to pause and resume later, you can disable the key without deleting it. Check that no open positions remain before you revoke, or use the panic switch to flatten first. Because the system is non-custodial, revoking the key does not affect your wallet balance. The funds stay where they are, and you can withdraw them to an owner-approved address whenever you choose. The agent never had the power to move funds out of your control. This is the core difference between agentic trading infrastructure and custodial alternatives. You delegate execution, not ownership.