How a single API keeps AI trading agents safe across every market

A single API that lets an AI agent trade stocks, crypto, perpetual futures, options, and prediction markets does not require the owner to give up control of their funds. Felix keeps the safety model non-custodial by construction, so the agent receives scoped keys that can place orders but cannot withdraw capital or move it to an unapproved address. Every limit, from budget caps to position sizing, is enforced by the infrastructure rather than by the agent's own logic, which means the owner retains the wallet while the agent operates inside hard boundaries it cannot negotiate or override.

Why does one API for every market change the trust model?

In a fragmented setup, a trader might hold separate accounts at a stock broker, a crypto exchange, a perps venue, an options venue, and a prediction market. Each account has its own credentials, its own interface, and its own risk profile. The trader naturally compartmentalizes risk because a breach at one venue does not automatically extend to the others. Consolidating access into one API removes that natural isolation. If a single key can reach every market, the safety model must be stricter than the sum of its parts, because a compromised agent or a misconfigured strategy could now touch multiple asset classes at once.

The API normalizes venue-specific contract math by sizing orders in plain US dollars. A developer does not need to manage tick sizes, lot sizes, or margin formulas across different venues. But this convenience also means the safety layer must normalize risk controls. A position limit on a stock is not the same as a position limit on a perpetual future, yet the API must enforce both with the same rigor. The trust model shifts from trusting individual venues to trusting the infrastructure that sits between the agent and those venues. That infrastructure becomes the single point of failure if it is not built with conservative defaults and transparent limits.

This is why the safety model is built as a perimeter, not as a suggestion. The agent does not decide whether it is safe to trade. The owner sets the perimeter before the agent starts, and the API rejects any order that crosses it. Trading can lose money, including everything, but the safety model ensures that losses are bounded by the limits the owner chose, not by the agent's autonomy. The agent may still make bad trades, but it cannot make trades that the owner explicitly forbade.

How does non-custodial architecture keep funds out of the agent's reach?

Non-custodial by construction means that funds sit in a wallet the owner controls, and the agent can only spend within limits that the owner defines. The agent receives a scoped key that authorizes trading actions, but the key cannot initiate a withdrawal to itself or to any address that the owner has not explicitly approved. This is a structural restriction, not a policy or a promise. Even if the agent's logic is hijacked, or if an LLM hallucinates a command, the key simply lacks the permission to move funds out of the owner's control. The architecture guarantees this by separating trading capabilities from fund movement capabilities at the key level. There is no backdoor that lets the agent escalate its privileges.

This matters because AI agents are not perfect. They can misinterpret prompts, loop on bad logic, or be influenced by manipulated data. If the agent held custody of the funds, these failures could result in total loss. Under the Felix model, the worst-case scenario is that the agent deploys its entire allocated budget inside the trading perimeter. It cannot drain the wallet, transfer funds to a third party, or change the withdrawal whitelist. The owner retains full custody, and the agent retains only the ability to trade within its cage. How a Claude trading agent trades without taking custody of your funds

The owner approves withdrawal addresses independently of the trading key. This separation of concerns is standard in secure system design. The trading key is a capability that grants limited authority, while the wallet itself remains under the owner's private key or hardware security module. When the agent needs to rebalance or exit, it does so within the trading venues. If the owner wants to withdraw profits, they do so with their own credentials, not through the agent. The agent never sees the owner's main private key, and it cannot reconstruct it from the scoped key it holds.

What controls stop an agent from overspending or overleveraging?

The primary controls are budget caps, position limits, drawdown limits, and exit plans. A budget cap is a hard ceiling on the total US dollars the agent can deploy across all markets. This cap is enforced at the API level, so the agent cannot exceed it by opening a new position in a different market or by splitting orders across venues. The API tracks the running total and rejects any order that would push the agent over its limit. The agent does not get to argue with the limit. It is a hard boundary written into the infrastructure. How to set spend caps and drawdown limits for trading agents

Position limits prevent concentration. An owner can set a maximum size for any single instrument, or for an entire asset class. This is useful because an agent might develop a strong signal for a specific market and keep adding exposure. Without a position limit, that concentration could overwhelm the portfolio if the signal turns out to be wrong. The limit acts as a circuit breaker on the agent's own confidence. It also protects against accidental duplication, where an agent might submit the same order twice through different paths.

Exit plans automate the close of a position when conditions are met. A stop-loss limits the damage on a losing trade, while a take-profit locks in gains. These rules are attached to the position at the infrastructure level, so the agent does not need to be online or attentive when the trigger is hit. How to automate exit plans and take-profit rules for an AI trading agent Because the agent does not control the exit plan logic, it cannot rationalize its way into holding a losing position past the owner's tolerance. The infrastructure closes the trade and updates the available budget.

Drawdown limits halt trading when the account level falls by a predetermined amount. Unlike a stop-loss on a single trade, a drawdown limit protects the entire allocated budget. Once triggered, the API refuses new orders until the owner manually reauthorizes the agent. This prevents a runaway strategy from chewing through capital while the owner is away. The drawdown limit is especially important for agents that trade across multiple markets, because a correlated drop in several positions could otherwise exhaust the budget faster than a human can react.

How does a kill switch work when the agent connects through MCP?

The kill switch is a panic mechanism that flattens open positions and revokes the agent's API access. It is owner-controlled and built into the infrastructure, so the agent cannot override it, disable it, or delay it. Whether the agent connects through MCP tools in Claude, Cursor, or another client, or through the REST API directly, the kill switch operates the same way. It targets the key, not the client. The agent could be running on a local laptop or a cloud server, and the kill switch would still sever its trading authority immediately. How to build a kill switch your trading agent cannot override

When the owner triggers the switch, the system first attempts to cancel open orders and flatten any open positions. It then disables the scoped key. The agent may still be running on the user's machine or in the cloud, but it has no authority to place new orders. This is important because simply stopping the agent process is not always reliable. The agent might be on a remote server, or it might be part of a multi-step workflow that restarts automatically. Revoking the key is the only way to guarantee silence. The process is irreversible from the agent's side.

Some owners configure automated kill conditions. For example, a drawdown limit might trigger the kill switch without human intervention. This removes the emotional delay that can occur when an owner watches losses accumulate and hesitates to act. The switch is binary. Once thrown, the agent is locked out until the owner generates a new scoped key and explicitly reauthorizes it. The owner must consciously decide to restore access, which prevents an agent from recovering on its own after a failure.

Testing the kill switch in paper trading is essential before live deployment. The owner should verify that positions are flattened quickly and that the key is truly dead. Paper trading exists for testing; live trading requires explicit owner authorization of a key. The test should simulate not just a calm market, but also a volatile one, because the speed of flattening can vary with liquidity. An owner who has tested the switch knows what to expect, and that knowledge reduces panic during real emergencies.

What should a developer verify before authorizing live trading?

Before moving from paper to live trading, a developer should verify several configuration details that prevent unintended exposure. A systematic checklist reduces the chance of a human error that exposes capital to risks the owner never intended to take.

1. 01Check that the key scope is limited to trading only, with withdrawals explicitly disabled.
2. 02Confirm that budget caps and position limits are set to conservative values appropriate for the strategy.
3. 03Test the kill switch in paper trading to verify it flattens positions and revokes the key completely.
4. 04Review exit plan logic for stop-loss and take-profit levels across different market conditions.
5. 05Verify that the wallet holding funds is secured independently of the agent with hardware or multisig.

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

{
  "key": "YOUR_KEY",
  "scope": "trade_only",
  "budget_usd": 5000,
  "position_limit_usd": 1000,
  "allow_withdrawal": false,
  "kill_switch_endpoint": "owner-controlled-url"
}

This illustration shows how the configuration bundles the safety controls into the key itself. The infrastructure reads these fields before accepting any order. If the agent tries to place a trade that exceeds the position limit, the API returns an error before the order reaches a venue. The developer does not need to trust the agent to respect the limit, because the API enforces it mechanically.

Developers should also review the exit plan logic. A stop-loss that is too tight might stop out on normal volatility, while one that is too loose might allow unacceptable losses. The same applies to take-profit levels. These parameters should be tested in paper trading across multiple market conditions, not just backtested on historical data. Paper trading lets the agent interact with the real API and its safety controls, but without real money at stake. Only after the agent behaves predictably under these constraints should the owner authorize live trading.

Finally, the owner should confirm that the wallet holding the funds is secured with hardware or multisig, depending on the amount of capital. The scoped key is only as safe as the wallet it draws from. If the owner loses control of the wallet, the agent's safety model becomes irrelevant. The non-custodial design protects against agent failure, but it does not protect against owner negligence. Trading can lose money, including everything, so the wallet that holds the remaining capital must be treated with the same care as the trading logic.