How a single API keeps AI trading agents safe by design

A single API can keep an AI trading agent safe by enforcing non-custodial controls, scoped permissions, and uniform risk limits across every market type. The owner keeps the funds, sets the boundaries, and can revoke access instantly, while the agent only executes within pre-approved constraints. This design removes the need to trust the agent with withdrawal rights or unlimited capital.

What does non-custodial mean for an AI agent?

In traditional automated trading, giving a bot access often means depositing capital into an account that the bot controls or sharing credentials that allow full account access. Felix takes a different approach. Funds remain in a wallet that the owner controls at all times. The agent receives an API key that lets it place trades, but the key cannot authorize withdrawals to any address that the owner has not explicitly approved. Even if the agent's logic is compromised, its server is hacked, or its prompt is manipulated, the worst case is limited to the trading budget and scope assigned to that specific key. The agent cannot drain the wallet, cannot transfer funds to itself, and cannot change withdrawal addresses. This is non-custodial by construction. The API acts as a secure pipe between the agent's decisions and the market venues, not as a custodian of capital. The owner retains the underlying signing rights or private key control for the wallet itself, and the API layer only facilitates execution. This separation of execution from custody is the foundation of the safety model. It means that deploying an autonomous agent does not require the owner to surrender ownership of their capital. The owner can inspect balances, move funds manually, or revoke the agent's access without requesting permission from any third party. Because the wallet is owner-controlled, the owner can also withdraw funds at any time without waiting for an agent to finish its logic or for a batch process to complete. This liquidity control is important in fast-moving markets where the owner may want to manually intervene. The non-custodial design means that trust is minimized. You do not need to trust the agent's developer, the API operator, or the underlying venue with your capital. You only need to trust the mathematical constraints encoded in the scoped key and the wallet technology you already use.

How do scoped keys limit what an agent can do?

Every API key is scoped at creation. An owner can restrict a key to specific market types, such as stocks and prediction markets, while blocking crypto and perps. The key can also be restricted to read-only operations, or to trading only, with no administrative access. Scoping limits the blast radius if an agent behaves unexpectedly. Suppose an agent is designed to trade options. If its key is scoped exclusively to an options venue, it cannot accidentally submit orders to a perps venue or a stock broker, even if the agent's reasoning engine hallucinates a different strategy. Scoped keys can also carry sub-limits, such as maximum order size, permitted symbols, or allowed order types. These constraints are enforced at the API level, not inside the agent. This means the agent does not need to be trusted to enforce its own boundaries. The API rejects any request that falls outside the scope, regardless of what the agent intended. For developers, this simplifies prompt engineering because the safety layer is external and deterministic. It also means that testing in paper trading can use the same scoped key structure, so the behavior observed in simulation maps directly to live behavior. If an agent tries to trade outside its scope during a paper session, the API returns the same error it would return in production. This parity helps teams catch configuration mistakes before capital is deployed. Developers can create multiple keys for different strategies or different agents, each with its own scope. One key might allow only prediction market trading with a fifty dollar cap, while another allows stock trading with a five hundred dollar cap. This multi-key architecture lets owners run several agents in parallel without allowing any single agent to access the full capital pool. If one agent malfunctions, the others are unaffected because their keys are independent. This isolation is enforced by the API, not by the owner's local firewall or network rules.

Why do budget caps and position limits matter across five market types?

The API connects to stocks, crypto, perpetual futures, options, and prediction markets. Each of these has different volatility profiles, margin requirements, and settlement mechanics. A budget cap is a hard dollar limit on how much capital the agent can deploy. Once the cap is reached, the API rejects further orders. This is not a suggestion to the agent; it is a protocol-level boundary. Position limits prevent the agent from concentrating too heavily in a single instrument or market. These limits are especially important when an agent trades across multiple asset classes, because a leveraged perp position and an options spread carry different risk characteristics. A single API normalizes the interface, but it does not normalize the underlying risk. The owner must set caps that respect the specific dangers of each market. For example, perpetual futures can liquidate quickly if leverage is used, while prediction markets may have wide spreads or low liquidity. Budget caps and position limits are enforced independently of the agent's reasoning, so they protect against both buggy code and flawed strategy. They also protect against market anomalies. If a flash crash occurs in one market while the agent is active, the position limit prevents the agent from doubling down repeatedly in an attempt to average down. The owner remains in control of total exposure. Owners should also consider how budget caps interact across correlated positions. An agent might hold a stock and an option on that same stock, or a crypto spot position and a perp hedge. The individual position limits may look small, but the combined exposure can still be significant. The API enforces the limits you set, but it does not judge whether your positions are correlated. That analysis remains the owner's responsibility. Setting caps therefore requires thinking about the portfolio level, not just the individual order level. If you are building an agent for perpetual futures, you should review how hard limits interact with leverage. perpetual futures limits.

What happens when an owner triggers the panic switch?

The panic switch, or kill switch, is a manual control that the owner can activate at any time. When triggered, it performs three actions in sequence. It flattens all open positions, meaning it places orders to close them. It cancels all open orders that have not yet filled. It then revokes the API key, cutting off all agent access. This sequence is executed by the API infrastructure, not by the agent, so a compromised or unresponsive agent cannot block it. The flattening step uses market orders or the fastest available execution method depending on the venue, prioritizing exit over price optimization. Once the key is revoked, the agent cannot reconnect unless the owner generates a new key and explicitly authorizes it. Some owners also configure an automated exit plan, such as flattening all positions at a specific time each day, which acts as a routine circuit breaker. The panic switch is the emergency override. It is designed to be used when the owner sees market conditions change, notices anomalous behavior, or simply wants to stop trading. The existence of this switch changes the psychology of deployment. It means that going live is not an irreversible commitment. The owner can pause, inspect, and restart with a new key after adjusting the strategy or the guardrails. This safety valve is essential for autonomous systems, because no prompt or code can be guaranteed to behave correctly in all market conditions. The speed of the panic switch matters. In volatile markets, seconds can change the outcome of a flattening operation. The infrastructure is designed to issue the exit commands immediately, though the actual fill prices depend on market liquidity and venue execution. The switch does not guarantee a profit or prevent losses already incurred. It simply stops the bleeding. After activation, the owner can review the logs, adjust the strategy, and decide whether to redeploy. This cycle of deploy, monitor, halt, and revise is a safer rhythm than letting an autonomous agent run indefinitely without oversight.

How does dollar-based sizing reduce complexity without hiding risk?

Orders are sized in plain US dollars. The API translates that dollar amount into the correct number of shares, contracts, tokens, or prediction market shares required by the specific venue. This spares the agent from needing to know contract multipliers, tick sizes, or lot sizes. An agent can request to buy one hundred dollars of an asset, and the API handles the normalization. This reduces errors caused by unit confusion, which are common when agents trade across multiple market types. However, dollar-based sizing does not eliminate risk. It simplifies the interface, but the underlying position is still exposed to market volatility, leverage, and liquidity conditions. An agent can still lose the full amount of the order, and in leveraged products, it can lose more than the initial dollar amount if margin is exhausted. The convenience of dollar sizing can obscure the true exposure if the owner does not also set appropriate position limits and budget caps. An agent might treat a one hundred dollar order as a small bet in every market, but one hundred dollars of a leveraged perpetual future can represent a much larger notional position than one hundred dollars of a stock. The abstraction is helpful for execution, but the owner must still understand the risk profile of the underlying instrument. Developers should also note that the API normalizes the request, but the venue may still impose its own minimum order sizes or tick increments. If an agent requests a dollar amount that translates to less than one contract or less than the minimum lot, the API will return an error rather than round the order. This prevents silent approximation errors that could accumulate. The owner should review the minimum sizes for each venue they plan to use, even though the agent works in dollars. You should understand where this abstraction can mislead the agent or the owner. dollar-based order sizing risks.

How should developers connect an agent to the API safely?

Developers can connect agents through MCP tools, which work with Claude, Cursor, and other MCP clients, or through the REST API directly. Before going live, every agent should pass through paper trading. Paper trading uses the same scoped keys, budget caps, and position limits as live trading, but it executes against simulated markets. This lets the owner observe whether the agent respects boundaries, handles errors, and behaves predictably under different conditions. Moving to live trading requires an explicit owner authorization step for the key. This is a deliberate friction point to prevent accidental deployment. Paper trading sessions should include deliberate stress tests. Owners can simulate what happens when the agent hits a budget cap, tries to trade outside its scope, or faces a rapid price move. Observing how the agent handles these errors in paper mode reveals whether the integration is robust. If the agent crashes or loops when it receives a rejection, that behavior must be fixed before live trading. The API's safety model protects against bad orders, but it cannot protect against a poorly written client that mishandles errors. Good deployment hygiene includes testing the failure paths, not just the success paths. When building the integration, the exact request schema is in the docs; the shape looks like this:

curl -X POST https://api.felix.trade/v1/orders \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "symbol": "EXAMPLE",
    "side": "buy",
    "dollar_amount": 100
  }'

This example is illustrative. Real endpoints and fields are documented at /docs. Developers should also audit guardrails before live deployment. audit guardrails. Many common failures stem from assuming that one API means one uniform risk profile across all markets. common mistakes. Test every market type separately, verify that the panic switch works from your dashboard, and confirm that withdrawal addresses are locked to your own wallets before the agent places its first live order. The transition from paper to live should be treated as a deployment event, not a configuration toggle. Document the scoped limits for each environment, and never reuse a paper trading key for live trading without reviewing its permissions.