How an AI agent trades perpetual futures within hard limits it cannot cross

Perpetual futures are leveraged derivatives that track an underlying price without a fixed expiry, so an AI agent trading them must operate inside a rigid boundary system that the agent itself cannot modify. The architecture separates the owner-controlled wallet from the agent's execution key, enforces budget and position limits below the agent layer, and provides a panic switch that flattens exposure and revokes access. Orders are sized in US dollars so the agent reasons in familiar terms, while the system normalizes margin calculations, funding rates, and contract sizes across venues. This design keeps the agent useful but bounded, even when leverage amplifies the cost of a mistake.

What makes perpetual futures different for an agent?

Perpetual futures do not expire, but they accrue funding payments that shift value between long and short holders every few hours. Because venues offer leverage, a small move in the underlying price can produce a large change in the margin balance and, in extreme cases, trigger liquidation. An AI agent that reasons in percentages or token counts can misjudge notional exposure if the system does not translate intent into contract math. The architecture therefore presents the market as plain US dollar positions to the agent, while the infrastructure handles margin requirements, funding conversions, and leverage ratios behind the scenes. This abstraction matters because it lets the agent focus on directional or market-neutral intent without needing to manage venue-specific contract denominations or mark-price mechanics.

Trading perpetuals also introduces liquidation risk. If the margin balance drops below a venue's maintenance threshold, the position can be closed automatically and the remaining margin may be lost. The architecture must prevent the agent from opening a position so large that a routine price gap triggers liquidation, or from adding to a losing position in a way that erodes the wallet balance. Hard limits on notional size, margin usage, and total drawdown are therefore not optional features. They are structural guardrails that sit between the agent and the venue, evaluated on every request before any signature is produced.

How does the non-custodial layer work?

Funds remain in a wallet that the owner controls. The agent receives a scoped API key that allows it to place and cancel orders, read balances, and query positions, but it cannot withdraw funds or add new withdrawal addresses. Withdrawal addresses are owner-approved at setup time, and the agent key has no power to change them. This means that even if the agent were prompted to act maliciously, or if its key were compromised, the worst case is limited to the capital deployed inside the trading budget. The owner retains the withdrawal key, and the platform itself cannot move funds to an unapproved address.

The separation is enforced by the key scope and by a policy engine that evaluates every request, not merely by the agent's instructions. The owner can revoke the key at any time through a separate authentication path that the agent does not share. Because the architecture is non-custodial by construction, the platform never takes control of the wallet. It only routes signed transactions and checks them against the owner's stated limits. This is a different model from giving a venue full custody of funds and then trusting an API to behave. If you want to see how these boundaries are set during onboarding, start an AI trading agent with hard limits covers the setup sequence.

Where are the hard limits enforced and what happens when the agent hits them?

Hard limits are enforced at the infrastructure layer, below the agent, so they hold even if the agent generates a bad request or a hallucinated parameter. The owner configures a maximum budget in US dollars, a maximum position size per market, and a maximum account leverage. When the agent submits an order, the system checks the intended notional value against the remaining budget and the open position cap. If the order would exceed either limit, the request is rejected before it reaches a venue. The agent receives a clear error and can adjust, but it cannot bypass the gate by rephrasing the request.

The budget cap is a hard ceiling on the total capital the agent is allowed to deploy at any moment. It is not a trailing stop or a suggestion. It is a spending limit that resets only when the owner adjusts it. Similarly, position limits prevent concentration in a single perpetual market. The system also enforces a margin cap so that the agent cannot open positions so large that the account sits near liquidation. These constraints are stored in a policy layer that evaluates every request independently of the agent's reasoning. The mechanics of budget enforcement are discussed in how an AI agent trades within a hard budget it cannot exceed.

When an order violates a limit, the system returns a rejection with a clear reason code. The agent can log the failure and retry with a smaller size, or it can pause and wait for new instructions. The owner sees the rejection in the audit stream, so there is transparency into how often the agent is bumping against its boundaries. If the account approaches a margin threshold due to market movement rather than agent action, the system can optionally flatten the position or notify the owner, depending on the exit plan configured at setup.

The agent does not have the ability to raise its own limits, to whitelist new addresses, or to disable monitoring. If it attempts to do so through a prompt injection or a malformed request, the action is blocked at the policy layer. This is important because large language models can hallucinate parameters or misinterpret market conditions. The architecture assumes that the agent might make mistakes, and it treats the limits as a safety net rather than a coaching tool. If the agent repeatedly hits limits in a short window, the system can temporarily suspend the key to give the owner time to review.

How is position sizing bounded?

Sizing is one of the most error-prone areas when an agent interacts with leverage. The architecture translates every order into a US dollar notional value before converting to contracts. This means the agent can think in terms of opening a five hundred dollar long position rather than buying a fractional number of contracts. The system then checks that the requested notional, plus existing exposure, stays within the owner's per-market limit and the total account budget. Because perpetual futures are leveraged, the notional value can be many times larger than the margin posted.

The owner sets a maximum leverage ratio, and the system rejects any order that would push the account above it. For example, if the owner caps leverage at three times and the wallet holds one thousand dollars in margin, the agent cannot open more than three thousand dollars in total notional exposure. This check happens after the agent formulates the trade but before the trade is signed and sent to the venue. If the agent already holds a position and tries to add to it, the system evaluates the aggregate notional and the combined margin requirement. You can read more about the logic behind these choices in position sizing for an AI trading agent from first principles.

How does the kill switch work?

Every deployment includes a panic switch that the owner can trigger without the agent's consent. When activated, the system cancels all open orders, flattens open perpetual positions at market, and revokes the agent's API key. The agent cannot intercept this process because the revocation path uses the owner's credentials, not the agent's scoped key. Once the key is revoked, the agent loses all trading and reading access until the owner issues a new key.

The kill switch is designed to terminate activity in seconds. Because perpetual futures use leverage, a fast exit is more important than for spot markets. The flattening logic sends offsetting orders to close exposure, and it respects the same position limits to prevent an accidental oversized close. After the positions are flat, the budget cap is effectively reset to zero because the agent can no longer act. The design of this mechanism is covered in detail in how to build a kill switch your trading agent cannot override.

How do agents connect to perpetual futures venues?

Agents can connect through MCP tools in clients like Claude or Cursor, or directly through the REST API. The same API key works across stocks, crypto, options, and prediction markets, but the scoped permissions for perps include order placement, cancellation, and position queries. The system normalizes the differences between venues so that the agent does not need to track varying margin models or contract sizes. The owner can test the full boundary logic in paper trading before authorizing live keys. When using MCP, the agent calls standard tools such as place_order or get_position. The MCP server holds the scoped key and forwards requests to the REST API. This means the agent itself does not store credentials, and the owner can rotate keys without updating the agent's codebase.

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

{
  "key": "YOUR_KEY",
  "market_type": "perps",
  "intent": {
    "direction": "long",
    "notional_usd": 500
  },
  "symbol": "BTC-PERP"
}

The system translates the notional USD amount into the correct contract size, checks the request against the owner's budget and position limits, and then routes it to the appropriate venue. The agent never sees the raw contract math, and it never handles the venue's native margin calculations. If the request passes the policy checks, the system signs and sends the order. If it fails, the agent receives an error in the same format, allowing it to adjust its plan.

Paper trading allows the owner to observe how the agent behaves when funding rates, margin calls, and leverage are simulated with real market data but no real capital. It is a chance to verify that the hard limits trigger correctly, that the agent interprets rejection messages gracefully, and that the kill switch flattens positions as expected. Developers should treat paper trading as a mandatory integration test for the policy layer. It exposes whether the agent retries aggressively on rejections, whether it misinterprets notional values, and whether the kill switch leaves any residual exposure. Fixing these issues in simulation prevents forced interventions later.

Live trading requires explicit owner authorization of a key. The authorization step is a deliberate friction that forces the owner to confirm that the budget cap, position limits, and kill switch are configured correctly. Once authorized, the agent operates under the same rules as in paper mode, but with real money at risk. Trading can lose money, including everything, and leverage makes that outcome faster. Paper trading does not guarantee future behavior, but it does prove that the guardrails are mechanically sound before the agent touches real margin.

Frequently asked questions