How hard limits keep AI agents safe when trading options

AI agents trading options face asymmetric risk where a single leg can expire worthless or expose the seller to theoretically unlimited loss. Felix prevents this with hard limits encoded at the infrastructure level, not in the agent's prompt, so the agent cannot override its own budget cap, position size, or approved strategy scope. These controls are enforced by the API before any order reaches a venue, which means the owner keeps custody and the agent keeps only the specific spending authority it was granted, as described in AI agents trade without custody. The result is that the agent can trade real money, but it can never redefine the boundaries of what it is allowed to do.

What makes options risk different for an AI agent?

Options are not linear instruments. A single contract controls a notional amount of the underlying that can be many times its quoted price, and the value of that contract decays as expiration approaches. An agent that reasons in share counts or token balances can easily misjudge how much capital is actually at risk, especially when it constructs multileg spreads or sells premium to collect income. Short naked calls and short naked puts carry exposure that can exceed the account balance if the underlying moves sharply, and long options can lose one hundred percent of the premium paid. Trading options with real money can lose money, including the entire account balance. Hard limits do not eliminate risk, but they prevent the agent from expanding exposure beyond what the owner has predefined.

The Felix API normalizes every order into a plain US dollar amount so the owner and the agent both reason in the same unit, but the hard limits remain the final authority. Unlike perpetual futures, where funding rates and liquidation prices create a different rhythm of risk, options have fixed expirations and nonlinear Greeks that can change exposure faster than an LLM can describe it in text. how AI agents mishandle perpetual futures Suppose an agent writes a call spread that looks safe on paper but carries assignment risk if the short leg is exercised early. Suppose it then rolls a losing position into a farther expiration without realizing that the new premium commitment pushes it past a notional limit. The owner can stop this by setting a hard rule that only defined risk strategies are permitted, which removes the possibility of assignment turning a limited loss into an unplanned stock position. Because the API enforces this at the key level, the agent does not need to understand early exercise or gamma risk in order to be blocked from them.

How do scoped keys limit what an agent can trade?

A scoped API key is the first line of defense. The owner can create a key that is permitted only for options, only for defined risk strategies such as vertical spreads, or only for long premium. The key can be restricted from selling naked calls, from trading expiration dates under a certain threshold, or from touching specific underlying symbols. These restrictions are not suggestions written into a prompt. They are enforced by the API infrastructure, so even if the agent hallucinates a strategy or misreads its instructions, the order is rejected before it leaves Felix. The owner can also scope a key to a single strategy ID, which means the agent can only place orders that match the preapproved structure. If the agent attempts to deviate, the API returns a rejection.

The scope travels with the key, not with the session. If the owner rotates the key or revokes it, the scope disappears with it. This is useful for testing, because the owner can issue a paper trading key with the same scope as the live key and know that behavior in simulation maps directly to behavior in production. The scope can also include allowed order types. For example, the owner can permit limit orders but block market orders in options, which prevents the agent from accepting a wide spread during a low liquidity period. The exact request schema is in the docs; the shape looks like this:

{
  "scoped_key": "YOUR_KEY",
  "market": "options",
  "direction": "buy_to_open",
  "notional_usd": 500,
  "strategy_id": "defined_risk_spreads_only"
}

A scoped key is a contract between the owner and the infrastructure. The agent is simply a user of that contract.

Where does the budget cap intercept a bad order?

The budget cap is a hard ceiling on committed capital, not a trailing stop that the agent can outrun. When an owner sets a daily or total budget in US dollars, the API tracks every open order, pending premium, and required collateral against that cap. If the agent attempts to open a fifth contract that would push the total above the limit, the request is rejected immediately. The agent does not get a warning that it can negotiate around. The cap accounts for the worst case payout, not the current mark price, so the owner is protected against gap risk. This is particularly important in options, where a single contract can represent a large notional exposure and bid and ask spreads can widen suddenly.

The API also tracks buying power across multiple legs, so a complex spread is evaluated as a single unit against the budget. If the agent tries to leg into a spread one side at a time, the first leg is checked against the cap, and the second leg is checked against the remaining cap. The owner does not need to trust the agent to calculate the net debit or credit correctly. The normalization to US dollars means that an options order at one venue and a stock order at another are both speaking the same unit of account, so the budget cap can aggregate across market types. Paper trading exists for testing these limits without live capital, and live trading requires explicit owner authorization of the key.

A budget cap is different from a margin requirement. A margin requirement is what a venue demands to hold a position. A budget cap is what the owner demands to let the agent trade at all. The agent might have enough margin to open a position and still be blocked by the owner's budget cap. This is the intended behavior. The owner decides the boundary, and the infrastructure enforces it before the venue ever sees the order.

What happens when an agent hits a position or loss limit?

Position limits prevent concentration. An owner can set a maximum number of contracts per underlying, a maximum notional per expiration, or a maximum delta exposure across the entire portfolio. If the agent reaches the contract limit on one symbol and tries to open another leg, the API rejects the order. The agent cannot shuffle symbols to bypass the rule because the limit is keyed to the underlying and the strategy scope, not just the current order. Loss limits work differently. An owner can configure a loss limit that, once hit, triggers an automatic flattening of the position and a temporary trading halt. The agent cannot disable this rule because the rule lives outside the agent's execution loop.

Exit plans can be preloaded so that the agent knows under what conditions it should close, but the agent cannot modify the exit plan without owner approval. Suppose the owner sets a rule that any short option position must be closed if its delta exceeds a certain threshold, or that any long option position must be sold two days before expiration to avoid assignment decay. The agent reads these rules as part of its context, but the infrastructure enforces them as hard limits. If the agent misses the signal or delays, the exit plan can trigger automatically. This removes the dependency on the agent's reasoning speed or its ability to parse market data under stress.

These limits are stored and enforced by the infrastructure, not by the LLM's reasoning process. The distinction matters because an LLM can make errors, omit details, or reinterpret instructions when context windows grow. A hard limit does not reinterpret anything. It evaluates the order against the stored rule and returns a binary result. The agent can then log the rejection and move on, but it cannot argue with the limit.

How does the kill switch work for options positions?

The panic or kill switch is the final hard limit. When an owner activates it, the API immediately attempts to flatten all open options positions, cancels all pending orders, and revokes the agent's key. Because options markets can be less liquid than their underlying spot markets, the flattening logic uses preconfigured parameters set by the owner, such as maximum slippage or allowed order types. The agent does not participate in this decision. Once the switch is thrown, the agent has no access, no budget, and no ability to reopen positions.

Options flattening can be more complex than stock flattening because of multileg positions, time decay, and wide spreads. The owner can configure whether the kill switch should close each leg independently or attempt to close the whole spread as a unit. If the owner chooses spread level closing, the API will attempt to find a counterparty for the entire structure before falling back to individual legs. This is a preference the owner sets when defining the exit plan, not a decision left to the agent during the panic event.

The owner retains full custody of the wallet throughout, and the funds never sit in a venue account that the agent can reach. This is noncustodial by construction. The kill switch is a hard limit that overrides every other setting. Even if the agent has an open order that the owner forgot about, the switch cancels it. Even if the agent has a scheduled task to trade at a specific time, the revoked key makes that task inert. The owner can always reauthorize later with a new key and a new scope, but the old agent session is permanently severed.

How should owners design prompts to stay within hard limits?

Hard limits are enforced by the API, but prompts are still important because they keep the agent from wasting cycles on rejected orders. A well designed prompt tells the agent what its budget, position size, and strategy scope are, so it does not attempt to trade outside them. design prompts for a trading agent The prompt should reference the specific strategy ID and budget cap as facts, not as goals to optimize around. Owners should instruct the agent to check its current position before every order and to interpret rejection messages as final.

The agent should not attempt to split a large order into smaller pieces to bypass a limit, because the API aggregates committed notional across all working orders. Suppose the owner wants the agent to trade around news or events. The prompt should include a rule that volatility spikes do not override the hard budget cap. The agent can be instructed to reduce size when implied volatility rises, but it cannot be instructed to ignore the cap. The prompt is the soft guidance. The infrastructure is the hard boundary. The best practice is to keep the prompt simple, factual, and tightly coupled to the actual scope of the key. If the key is scoped to long premium only, the prompt should not discuss short selling strategies. This reduces the chance of the agent generating text that describes a forbidden action and then attempting it. The Felix docs include prompt templates that map directly to scoped key configurations, so the owner can copy the parameters from the key settings into the prompt context.