How trading APIs keep AI agents safe in 2026

In 2026, the safety model behind trading APIs for AI agents rests on three ideas: the agent can trade but never withdraw, it can spend only within owner-defined limits, and the owner can revoke access instantly. These APIs do not hold user funds in a pooled account. Instead, they sign transactions from a wallet the owner controls, applying scoped permissions and budget caps before any order reaches a venue. The result is an automation layer that can execute across stocks, crypto, perps, options, and prediction markets without ever taking custody of capital.

What does non-custodial mean for an API?

A non-custodial trading API is not a place where you deposit money. It is a permission layer that sits between your agent and the venues where you already hold assets. When you trade through a custodial service, you send funds to a third party and hope their internal ledger records your balance correctly. When you trade through a non-custodial API, your capital stays in your wallet or brokerage account. The API receives only a scoped key that can request trades, and it routes those requests to the appropriate venue under your existing ownership. Settlement still happens in your own accounts. The agent cannot withdraw to an address you have not pre-approved, and it cannot move funds into a pool that the API operator controls. This removes the primary risk of agentic automation: a compromised or misaligned agent stealing funds. The worst it can do is trade poorly within the limits you set. Because the API never takes possession of your assets, insolvency or misuse by the API operator is also structurally impossible. The operator runs the routing layer, not the treasury. This distinction matters because many automation tools in the past required you to hand over API keys with full account access. A non-custodial model deliberately inverts that trust assumption. The agent is treated as untrusted by default, and every action is filtered through owner-defined policy. You can learn more about this architecture in our overview of non-custodial trading for AI agents.

How do scoped keys limit an agent's authority?

Scoped keys are credentials that carry their own restrictions. Unlike a general trading password that opens every door, a scoped key created for an AI agent might be limited to spot markets under ten thousand dollars, or to options buying without selling naked calls, or to prediction markets with a single strategy. The API evaluates every outgoing request against these scopes before it forwards anything to a venue. If the agent asks to trade a market outside its scope, or to size an order beyond its position limit, the API rejects the request at the edge. This happens before risk checks at the venue level, adding a second layer of defense. The owner can rotate or revoke the key without changing the underlying account credentials. This means a leaked agent key is damaging, but it is contained. The scope is enforced by the API infrastructure, not by the agent's own code, so a bug in the agent cannot accidentally expand its own authority. Scopes can also include time windows, allowed symbols, and permitted order types. An agent might be allowed to place limit orders but not market orders, or to trade only during certain hours. These constraints are stored in the API control plane, not in the agent's prompt or memory, which makes them tamper resistant. Even if the agent is running on a remote server that the developer does not fully control, the key itself cannot be repurposed for unauthorized activity. You can read more about how a single API enforces this in how a single API keeps AI trading agents safe by design.

What happens when a budget cap is reached?

Budget caps are hard spending limits set by the owner, not soft suggestions. The API maintains a running tally of executed trades against the cap. Once the cap is reached, the API stops accepting new orders from that agent. It does not wait for the venue to reject the trade; it blocks it internally. This protects against runaway behavior where an agent enters a loop, misinterprets a signal, or encounters a bug that causes repeated orders. Some owners set daily caps, others set strategy lifetime caps. The important part is that the limit is enforced by the infrastructure, not by the agent's own logic. An agent cannot override its own budget because it does not have the authority to modify the cap. The owner must explicitly raise the limit through a separate authenticated session. The API tracks filled notional value, not just requested value, so an agent cannot game the cap by placing and canceling large orders. Once the cap is hit, the agent receives a clear rejection and can log the event, but it cannot proceed. The cap state persists independently of the agent process, so restarting the agent or moving it to a new server does not reset the count. This prevents an owner from accidentally giving the agent a fresh budget simply by rebooting the system. The owner can set multiple caps for different strategies, so a single account can run several agents without letting one drain the total allocation.

Why is dollar sizing safer than contract math?

Different venues use different contract specifications. A perpetual future on one platform might use a different margin unit than an option on another. When an agent reasons in native contract sizes, it is easy to make magnitude errors. A trading API that normalizes everything to plain US dollars removes this ambiguity. The agent says, buy two hundred dollars worth, and the API translates that into the correct number of shares, contracts, or tokens for the specific venue. This reduces the risk of an agent accidentally sizing an order by a factor of ten because it misunderstood a tick size or decimal place. The API handles the venue-specific math, and the agent handles the strategy. This separation of concerns is a safety feature because it prevents the most common class of automated trading errors: incorrect position sizing. Dollar sizing also makes it easier to compare positions across market types. A five hundred dollar position in a stock and a five hundred dollar position in a perp carry the same notional exposure in the agent's internal logic, even though the underlying contract mechanics differ. The agent does not need to maintain a table of multipliers, margin requirements, or token decimals. It reasons in the same currency it uses for budgeting, which keeps the strategy logic clean and the execution layer precise. This consistency also simplifies backtesting, because the strategy logic can be written in dollar terms and deployed directly without rewriting the sizing module.

How do kill switches and exit plans work?

A kill switch is a control that flattens positions and revokes the agent's key. It is not a polite request to the agent; it is a direct command to the API infrastructure. When triggered, the API cancels open orders and issues exit instructions to bring the portfolio to a neutral state, or to a state defined by the owner's exit plan. The exit plan itself is a pre-configured set of instructions: close all perps, hold stocks, redeem prediction market shares, or similar. Because the API can issue these instructions directly, the agent does not need to cooperate. Even if the agent is stuck in a loop or its host server is offline, the kill switch operates at the API layer. This is important because it treats the agent as potentially faulty by design. The owner retains ultimate control. The kill switch can be triggered manually by the owner or automatically by conditions such as breaching a loss threshold or violating a position limit. Either way, the result is the same: the agent loses its ability to trade, and the portfolio moves toward safety. The exit plan is stored in the control plane, so it survives even if the agent's local state is corrupted or its server fails. You can explore the mechanics in more detail in our article on kill switches from first principles.

How should developers connect agents safely?

Developers connect agents through MCP tools or the REST API. In either case, the principle is the same: the agent receives only the scoped key, not the owner's main credentials. 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_AGENT_KEY" \
  -H "Content-Type: application/json" \
  -d '{\n    "market": "BTC-USD",\n    "side": "buy",\n    "dollar_amount": 500\n  }'

The key in the header is the scoped agent key, not the owner's master key. The agent sends a dollar amount, and the API handles normalization. Developers should test with paper trading before live trading, and live trading requires explicit owner authorization of the key. This means the agent cannot accidentally go live because it found a key in a configuration file. The owner must approve the promotion from paper to live. This two-stage setup prevents an untested strategy from touching real capital. When connecting through MCP, the agent uses standard tools that map to these same API calls, so the security model does not change. Monitoring webhooks can alert the owner when the agent approaches its budget cap or triggers a risk threshold, adding observability without exposing credentials. You can read more about the MCP path in our guide on how an AI agent executes orders through MCP.