The architecture that keeps AI trading agents secure in 2026

The security of an AI trading agent in 2026 does not depend on trusting the agent. It depends on an architecture that treats the agent as a potentially compromised process and constrains every action it can take. The Felix infrastructure keeps owner funds safe by combining non-custodial wallet control, cryptographically scoped keys, hard budget caps, and a panic switch that can flatten positions and revoke access instantly. Trading can still lose money, including the entire budget allocated to the agent, but the architecture prevents the agent from stealing funds or exceeding the owner's explicit limits.

What does non-custodial by construction mean for an agent?

In a non-custodial architecture, the owner retains control of the private keys that hold the funds. The agent receives an API key that lets it submit orders, but that key does not grant ownership of the underlying wallet. This means the agent can spend within the limits set by the owner, yet it cannot withdraw funds to an address the owner has not pre-approved. Withdrawal addresses are owner-approved only, and changing them requires a separate authorization flow that the agent key cannot satisfy.

This design removes the single greatest risk in automated trading: the custodial temptation to pool funds under a platform's control. Because the wallet belongs to the owner, the agent is reduced to a delegated operator. Even if the agent's environment is fully compromised, the attacker cannot sweep the wallet. They can only place trades within the scoped budget, and those trades are further constrained by the position and budget limits we describe below.

The non-custodial property is enforced by the protocol, not by policy. The API key is a distinct credential from the wallet key. The infrastructure signs transactions on behalf of the owner only after verifying that the request falls within the key's scope and the owner's guardrails. The owner can revoke the API key at any time without moving funds or rotating wallet addresses. This separation of duties is the foundation of the security model.

For developers, this means the integration path does not require depositing funds into a new account controlled by a third party. The owner connects an existing wallet, sets spend permissions, and issues a scoped key. The agent then operates against the API, but the settlement layer remains under the owner's direct control. If the agent is disconnected, the funds stay exactly where they are. There is no withdrawal queue, no bridge delay, and no counterparty risk introduced by the infrastructure itself. Trading can still lose money through market movements, but it cannot lose money through infrastructure theft.

How do scoped keys limit what an agent can do?

Scoped keys are the primary mechanism for enforcing least privilege. When an owner creates an API key for an agent, they define what markets it can access, what order types it can submit, and what budget it can deploy. A key scoped to a stock broker and a perps venue cannot touch options or prediction markets. A key scoped to read-only cannot place orders at all. These restrictions are encoded into the key material and enforced by the infrastructure on every request.

This matters because AI agents run in environments that are difficult to secure. An agent might execute inside a Claude or Cursor session, or via a REST call from a server that could be exposed to the public internet. If the key leaks, the blast radius is limited to the scope. An attacker who finds a read-only key gains nothing but stale prices. An attacker who finds a trading key can only trade within the approved markets and budget. They cannot withdraw, they cannot change scopes, and they cannot escalate privileges.

We cover the practical steps in how to build scoped API keys for a trading agent step by step. The important architectural point is that scopes are not checked by the agent. They are checked by the API gateway before the request ever reaches a venue. The agent can hallucinate a request to buy a million dollars of an option, but the gateway will reject it if the key lacks the market scope or the budget cap is lower. The enforcement is cryptographic and deterministic, not probabilistic.

Scopes also make auditing straightforward. Every request carries the key identity, so the owner can see exactly which agent attempted which action. If an agent is misbehaving, the owner can revoke that specific key without rotating the wallet or disabling other agents. This granularity reduces the operational friction of running multiple strategies in parallel.

Why are hard limits and kill switches the last line of defense?

Budget caps and position limits are hard walls, not guidelines. The owner sets a maximum dollar amount the agent can commit to open positions. Once that cap is reached, the API rejects new orders that would increase exposure. The limit is calculated in real time across all venues the key touches, so an agent cannot evade the cap by splitting orders between a stock broker and a crypto venue. This unified accounting is essential because agents can trade across five market types from a single key.

Position sizing is another layer. How position sizing protects owner funds from agent error explains the owner-side logic, but the architecture enforces it at the protocol level. The API normalizes every order into a plain US dollar notional value before checking it against the limit. Whether the agent is trading shares, perpetual contracts, or prediction market positions, the infrastructure converts the venue-specific contract size into a comparable dollar figure. The agent does not need to know the conversion math, which removes an entire class of sizing errors.

The kill switch is the final circuit breaker. When triggered, it flattens open positions and revokes the API key immediately. Flattening means submitting offsetting orders to close exposure, not liquidating into a market order if that would cause excessive slippage. The exact mechanics depend on the venue and position size, but the goal is to return the portfolio to neutral and sever the agent's access. The owner can trigger the switch manually, and some configurations allow automated triggers based on drawdown thresholds. Trading can lose money rapidly, and a kill switch cannot guarantee a specific loss floor, but it can prevent an unattended agent from compounding a bad position over hours or days.

How does the API normalize risk across five market types?

One key, one API, five market types. That simplicity is intentional, but it hides a significant normalization layer. Each venue speaks a different dialect: lot sizes for stocks, contract multipliers for options, leverage tiers for perps, and outcome shares for prediction markets. If the agent had to manage these conversions, it would be a source of constant risk. The Felix API accepts orders in plain US dollars and normalizes the venue-specific math on the back end.

For example, suppose an agent wants to allocate five hundred dollars to a position. It sends an order with a notional value of five hundred. The infrastructure translates that into the correct number of shares, contracts, or shares depending on the venue and the current price. The agent never sees the contract math. This means an agent written for one market type can reason about another market type in the same terms. The risk of misplacing a decimal, misunderstanding a tick size, or miscalculating leverage is borne by the infrastructure, not the agent.

This normalization also makes unified risk limits possible. The budget cap is a single dollar number. The position limit is a single dollar number. The API aggregates exposure across a stock broker, a crypto venue, a perps venue, an options venue, and a prediction market into one coherent balance sheet. The agent cannot hide risk in a complex instrument because the infrastructure sees the economic exposure in common terms. The owner sets one number, and the architecture enforces it everywhere.

For developers, this means the integration surface is small. An agent that can trade stocks can, with a scope change, trade prediction markets without rewriting its sizing logic. The API contract remains the same. The security properties remain the same. The only change is the market scope on the key.

What does the owner need to authorize before live trading?

Paper trading exists for testing. Every agent should run in paper mode while its logic, prompt engineering, and error handling are validated. Paper trading uses the same API paths and the same scope checks, but it executes against simulated liquidity. This means the owner can observe how the agent respects budget caps and position limits without risking capital. When the owner is ready to trade real money, they must explicitly authorize a key for live trading.

This authorization is a deliberate human gate. It requires the owner to confirm the key scope, the budget cap, the approved withdrawal addresses, and the kill switch configuration. The infrastructure records this authorization immutably. If an agent attempts live trading before the key is authorized, the request is rejected regardless of the agent's intent. The agent cannot self-authorize. Even if the agent is running inside an AI code editor with full MCP access, it cannot bypass the owner's explicit opt-in.

We discuss the broader transition in what it takes to move an AI trading agent to live trading in 2026. The architectural principle is that live money should never be accessible by default. The default state is deny. The owner must construct a positive authorization chain: wallet connected, scopes defined, limits set, and live flag toggled. Each step is independently verifiable. This prevents the common mistake of an agent accidentally touching production markets during a test session. It also ensures that if an agent is cloned or its key is regenerated, the new key starts in a safe, unauthorized state.

How does the architecture assume the agent is already compromised?

Defense in depth only works if every layer is designed to hold when the others fail. The Felix architecture assumes the agent is already compromised. It assumes the MCP client or the REST server is running on a machine with malware. It assumes the LLM prompt has been jailbroken. It assumes the API key has been leaked to a public channel. Under these assumptions, the security model still protects owner funds.

The reason this holds is that the trust boundary is not the agent. The trust boundary is the API gateway and the non-custodial wallet. The agent can ask for anything, but the gateway checks the key scope, the budget cap, the position limit, and the live authorization on every request. The wallet can only move funds to owner-approved addresses, and the API key cannot change those addresses. Even a fully compromised agent is trapped inside a cage of hard constraints.

This is why the architecture treats prompts as untrusted. A prompt is a request, not a rule. The actual rules are the scopes and limits encoded in the key and the owner's configuration. The agent can generate a malicious strategy, but it cannot execute a strategy that violates the guardrails. The owner remains in control. Trading can still lose money within the approved budget, and the owner must monitor and adjust limits as market conditions change. The architecture does not eliminate trading risk. It eliminates infrastructure risk and keeps the trading risk where it belongs: inside the owner's explicitly bounded intent. The architecture applies whether the agent connects through MCP tools or the REST API, as described in how a single API keeps an AI trading agent safe inside a code editor.