How Felix guardrails protect trading agents step by step

Felix guardrails are a system of enforceable limits that operate between the agent and the market. They do not rely on the agent to behave correctly. Instead, every instruction is checked against owner-defined rules for budget, position size, and allowed markets before any order is signed or sent. The result is that the owner can let an autonomous system trade real money while retaining custody and setting hard boundaries on what that system is allowed to lose.

What makes a guardrail different from a prompt instruction?

A prompt tells an agent what to do. A guardrail tells the system what it may do. This distinction matters because large language models can misinterpret prompts, hallucinate parameters, or follow conflicting instructions. A prompt is a suggestion interpreted by a model. A guardrail is a policy enforced by the infrastructure that sits between the agent and the trading venues. The owner writes the policy, the infrastructure enforces it, and the agent cannot override it. Even if the agent produces an order that would exceed the owner’s risk tolerance, the order is blocked before it reaches a venue. This is why relying on prompt engineering alone is insufficient for real money trading. The model may generate a valid looking request that is financially dangerous, and only a mechanical check can stop it. Prompts are interpreted by a language model that has no inherent understanding of dollar values or leverage. It might generate a request to buy a thousand dollars of an asset when the owner intended a hundred, or it might conflate units across different venues. A guardrail does not interpret intent. It checks the numerical value against a hard limit and rejects the order if the value is too large.

How does custody stay with the owner?

Felix is non-custodial by construction. The owner’s funds sit in a wallet that the owner controls through private keys that the agent never sees. The agent receives a scoped key that can place orders and read balances, but it cannot withdraw funds to an external address. Withdrawal addresses are owner-approved only, which means the agent can trade within the limits but cannot steal the capital. This architecture is why algorithmic traders can start with self-custody and hard limits without building their own custody stack. If the agent is compromised, the attacker can only lose what the scoped key is permitted to spend, not the full wallet balance. The owner can revoke the key at any time, and the revocation is immediate. The funds remain in the owner’s wallet, untouched by the infrastructure provider or the agent. Because the wallet is separate from the trading infrastructure, the owner can move funds, change keys, or shut down the agent without asking permission from any platform. The infrastructure never takes custody, which means there is no central pool of user funds to target in an infrastructure-level breach.

How do scoped keys limit what an agent can do?

A scoped key is a credential with a narrow mandate. One key might be allowed to trade only stocks and crypto, while another might be limited to prediction markets and options. Each key carries its own budget cap, maximum position size, and allowed order types. The owner can create multiple keys for different strategies or agents, so a mistake in one agent cannot drain the entire allocation. Agents connect through MCP tools or the REST API using these keys, and the system checks every call against the key’s scope before processing it. The scope includes not only which markets are accessible, but also which actions are permitted. For example, a key might be allowed to open long positions but not short positions, or it might be restricted to limit orders only. This granularity prevents an agent from deviating into unintended behavior. This means a developer can connect an agent built in Claude, Cursor, or any MCP client to a scoped key and know that the agent's creative output is bounded by the key's rules. The connection is just a tool call, but the tool itself has teeth that prevent misuse. The exact request schema is in the docs; the shape looks like this:

POST /trade/v1/order
Authorization: Bearer YOUR_KEY
Content-Type: application/json

{
  "market": "example-market",
  "side": "buy",
  "amount_usd": 100,
  "type": "limit"
}

The response will indicate whether the order passed the guardrail checks or violated a limit. This lets developers see the enforcement layer in action during integration. The key itself does not contain the private key to the wallet, so leaking the scoped key does not expose the owner’s funds to theft. It only exposes the specific budget assigned to that key.

How do budget caps and position limits work in practice?

Orders are sized in plain US dollars, which removes the need for the agent to compute venue-specific contract math. The owner sets a budget cap in dollars, and the system tracks the running total of committed capital across all venues. A position limit prevents the agent from concentrating too much capital in a single market. If an agent tries to place a buy order that would push its total exposure beyond the cap, the order is rejected immediately. This happens before the order is signed, so the agent cannot accidentally or maliciously exceed the limit. The system maintains a live view of open positions, pending orders, and settled trades so that the cap is always evaluated against the current state. This prevents race conditions where an agent might send multiple orders that individually pass but collectively exceed the limit. The tracking is unified across all five market types, so an agent trading stocks, crypto, perps, options, and prediction markets through one API still faces a single consolidated budget. The owner does not need to manually sum exposures across different venues or asset classes. Owners who want to understand the full risk picture should review risk management for a first-time trading agent before setting these numbers. Trading can lose money, including everything, and these limits exist to bound that loss rather than prevent it. The dollar sizing abstraction also reduces the chance of decimal errors or unit confusion that have historically caused automated trading losses.

What happens when an agent tries to break a rule?

Rejection is the default response. The system does not log the violation and allow the next attempt to pass. It returns an error to the agent, and the order does not reach the market. If the owner sees repeated violations or a sudden market move, they can trigger the panic switch. The panic switch flattens positions and revokes the scoped key, cutting the agent off from further trading. This is a hard stop, not a request. The agent has no ability to delay or ignore it. The flattening operation is executed by the infrastructure, not by the agent, so it works even if the agent is unresponsive. Flattening means closing all open positions and canceling all open orders. Once the panic switch is thrown, the key is dead. The owner must create a new key and re-authorize it if they want to resume trading. This creates a clean break that prevents a confused agent from reopening risk while the owner is investigating. The design philosophy is that how guardrails keep AI trading agents from losing everything depends on mechanical enforcement, not trust. An agent that loses connectivity or starts behaving unpredictably should hit a wall, not a warning. The kill switch is owner-controlled and irreversible for the key it targets, which prevents a compromised system from talking its way back into access.

How do you test guardrails before going live?

Felix offers paper trading for testing the full policy stack. The agent operates against real market data, but orders are not executed with real money. This lets the owner observe how the agent behaves when it hits a budget cap, a position limit, or a scope restriction. Only after the owner explicitly authorizes a scoped key for live trading does the system send real orders. Many beginners make mistakes when they first let an AI agent trade, and paper trading is the safest place to discover them. Treat paper trading as a rehearsal for the enforcement layer, not just a backtest for the strategy. During paper trading, the owner should deliberately trigger rejections and test the panic switch to confirm that the agent handles errors gracefully. A strategy that fails to check error responses in paper trading will behave dangerously in live markets. Paper trading also reveals whether the agent respects the API's error responses. An agent that loops on a rejected order or retries with larger sizes is a hazard that must be fixed before going live. The owner should review logs during paper trading to confirm that the agent's reasoning process aligns with the guardrail outcomes. The transition to live trading requires a deliberate opt-in, so an agent cannot drift from simulation to real money without the owner noticing.

How does an exit plan fit into the guardrails?

An exit plan is a set of rules that tell the system when to close positions automatically. The owner can configure several conditions that run without the agent’s involvement.

• ·A stop level that closes the position if the market moves against it by a defined amount.
• ·A time-based exit that closes the position after a set duration.
• ·A profit target that triggers when a gain threshold is reached.

The guardrail engine evaluates these conditions independently of the agent. If the agent crashes or loses its connection, the exit plan still runs. This is important because an agent that cannot communicate should not hold open risk indefinitely. The owner defines the exit plan when creating the scoped key, and the system monitors it continuously. The exit plan is not a suggestion to the agent. It is an instruction to the infrastructure to close the position when the condition is met. This removes the risk that the agent will ignore a bad trade because of reasoning errors or overconfidence. Trading can lose money, including everything, and an exit plan is a way to cap the duration of that risk. It is most useful when the agent is meant to operate unattended for long periods. Exit plans can be combined with budget caps so that a single bad trade is caught by both the position limit and the exit rule. The redundancy is intentional. No single control should be the only thing standing between the agent and a large loss.