How a single API keeps an AI trading agent safe inside a code editor

When an AI trading agent runs inside a code editor, it operates at the edge of your trust boundary. The agent can write and execute code, but it should never be able to drain your wallet. Felix addresses this by routing every order through a single API that enforces non-custodial limits, scoped permissions, and owner-approved controls before any venue sees the request. The agent can trade across stocks, crypto, perps, options, and prediction markets from the editor without ever holding unilateral power over your funds.

Why does an AI code editor change the trust boundary?

A code editor with an integrated AI agent is designed to iterate quickly, generate files, and execute commands. That same flexibility becomes a liability when the agent is given access to live markets. Unlike a dedicated server running a hardened trading bot, an editor session is an interactive environment where the model may rewrite its own logic, fetch new dependencies, or respond to prompts that were never part of the original strategy. The context window is wide, and the model may incorporate suggestions from inline comments, imported libraries, or chat history that the owner did not explicitly vet. If the agent holds a raw private key or an unconstrained brokerage token, a single malformed thought or injected instruction could send capital to an unintended destination. The safety model therefore starts from the assumption that the editor is a hostile environment and that the agent should be treated as a guest with a strict allowance, not a co-owner of the account.

This is why the Felix architecture separates the agent from the money. The agent proposes actions through an API, but the API owns the enforcement layer. The editor never sees the underlying venue credentials, and the owner retains the ability to revoke access without rotating a dozen separate passwords. This design is discussed in more detail in how trading APIs keep AI agents safe in 2026.

How does the single API limit what the agent can touch?

One key and one API surface control five market types, but the key does not unlock your entire portfolio. It is scoped to specific actions, such as placing orders within a dollar budget or closing positions, and it cannot initiate withdrawals to arbitrary addresses. Funds remain in a wallet or account that the owner controls, and the agent can only spend within preconfigured limits. This non-custodial structure means that even if the agent were fully compromised, the damage is bounded by the caps you set before the first order. The owner defines these boundaries during setup, and they persist across sessions.

The scoped key is generated with a specific purpose in mind. An owner might create one key for a long-only stock strategy and another for a delta-neutral options program, each with its own budget and market whitelist. If one key is compromised or misused, the other keys are unaffected. This compartmentalization is straightforward when every market routes through the same API, because the owner manages policies in one place rather than across multiple venue portals.

The API also normalizes venue-specific complexity. Orders are sized in plain US dollars, so the agent does not need to calculate contract multipliers, tick sizes, or margin formulas for each instrument. This removes an entire class of errors where a model might misread a decimal place or confuse notional value with lot size. When an agent sends a $100 order, the API translates that into the correct quantity for a stock broker, a perps venue, an options venue, or a prediction market. The agent does not need to know the underlying mechanics. You can read about how this normalization interacts with risk in how an AI agent executes orders through MCP.

Because every market flows through the same control plane, the owner can set global rules that apply across all five asset classes. A single position limit, a single daily budget, and a single kill switch govern the entire surface area. There is no need to configure separate guardrails for each venue or worry that the agent will find a weaker door by switching asset classes. The owner sees one unified exposure, not five fragmented accounts.

How does the safety layer intercept dangerous orders?

Before any order reaches a stock broker, a perps venue, an options venue, or a prediction market, it passes through a validation layer that checks against the owner’s rules. If the order violates a budget cap, exceeds a position limit, or drifts outside the allowed trading hours, the API rejects it and returns an error to the agent. The agent can then log the failure or adjust its plan, but it cannot override the refusal. The rejection happens in milliseconds, and the venue never sees the invalid request.

Pre-flight checks also examine the order for structural sanity. If the agent sends a negative quantity, an unrecognized symbol, or a limit price that drifts too far from the last mark, the API can reject the order as malformed. This protects against prompt-injection scenarios where a malicious or confused instruction tries to trick the agent into an absurd trade. The validation layer does not trust the agent’s intent. It trusts only the owner’s configured rules and the current market state.

The system also enforces an exit plan. An owner can configure conditions that automatically flatten positions and revoke the key. If the agent hits a drawdown limit, or if the owner manually triggers the panic switch, the API cancels open orders and closes exposures. This happens without waiting for the agent to agree, because the agent is a client of the API, not the other way around. The controls are designed to fail closed. If the editor crashes, the model enters a loop, or the network drops, the budgets and kill switch remain active on the server side. The owner is not dependent on the agent’s good behavior for protection.

How do you test the agent before it touches real capital?

Felix provides a paper trading environment that mirrors the live API. An agent connected through MCP tools or the REST API can place orders, track PnL, and react to market data, but the trades are simulated. This lets the owner observe how the agent behaves when it encounters errors, slippage, or budget boundaries. Paper trading exists for testing, and live trading requires an explicit owner authorization step that upgrades the key to real money. The owner should watch how the agent responds to rejected orders, whether it respects the dollar-based sizing, and whether it attempts to retry aggressively or gracefully back off.

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

curl API_ENDPOINT \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "market": "stocks",
    "side": "buy",
    "dollar_notional": 500
  }'

In this illustration, the agent sends a plain dollar amount. The API translates the notional value into the correct contract size for the underlying venue, and it rejects the request if the $500 order would breach the daily budget. The agent does not need to know whether the venue prices in lots, shares, or contracts. This abstraction is what keeps the model’s prompt simple and the owner’s risk surface small. It also means that switching from paper to live trading is a single authorization change, not a rewrite of the agent’s logic.

How do kill switches and budgets work when you step away?

Autonomous agents do not sleep, and owners cannot watch every tick. The safety model therefore includes a hard budget that the agent cannot exceed, regardless of how convincing its reasoning sounds. Once the cap is reached, the API returns a funding error to every subsequent order attempt. The agent may retry or reallocate, but it cannot spend more than the owner allocated. This is covered in depth in how an AI agent trades within a hard budget it cannot exceed.

In addition to budgets, the owner can set drawdown limits that trigger automatic deleveraging. If the portfolio loses a predefined amount, the API cancels open orders and closes positions. The panic switch performs the same action instantly, revoking the key and flattening exposure in a single step. These controls are server-side, so they function even if the editor is closed, the laptop is offline, or the model is stuck in a loop. The owner retains ultimate control over the funds, and the agent is merely a constrained operator.

Every action is recorded in an audit trail that the owner can review without relying on the agent’s own logs. This observability is critical when the agent is running inside an ephemeral editor session that might not persist history. The audit trail captures what the agent requested, what the API allowed, and what the venue executed. The logs are immutable and stored outside the editor environment, so the agent cannot delete or alter its own history. You can learn more about this in how audit logs and observability keep MCP trading agents accountable.

What should you verify before letting the agent trade live?

Before moving from paper to live trading, confirm that the key is scoped to the intended markets and actions. Check that the budget cap reflects money you are prepared to lose, because trading can lose money, including everything. Verify that the withdrawal addresses on the account are your own and that the agent has no path to add new ones. Test the kill switch from a separate device to ensure it flattens positions even when the editor is closed.

Review the agent’s prompt and tool definitions to ensure it understands that orders are sized in dollars and that it should not attempt to compute venue-specific margin. A confused agent is not a malicious one, but the result can be the same if it sends an order that misinterprets leverage. The model should also know that it cannot override a rejection from the API. Treating the API as an inflexible boundary in the prompt helps prevent argument loops where the agent tries to justify a larger position.

Owners should also consider the operational rhythm of the agent. A strategy that rebalances once per day has different safety needs than a high-frequency scalper. The API allows time-based rules that restrict trading to specific windows, which can prevent the agent from entering positions during illiquid hours or macroeconomic announcements. These rules are especially valuable when the agent is running unattended from a cloud-hosted editor instance.

Finally, authorize the live key only after you have observed the agent handling errors gracefully in paper mode. The transition to real money should be a deliberate owner action, not a side effect of a configuration change. When you do promote the key, start with a small budget and expand only after you have seen the agent operate correctly under live market conditions. The safety model is designed to scale with your trust, not to replace it.