How to trade options with an AI agent without giving up custody

Developers can automate options strategies through an AI agent without ever depositing funds to a centralized exchange or broker. The agent receives a scoped key that can place trades and manage positions within owner-defined limits, but it cannot withdraw funds or move capital to an unapproved address. The owner retains the private key to the wallet where the capital sits, and the agent simply routes orders through an API that normalizes contract specifications across multiple venues. This model keeps the developer in full custody while still allowing algorithmic execution of complex options positions, including multi-leg spreads and rolling adjustments.

Why does custody matter for options trading with agents?

Options have asymmetric payoff profiles, time decay, and path-dependent risks that make capital preservation especially important. When you deposit funds to a traditional trading account, you give up direct control and introduce counterparty risk. The venue holds your capital and could freeze, delay, or lose access to it due to operational issues. For an AI agent, the risk compounds because the software operates continuously, and a bug or prompt misinterpretation could trigger unintended orders rapidly while you are not watching. Short options in particular can expose you to assignment risk and large margin calls, so keeping the collateral in your own wallet rather than a third-party pool is a meaningful reduction in counterparty exposure. Trading options can lose money, including your entire allocated budget, and non-custodial controls do not eliminate market risk. Non-custodial architecture removes the possibility of the agent or the venue absconding with funds, because the capital remains in a wallet only the owner controls. The agent can only spend within pre-approved limits, and withdrawals are restricted to addresses the owner has explicitly whitelisted. This is critical in options markets, where assignment risk, margin changes, and expiration events can alter your position dramatically without warning. Algorithmic traders keep self-custody with a single API by design, and this structure is especially valuable when an agent is managing short-dated or short-gamma positions.

How does a non-custodial options agent actually work?

The architecture is straightforward. You create a wallet that you control, and you fund it with the capital you are willing to allocate. You then generate a scoped API key through the Felix platform that grants permission to trade options at an options venue, but explicitly denies withdrawal rights. The agent, whether it is a Claude MCP client, a Cursor integration, or a custom REST service, receives this key and uses it to read market data and submit orders. The connection method does not change the custody model; in all cases, the key is scoped and the wallet remains under your control. The API translates your agent's plain dollar-denominated instructions into the venue-specific contract language, handling multipliers, strike notation, expiration dates, and any venue-specific order types. Funds never leave your wallet except to pay for the contracts you buy or to meet margin requirements for short positions. Any premium received from selling options flows back to your wallet immediately. Settlement and assignment, if they occur, also resolve within your controlled wallet rather than a pooled exchange account. A single API keeps AI trading agents safe by design because it enforces these boundaries at the infrastructure layer, not inside the agent's logic, which means a bug in your strategy code cannot rewrite the permission rules.

What controls prevent an agent from exceeding your risk limits?

Hard limits are the primary defense against a malfunctioning or misinformed agent. You define these before the agent starts trading, and the API enforces them on every order. The agent cannot negotiate around them, because the checks happen outside the agent's environment in the API gateway. You should set limits that reflect the specific risks of options, not just generic trading caps. For options specifically, you may want to set a maximum allocation to short premium strategies, because the income can be attractive while the tail risk is significant. You can also restrict the agent from holding positions through expiration, which avoids the complexity of after-hours assignment and settlement.

• ·Budget caps set the maximum US dollar value the agent can deploy across all options positions at any given time.
• ·Position limits restrict the number of contracts, notional exposure, or net delta the agent can accumulate in a single underlying or across the entire portfolio.
• ·Scoped keys limit which markets and order types the agent can access, so an options key cannot suddenly trade perps or withdraw funds.
• ·Exit plans define how and when the agent should close positions, such as before expiration or after a certain drawdown threshold.
• ·A panic kill switch flattens all positions and revokes the key instantly, stopping all further activity without waiting for the agent to cooperate.

Because these controls live in the API layer, even a compromised agent key is trapped inside your rules. The agent might try to buy more calls than you intended, but the API will reject the order if it violates the cap. Kill switches enforce hard limits that trading agents cannot cross, and you can control risk when an AI agent trades through MCP using the same scoped permission model that works across stocks, crypto, and other markets.

How do you size and express options trades through a single API?

Options contracts vary by venue. Some use multipliers of one hundred, others use different decimal conventions, and strike notation can differ between chain providers. The Felix API abstracts this by accepting orders sized in plain US dollars and translating the intent into the correct contract parameters. When your agent sends an order, it specifies the target dollar exposure, the underlying, the option type, the strike, and the expiration. The API computes the required number of contracts, rounds according to lot size, and submits the order to the connected options venue. For multi-leg strategies, the agent can send a target dollar amount for the entire spread, and the API will allocate the legs according to the current market prices for each component, respecting the total budget you set.

curl -X POST "URL_FROM_DOCS" \
  -H "Authorization: Bearer YOUR_KEY" \
  -d '{
    "market": "options",
    "underlying": "EXAMPLE",
    "target_usd": 5000,
    "direction": "buy",
    "instrument": {
      "strike": 100,
      "expiration": "2026-09-18",
      "type": "call"
    }
  }'

Dollar-based sizing simplifies the agent's reasoning, but it does not eliminate the complexity of options Greeks. An agent that thinks only in dollars might ignore delta, gamma, or theta, and it might hold a position through expiration without understanding assignment risk. You should still program the agent to check Greeks or to favor simple structures like defined-risk spreads. The API handles the contract math, but the strategy logic remains your responsibility. Be explicit in your prompts about whether the agent is allowed to sell naked options, because the margin requirements and potential losses differ sharply from long-only strategies.

What should you test before letting an agent trade live options?

Paper trading is essential. The Felix paper environment uses the same API shape as live trading, so your agent code requires no changes when you transition. You should test more than just basic buy and sell orders. Options have unique lifecycle events, and an agent that works for stocks may fail when faced with expiration or multi-leg execution. Options Greeks are not automatically managed by the API on your behalf. If your agent is delta-neutral in intent but only checks prices, it may end up with significant directional exposure. Your testing should include verifying that the agent reads delta, gamma, theta, and vega, or that it restricts itself to structures where these risks are bounded, such as iron condors or butterflies with defined maximum loss.

1. 01Verify that the agent correctly opens and closes single-leg options and that the resulting position appears in your wallet.
2. 02Test multi-leg spreads, such as vertical spreads, to ensure the agent groups legs properly and does not leave one side unexecuted.
3. 03Confirm that the agent rolls positions before expiration rather than letting contracts expire into unexpected assignment.
4. 04Check that budget caps and position limits trigger rejections when the agent attempts to exceed them, even with partial fills.
5. 05Simulate a rapid drawdown scenario to see if the agent follows your exit plan or if it attempts to average down against your rules.
6. 06Test the kill switch by triggering it during a paper session to observe how quickly the agent flattens and loses access.

After paper testing, review the prompt or code that drives the agent. Ambiguous instructions like 'hedge my portfolio' can be interpreted in ways that produce unexpected options positions. You should also verify that the MCP tool schema or REST endpoints your agent uses match the current docs, because stale parameters can cause failed orders or incorrect sizing. Finally, test how the agent handles a situation where the options venue rejects an order due to liquidity or wide spreads. A good agent should pause or retry within bounds, not blast the market with repeated orders.

How do you shut down an options agent if something goes wrong?

Markets move fast, and options can swing from out-of-the-money to in-the-money in minutes. If your agent begins acting unexpectedly, you need a shutdown mechanism that works faster than you can read logs. The panic kill switch is designed for this. When activated, it immediately revokes the agent's API key, which stops new orders from being accepted at the gateway. It then submits flatten orders for all open options positions, converting them back to cash or the underlying as appropriate, and returns the resulting capital to your wallet.

Because the system is non-custodial, the agent never had the ability to withdraw to its own address in the first place. Revocation simply removes its trading privileges. You should keep the kill switch accessible outside the agent's normal interface, either through a dashboard or an emergency webhook, so you can act even if the agent's host is unresponsive. You should also consider whether your flatten orders will execute as market orders or limit orders, because options markets can become illiquid during stress events. A market order in a wide spread can fill far from the last traded price, so some developers prefer to set the kill switch to revoke first and then manually manage the unwind during liquid hours. Near expiration, you may want to flatten manually rather than wait for an automated close, because liquidity can evaporate and bid-ask spreads can widen sharply in the final hours. After a shutdown, audit the agent's logs to determine whether the issue was a strategy bug, a bad data feed, or a prompt misinterpretation. Only generate a new scoped key and restart after you have fixed the root cause and re-tested in paper mode.