How Felix keeps agents safe while reading live order books

When an AI agent reads a live order book with real money at stake, the safety model must guarantee that seeing prices never becomes spending money without limits. Felix handles this by separating read access from execution authority, wrapping both in scoped keys that the owner controls. The agent can observe bids and asks across stocks, crypto, perps, options, and prediction markets, but every order it might later place is bounded by pre-approved budgets, position limits, and a kill switch that the owner can trigger at any time. Funds remain in a wallet the owner controls, and the agent cannot withdraw them to itself or any external address that the owner has not explicitly approved.

What does it mean when an AI agent reads a live order book?

When an AI agent reads a live order book, it is doing the same thing a human trader does when they glance at a depth chart. It is ingesting a list of bids and asks, along with sizes and sometimes order history, to build a model of where supply and demand currently meet. For an agent, this is a continuous loop: read the book, update internal state, decide whether to act, and then perhaps read again. Felix treats this loop as a privileged operation because the agent will use this data to form intent, but the act of reading itself does not move money. Felix normalizes order book data across five market types so the agent sees a consistent structure. Whether the agent is connected to a stock broker, a crypto venue, a perps venue, an options venue, or a prediction market, the shape of the data is similar. The agent does not need to parse venue-specific contract sizes, tick increments, or margin notation. The API returns plain USD-denominated values where possible, so the agent reasons in dollars rather than in native units. This reduces one class of error where an agent miscalculates size because it misunderstood a contract multiplier. However, reading a live book is not risk-free in the broader sense. The book can change between the read and the order. The data can be stale, crossed, or show anomalous depth if a venue experiences low liquidity or a technical glitch. Felix does not validate whether the prices are fair or correct; it normalizes and delivers what the venue publishes. The safety model therefore assumes that data can be wrong and places limits on what the agent can do in response. A human trader might misread a screen and place a bad trade. An agent might do the same at machine speed, repeating the error across multiple markets. The controls are designed to limit the consequences of such misreads. Trading can lose money, including everything, and reading a book does not change that underlying risk.

How does Felix separate data access from settlement risk?

Felix splits the agent's interaction into two distinct planes: the data plane and the execution plane. Reading an order book happens on the data plane. The agent asks for a snapshot or a stream of bids and asks, and the API returns normalized market data. This operation does not touch the wallet. It does not reserve funds. It does not create a liability. It is observation, and the scoped key used for this operation can be configured to permit nothing else. Execution happens on a separate plane. When the agent decides to trade, it must use a different scope or a constrained key that permits order placement. Even then, the order is not an open-ended instruction. The owner pre-defines a budget cap, a maximum position size, and approved trading markets. The agent can spend only within that envelope. If the agent has read an order book and decides to buy, the order is checked against the remaining budget and position limit before it is forwarded to the venue. If the order would exceed either limit, the API rejects it. The wallet itself is non-custodial by construction. The owner holds the keys to the wallet. The agent receives an API key that can sign orders within the configured limits, but it cannot construct a withdrawal transaction to an unapproved address. It cannot move funds to itself. It cannot escalate its own permissions or request a larger budget. This means that even if the agent's logic is compromised, or if a prompt injection causes it to hallucinate a trading strategy, the funds cannot be stolen through the API. The worst-case scenario is losing the budget allocated to that scoped key, not the entire wallet balance. The owner can revoke the key at any time, which immediately stops both reading and trading. This separation is important because many traditional trading APIs conflate data access with trading access. A single credential might allow reading books, placing orders, and withdrawing funds. Felix breaks these apart so that the owner can grant the agent read access today, trade access tomorrow, and revoke either independently without affecting the other. A practical checklist for non-custodial AI trading covers how to set these scopes in practice.

Why are scoped keys safer than giving an agent direct exchange credentials?

Direct exchange credentials are often all-or-nothing. They might bundle market data, trading, and withdrawal permissions into one long-lived secret. If an agent holds that secret, a bug in the agent's reasoning, a misinterpretation of the book, or a prompt injection can cause immediate harm. Felix replaces this model with scoped keys that carry only the permissions the owner explicitly grants, and only for the markets the owner selects. A read-only scoped key lets the agent poll order books without any ability to place orders. This is useful for monitoring, signal generation, or running paper trading logic against live data. An execution-scoped key can place orders, but it carries additional constraints such as a notional budget cap, a whitelist of markets, and a maximum position size. There is no key that grants both unlimited trading and unlimited withdrawals. The owner must approve withdrawal addresses separately, and the agent cannot add new ones through the API. If the agent is an MCP client connected through Claude, Cursor, or another MCP host, the tools it can call are limited by the scope of the key injected into its environment. The agent cannot escalate beyond the tools provided. For example, if the environment only exposes read_order_book and place_limited_order, the agent cannot call a raw withdrawal endpoint. The API simply rejects requests outside the scope. The enforcement happens on the server side, not inside the agent's own code, so a compromised agent cannot bypass it by rewriting its own prompt. The exact MCP schema is in the docs; the shape looks like this:

{
  "tool": "read_order_book",
  "arguments": {
    "market": "...",
    "depth": 10
  }
}

Even if the agent constructs a malformed request or attempts to spoof a different tool name, the API evaluates it against the key's scope. A read-only key will never execute a trade. This is enforced server-side, not by the agent's own code. How to control the risks of non-custodial trading with real money explains how to set these limits before going live.

What controls prevent an agent from acting on stale or manipulated book data?

Market data is not guaranteed to be correct. An order book can become stale during volatile periods, especially if the connection to a venue lags. A single venue can show anomalous prices due to low liquidity, a fat-finger order, or intentional manipulation. Felix does not promise to filter all bad data, and no safety model can eliminate the risk that an agent will act on a false signal. The controls are designed to limit the damage, not to guarantee perfect data. First, the agent's orders are sized in plain USD. The API normalizes venue-specific contract math so the agent does not accidentally request ten thousand contracts when it meant ten thousand dollars. This removes a common source of oversized orders that can arise when an agent misreads a tick size or lot convention. Second, every execution key carries a hard budget cap. Once the agent has spent that budget, it cannot place further orders until the owner resets or increases the cap. A misread book might trigger one bad trade, but it cannot trigger an unlimited sequence of escalating losses. Third, position limits restrict how large any single position can become. Even if the agent repeatedly buys in response to a static book it believes is moving, the limit stops the accumulation. Fourth, rate limits on order placement prevent the agent from spamming the venue in a tight loop. These limits are independent of the data feed. The agent might read the book a thousand times a second, but it can only place orders at a rate that the owner has pre-approved. Finally, the owner should test the agent's data pipeline thoroughly before authorizing live trading. How to build a market data pipeline for your first trading agent offers a step-by-step guide. Paper trading exists for exactly this reason: the agent can read books and simulate orders without touching real money. When the owner does authorize a live key, it should be done with explicit intent and a clear understanding that trading can lose money, including everything.

How does the panic switch work when the book moves unexpectedly?

Markets can gap. An order book that looked calm one second can gap violently the next. If the agent is reading the book and executing on every update, it might accumulate unwanted exposure before the owner notices. Felix includes a panic switch, sometimes called a kill switch, that the owner can trigger at any time. The agent cannot override it. When activated, the switch performs two actions in sequence. It first flattens or attempts to flatten open positions according to a pre-defined exit plan. It then revokes the agent's API key, cutting off all read and write access immediately. The agent cannot stop this process. The agent cannot revoke the revocation. The key is dead, and the agent must stop. The owner retains full control of the wallet throughout. This is possible because the safety model is non-custodial but owner-controlled. The owner holds the wallet, but the owner also holds the override. The agent is a delegate with limited powers. The panic switch is the final assertion of that hierarchy. How to build a kill switch your trading agent cannot override describes how to wire this into your system. Audit logs record every book read, every order attempt, and every switch trigger. If the book moved unexpectedly, the logs will show the exact prices the agent observed and the exact orders that followed. This observability is part of the safety model, because an agent that cannot be audited cannot be trusted with real money.

What should a developer test before letting an agent read live books?

Developers should begin in paper trading. The agent can read live or simulated books and place simulated orders. This tests the data pipeline, the reasoning loop, and the safety controls without risking capital. Common mistakes include assuming that a paper trading stream behaves exactly like a live book, or forgetting to enforce the same rate limits in simulation. Before going live, verify that the scoped key is truly limited. Attempt to place an order that exceeds the budget and confirm it is rejected. Attempt to read a book with a read-only key and confirm that trading is blocked. Test the kill switch manually and measure how long it takes to revoke access. Review the audit logs to ensure that every read and write is recorded with a timestamp and a key identifier. Live trading requires explicit owner authorization of a key. This is a deliberate gate, not an accidental toggle. The owner must understand that the agent will have real money at its disposal, within the configured limits. Those limits should be set conservatively for the first live deployment. An agent that reads five market types does not need full access to all of them on day one. Start with one market, a small budget, and a tight position limit. Expand only after the logs show stable, expected behavior over a meaningful period. Remember that trading can lose money, including everything, and no amount of testing can remove that risk.