How hard limits control the remaining risks of non-custodial agent trading

Non-custodial agent trading means the agent never holds your funds in its own wallet, so it cannot steal them or withdraw them to an unknown address. However, the agent can still lose money through normal market movement, execution errors, and prompt-level mistakes if it has too much freedom to trade. Hard limits enforce boundaries that the agent cannot override: a maximum budget per key, position caps, scoped permissions, and a kill switch that flattens positions and revokes access. These controls turn an autonomous agent into a bounded tool that can only operate inside the owner's predefined safety envelope.

What risks remain when the agent cannot steal funds?

Non-custodial architecture removes the single greatest risk in automated trading: the possibility that the operator of the software runs away with the money. In a non-custodial system, the owner retains control of the wallet, and withdrawal addresses are owner-approved only. The agent receives a scoped key that can spend within limits but cannot withdraw funds to itself.

That removal of custody risk does not eliminate other risks. The agent can still lose capital through ordinary market volatility. Suppose you give an agent a strategy to buy a stock and the price drops thirty percent before the agent exits. That loss is real market risk, not theft, and non-custodial design does not prevent it.

Execution risk is another category. An agent might misread an order book, place an order at the wrong price, or trade the wrong instrument because of a prompt hallucination or a malformed webhook payload.

Concentration risk matters too. Without a position limit, an agent could allocate the entire budget to a single options contract or a single perpetual future. Even if the venue is reputable and the wallet is secure, a concentrated bet can wipe out the allocated budget in one move. This is especially dangerous in leveraged products where a small adverse move can exceed the initial margin.

Operational risks include infinite loops where a webhook triggers a new order, which triggers another webhook, which triggers another order. An agent might also interpret news incorrectly and trade on a false signal. It might receive a malformed data packet and decide to double the intended position size. Hard limits do not prevent the agent from making a mistake, but they prevent the mistake from propagating beyond the boundaries you set. A budget cap stops a loop after a few iterations. A position limit stops a single oversized bet. These are mechanical guardrails, not strategic advice.

Model risk is a related concern. The agent might be running a strategy that backtested well on historical data but fails in current conditions. A budget cap ensures that the model risk is contained to the allocated envelope, not the entire portfolio.

How do scoped keys and budget caps work in practice?

Felix uses scoped API keys to define what an agent is allowed to do. A key can be restricted to specific market types, such as stocks or prediction markets, and can be barred from others. The owner can also limit the key to read-only operations, or allow placing orders but not canceling them, depending on the strategy. If the strategy only trades equities, the key should not have access to perpetual futures or options. This scope restriction prevents the agent from wandering into unfamiliar markets if a prompt goes off track.

Budget caps are enforced in plain US dollars. When an agent attempts to place an order, the system checks the total notional value against the remaining budget for that key. If the order would exceed the cap, the request is rejected before it reaches any venue. This normalization happens regardless of whether the underlying instrument is a crypto spot pair, a perps contract, or an equity share. A five hundred dollar order counts the same against the cap whether it is a stock share or a prediction market position. The developer does not need to calculate lot sizes, tick sizes, or contract multipliers by hand.

The non-custodial construction means the funds sit in a wallet the owner controls. The agent can spend within the limits but can never withdraw to itself or steal. Withdrawal addresses are owner-approved only. Non-custodial trading for AI agents explains how this custody model works in detail.

For developers, the configuration of these limits is part of the key setup. The exact request schema is in the docs; the shape looks like this:

{
  "key_name": "agent-1-scoped",
  "budget_usd": 5000,
  "allowed_markets": ["stocks", "prediction_markets"],
  "allow_withdrawal": false,
  "max_position_usd": 1000
}

You would replace the placeholders with your own parameters and store the resulting key identifier in your agent's environment. The key is bound to your wallet, and the agent can only trade within the envelope you define.

Developers can rotate keys easily. If one key reaches its budget cap or needs to be retired, the owner can create a new scoped key with different parameters without moving funds to a new wallet. The funds remain in the same owner-controlled wallet throughout.

What happens when an agent hits a position limit or exit plan?

Position limits stop the agent from opening a notional exposure larger than the owner allows. If the limit is one thousand dollars per symbol and the agent already holds nine hundred dollars, a new order for two hundred dollars will be rejected. This applies across all five market types, because the API normalizes venue-specific contract math into plain dollar amounts. The owner does not need to trust the agent to respect the limit; the system enforces it at the order level.

Exit plans are automated rules that trigger when a position moves against the owner or when a target is reached. An exit plan can flatten a position, meaning it closes the entire exposure and returns the account to cash. These plans run outside the agent's own logic, so even if the agent is unresponsive, stuck in a loop, or hallucinating, the exit plan can still execute. Think of the exit plan as a safety net beneath the strategy.

Because orders are sized in plain US dollars, the owner does not need to calculate lot sizes, contract multipliers, or margin requirements for each venue manually. The API handles the conversion. This reduces the chance that the agent makes a decimal-place error and opens a position fifty times larger than intended. A dollar-based order is easier to audit and easier to limit.

Hard limits also interact with each other. A budget cap is the global ceiling for the key. A position limit is the per-trade or per-symbol ceiling. An exit plan is the time or price trigger. Together they form layers: the agent can only trade inside the market scope, only up to the budget, only up to the position size, and only until the exit plan fires. How autonomous trading systems enforce hard limits the agent cannot cross describes this layering in more detail.

Why is a kill switch necessary if the system is already non-custodial?

Non-custodial design prevents theft, but it does not prevent the agent from trading badly while the owner sleeps. A kill switch is a hard control that immediately flattens all open positions and revokes the API key. Once triggered, the agent cannot place new orders, and any existing exposure is closed. The owner retains the funds, but the funds may have lost value during the trading session. The kill switch stops the bleeding.

This is useful when the owner notices unexpected behavior, such as a series of losing trades, a webhook storm, or a strategy that no longer matches market conditions. Rather than logging into multiple venues to close positions manually, the owner presses one control. The system then sends close orders and disables the key. The speed of this action matters because every second of delay in a fast market can deepen the loss.

The kill switch is also a safeguard against compromise. If an attacker gains access to the agent's environment or prompt context, they might try to make the agent trade toward a malicious goal. Scoped keys and budget caps limit the damage, but the kill switch ends the session entirely. It is the final layer of defense.

Paper trading exists for testing these mechanisms. Before an owner authorizes live trading, they can run the agent against simulated markets and verify that the kill switch flattens positions, that budget caps reject oversized orders, and that scoped keys block unauthorized markets. Live trading requires explicit owner authorization of a key. How to take an AI trading agent live with real money outlines the authorization steps.

How should a developer test hard limits before going live?

Developers should treat hard limits as part of the strategy, not as an afterthought. The following four steps create a practical testing framework.

1. 01Define the worst-case loss you are willing to accept per key. That number becomes the budget cap. If you cannot afford to lose the entire cap, make it smaller.
2. 02Define the maximum exposure you want in any single instrument. That becomes the position limit. A common starting point is to limit any single position to a small fraction of the total budget cap.
3. 03Build an exit plan before the first order. Decide under what conditions the agent must close positions and return to cash. This can be a stop level, a time limit, or a manual trigger.
4. 04Test every limit in paper trading. Submit an order that exceeds the budget and confirm it is rejected. Open a position and trigger the kill switch to confirm it flattens. Attempt to access a disallowed market and confirm the scope restriction blocks the request.

Developers connecting through MCP tools, such as Claude or Cursor, should verify that the tool definitions the agent sees match the scoped permissions of the key. If the key is scoped to stocks only, the MCP client should not expose crypto trading functions to the agent. This alignment prevents the agent from attempting actions that will be rejected, which reduces error loops and false confidence. An agent that repeatedly tries to trade crypto through a stock-only key will waste time and generate confusing logs.

When moving to live trading, start with a small budget cap and a short time limit. Increase the scope only after the agent demonstrates stable behavior inside the smaller envelope. Review the logs daily at first. Look for rejected orders, which may indicate the agent is pushing against limits. Rejections are good; they mean the hard limits are working. How to run an AI trading agent with real money, safely provides a practical checklist for this transition.

Finally, document the limits you set. If you return to the project after a month, you should be able to read a configuration file and know exactly what the agent is allowed to do. Documentation prevents accidental scope creep.