How the Felix architecture keeps AI trading agents secure

AI trading agents on Felix are secured by a non-custodial architecture that separates trade execution from fund custody. The owner keeps control of the wallet, while the agent receives scoped permissions that allow it to place orders but never to withdraw funds or change withdrawal addresses. Programmable limits on budgets, position sizes, and market exposure act as guardrails, and a kill switch can revoke access instantly if the owner needs to stop trading. Trading can lose money, including the full amount allocated, and these controls do not eliminate market risk.

What does non-custodial mean for an AI agent?

Non-custodial architecture means that the funds remain in a wallet the owner controls, rather than being deposited into an account managed by a trading platform or the agent itself. When you set up an agent through Felix, you do not send your capital to a pooled custodial account. Instead, you authorize a specific wallet to execute trades through the API while retaining sole ownership of the underlying assets. The agent receives a scoped key that permits trading activity, but the key is mathematically incapable of initiating a withdrawal to any address that you have not pre-approved.

• ·The owner retains the wallet's private keys and seed phrase.
• ·The agent receives a scoped key that can trade but cannot withdraw.
• ·Withdrawal addresses are whitelisted by the owner and cannot be altered by the agent.
• ·Compromising the agent does not grant access to the underlying wallet funds.

For many beginners, the idea of an AI trading agent evokes images of handing capital to a black box. The non-custodial architecture makes this image inaccurate. You connect a wallet that you already own, secured by a hardware device or software, and grant the API a narrow spending mandate. You do not share your wallet's master seed phrase with the agent. You do not deposit funds into an API-controlled account. The agent can only spend what the mandate allows, and the mandate can be revoked at the wallet level. This two-layer defense, API scoped keys plus wallet-level controls, means that compromising the agent gives an attacker very little. They would need to compromise both the agent's key and the wallet's underlying security to access your capital. This is a significant improvement over traditional custodial trading accounts.

How do scoped keys limit what an agent can do?

Scoped keys are API credentials that carry only the permissions you assign, following the principle of least privilege. Instead of giving your agent a master key that could trade, withdraw, or reconfigure account settings, you create a key that is restricted to a narrow set of actions. For example, you might allow the agent to open long positions in stocks and perps, but not to trade options, or you might allow it to trade crypto but only within a maximum order size of one hundred dollars. The key is bound to these constraints at the infrastructure level, so the agent cannot bypass them by writing a clever prompt or exploiting a loophole in its instructions. If the key is exposed in a log file, a compromised MCP client, or a leaked environment variable, the attacker gains only the limited abilities embedded in that key.

You can also apply time-bound restrictions to a key. If you want to test a new approach for one week, you can create a key that expires automatically. If you run multiple agents, you can issue separate keys for each and isolate them. If one key is compromised, you delete it without affecting the others. This granularity is difficult to achieve with traditional exchange API keys, which often grant broad account access. The scoped key system is designed for automation, where keys may be stored in environment variables or passed through MCP servers. By limiting what each key can do, you reduce the chance that a small configuration error leads to a large loss. How to run a non-custodial trading agent through MCP: a practical checklist

What happens when an agent reaches a budget cap or position limit?

The system enforces hard limits at the API level, which means the agent is physically blocked from executing orders that exceed your predefined boundaries. A budget cap is a ceiling on the total amount of capital the agent is allowed to deploy. Once the agent has entered positions that sum to that cap, any additional order is rejected before it reaches the market. Position limits work similarly, but they constrain concentration. You might set a rule that no single position can exceed five percent of the allocated budget, or that the agent cannot hold more than three correlated positions at once. These checks run independently of the agent's reasoning. If the LLM decides that an opportunity is compelling and tries to size up aggressively, the API normalizes the request and rejects it if it breaches the limit.

Manual traders sometimes rely on discipline to enforce limits. An agent operating at machine speed does not have that luxury. It can place dozens of orders in the time it takes a person to read a chart. Hard limits exist because discipline is not fast enough to catch an agent that has misinterpreted a signal. The API acts as a referee that enforces the rules in real time. This is why agent trading with hard limits differs from manual trading. The limits are not a crutch for weak strategy. They are a structural acknowledgment that agents can act faster than owners can react, and that speed requires mechanical boundaries. Common position sizing mistakes when letting an AI agent trade real money

How does the kill switch protect owner funds?

The kill switch is a panic mechanism that lets you halt an agent immediately and flatten its exposure. When you trigger it, the system attempts to close open positions and then revokes the agent's API key, severing its connection to every market. This happens in seconds, not hours, and it does not require you to manually cancel orders across multiple venues. Because the key is scoped, revocation is final. The agent cannot use the same credential to reconnect, and it cannot trade while you are asleep or away from your desk. The kill switch is designed for situations where you observe behavior you do not understand, where market conditions change faster than your strategy can adapt, or where you simply want to pause trading to reconsider your limits.

After the kill switch is activated, the owner receives a summary of the agent's final positions and revocation status. There is no ambiguity about whether the agent is still active. The owner can then withdraw the remaining budget to a cold wallet, or reauthorize a new key after fixing the issue. The kill switch is not hidden in advanced settings. It is a first-class control because the designers assumed that owners will need to stop agents quickly. That assumption shapes the entire architecture. Safety is not an afterthought. It is a core functional requirement that determines how keys are issued, how orders are validated, and how sessions are terminated.

Why does plain-dollar sizing reduce risk?

A surprising source of risk in automated trading is unit confusion. Different venues express order size in contracts, lots, tokens, or other units that do not map directly to the dollar amount you intend to risk. Felix normalizes this by accepting orders in plain US dollars. When you tell the agent to trade one hundred dollars worth of an asset, the API handles the conversion to the venue's native unit size. This removes a class of errors where an agent might submit an order that is ten, one hundred, or one thousand times larger than intended because it miscalculated a multiplier or decimal place.

Cross-market consistency is especially valuable for multi-market agents. If your agent trades both stocks and crypto, you do not need to maintain two different sizing models in its prompt. You tell it to risk one hundred dollars, and the same logic applies whether it is buying shares or entering a perps position. This prevents the agent from confusing notional value with margin requirements. The API handles the translation, and the owner retains a single, unified view of risk in dollars. This abstraction reduces cognitive load on both the agent and the owner, which reduces the chance of a sizing error that breaches your budget cap.

How does the API act as a safety layer between the agent and the market?

The Felix API sits between the agent's decision logic and the actual trading venues. It functions as an enforcement layer, not merely a pipe. When the agent generates an order, the API inspects the request against the owner-defined constraints before it forwards anything. It checks the scoped key's permissions, the remaining budget, the position limits, and the plain-dollar sizing. If any constraint is violated, the API rejects the order and returns an error to the agent. The agent can then adjust its plan, but it cannot override the rejection. This means that even if the agent's reasoning is flawed, the infrastructure prevents the flaw from reaching the market.

When the API rejects an order, the agent receives a structured error rather than a silent failure. A well-designed agent can interpret this error and adjust its next action. For example, if the agent tries to double a position and hits the limit, it might receive a message indicating that the cap has been reached. The agent can then decide to hold or wait. This feedback loop keeps the agent inside the guardrails without requiring human intervention. The architecture assumes that agents will bump against limits, and it treats those collisions as normal events. This is part of making the system safe by design. The constraints are not hidden traps. They are visible boundaries that shape the agent's behavior. This enforcement logic is part of the broader safety model described in how the safety model behind LLM trading works.

Why does live trading require explicit authorization?

Before an agent can move from paper trading to live trading, the owner must explicitly authorize the scoped key for real money. Paper trading runs against simulated market data and lets you observe how the agent behaves without capital at risk. The transition to live trading is gated by a deliberate approval step. This ensures that you have reviewed the agent's strategy, confirmed its limits, and understood that trading can lose money, including the full amount allocated. Authorization is not a one-time contract. You can revoke it instantly, and the system defaults to safety.

Paper trading is the default state for every new agent. In this mode, the agent processes real market data but its orders are not executed with actual capital. This lets you observe slippage, timing, and strategy logic under realistic conditions. You can let the agent run for days to build confidence. Only after you have reviewed its behavior and confirmed its limits do you authorize the live key. Some owners keep certain agents in paper trading indefinitely to generate signals without execution. The architecture supports both modes through the same API, so switching between paper and live is a matter of key authorization, not a code rewrite.