How the safety model behind LLM trading works

LLM-powered trading agents make decisions in natural language, but their safety cannot depend on the quality of those decisions alone. The safety model is built into the infrastructure layer: a non-custodial wallet, scoped API permissions, dollar-denominated order limits, and an owner-controlled kill switch. These constraints operate independently of the model's reasoning, so even if the agent misinterprets data or generates a harmful plan, the API refuses to execute actions that violate the owner's rules. This structural approach treats the LLM as an untrusted component inside a hardened boundary, which is the only way to deploy autonomous software with real money responsibly.

Why must safety be structural instead of relying on prompts alone?

Prompt engineering is a useful way to guide an agent's behavior, but it is not a reliable enforcement mechanism. Large language models are probabilistic systems that can hallucinate, misinterpret instructions, or be manipulated through creative prompting. If the only thing preventing an agent from placing a reckless trade is a sentence in the system prompt, then the safety boundary is soft and easily bypassed. An attacker who gains access to the agent's context window or input stream might reframe the objective, and a confused model might simply ignore a buried instruction during a long reasoning chain.

Structural safety moves the enforcement out of the model's context window and into the API gateway that sits between the agent and the market. Every order generated by the agent is validated against hard constraints before it reaches a venue. If the agent requests a trade that exceeds its budget cap, targets a disallowed market, or attempts a withdrawal, the API rejects the request regardless of how cleverly the prompt was written. This separation of concerns follows a standard security principle: the policy decision point should not reside inside the component being controlled. Felix agents connect through MCP tools or the REST API, and both pathways route through the same enforcement layer. The agent proposes, the infrastructure disposes, and the owner retains the final authority.

How does non-custodial architecture remove theft risk?

In a custodial setup, an agent or service holds funds on the owner's behalf, which means a compromised agent could potentially transfer assets to an attacker. Felix is non-custodial by construction. Funds remain in a wallet that the owner controls, and the agent receives only a scoped key that permits trading within predefined limits. The agent can spend money to open and close positions, but it cannot withdraw funds to itself or to any external address. Withdrawal addresses are approved by the owner during setup and cannot be modified by the agent.

This means that even if the agent's environment is fully compromised, the attacker's capability is bounded by the trading permissions of the key. The worst-case scenario is the loss of the budget allocated to that agent, not the loss of the entire wallet. This distinction is important because trading can lose money, including the entire allocated budget, but the owner retains custody of the remaining capital. The architecture assumes that the agent itself is a potential threat vector, and it designs the permission system accordingly. How to control the risks of non-custodial trading with real money explains this custody model in more detail.

What controls keep an agent within its budget?

Budget enforcement is the most direct way to limit the damage from a misbehaving agent. The Felix safety model provides several overlapping controls that work together:

• ·Spend caps limit how much capital the agent can deploy over a given time period.
• ·Drawdown limits trigger an automatic halt if the account value falls by a specified amount.
• ·Position limits restrict the size of any single trade or the total exposure across all markets.
• ·Exit plans are pre-configured rules that close positions when certain conditions are met, such as a target loss level or a time-based expiration.

These limits are set by the owner before the agent starts and are stored in the API layer, not in the agent's memory. Because the API tracks running totals of executed orders and open positions, the agent cannot simply restart the conversation to reset its budget. Once a cap is reached, subsequent orders are rejected until the owner adjusts the limit. This is not a warning or a suggestion; it is a hard stop enforced by the infrastructure. The owner can make the limits as tight or as loose as their risk appetite allows, but the agent has no mechanism to override them. How developers should set spend caps and drawdown limits for trading agents in 2026 offers practical guidance on choosing these values.

How do scoped keys and kill switches limit blast radius?

A scoped key is an API credential that carries its own permissions, so the agent does not need full account access. One key might authorize trading in stocks and crypto while prohibiting options, perps, or prediction markets. Another key might allow trading but block withdrawals entirely. Because the API enforces these scopes, the LLM never sees or controls them. Even if an attacker tricks the agent into requesting a withdrawal or a prohibited trade, the API rejects the action. This limits the blast radius of a single compromised key or a single bad model output.

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

{
  "key_label": "YOUR_KEY_NAME",
  "budget": {
    "daily_usd": 500
  },
  "markets": ["stocks", "crypto"],
  "can_withdraw": false
}

The panic or kill switch is a separate manual control that the owner can trigger at any time. When activated, it immediately flattens open positions and revokes the agent's key. This does not depend on the agent's cooperation or on the model's reasoning. It operates directly on the infrastructure layer, so it works even if the agent is stuck in a loop or has been hijacked. The owner can also revoke the key through standard credential management without waiting for external support. This combination of narrow scopes and instant revocation means that no single failure can expose the full account. How the safety model for MCP trading tools works from first principles covers this layer in more depth.

Why does dollar sizing reduce complexity errors?

Trading venues use incompatible contract specifications. A stock broker might trade in whole shares, a crypto venue in decimal token amounts, a perps venue in contract units with leverage multipliers, and an options venue in lots of one hundred. If an LLM reasons directly in these native units, it must perform conversions correctly on every single order. A mistake in decimal places, leverage ratios, or lot sizing can produce an order that is ten times too large or ten times too small. In some cases, the error might be in the agent's favor, but the risk of an oversized loss is unacceptable.

Felix removes this risk by accepting orders in plain US dollars. The agent reasons in dollars, and the API normalizes the order into the correct venue-specific units. This reduces the cognitive load on the model and eliminates a large class of arithmetic errors. The agent does not need to know how a perps venue calculates notional value or how an options venue structures premiums. It simply specifies the desired dollar exposure, and the infrastructure handles the rest. This simplification is not merely a convenience; it is a safety feature because it removes a common source of agent error. How to size orders in dollars when building a trading agent walks through this approach.

How should developers validate a safety model before going live?

Before an agent handles real capital, its safety constraints should be tested in paper trading. Paper trading uses the same API paths, the same scoped keys, and the same budget logic as live mode, but execution is simulated. This lets developers observe how the agent behaves when it hits a budget cap, receives a rejection, or attempts an out-of-scope action. It is also the right time to test the kill switch and confirm that revocation works as expected. The agent should handle rejection responses gracefully rather than retrying aggressively or switching to a different strategy that circumvents the limit.

Only after the owner has reviewed the agent's behavior and explicitly authorized a live key should the agent trade real money. This authorization step is a deliberate human gate that prevents accidental deployment. Developers should start with narrow scopes and small budgets, then expand permissions gradually as confidence grows. Trading can lose money, including the entire budget allocated to the agent, so starting small is not just cautious; it is a structural part of the safety model. The transition from paper to live should be treated as a release process, complete with checklists and rollback plans, rather than a simple toggle switch.