How AI agents execute orders without taking custody of your funds

An AI agent executes orders by sending signed instructions through an API that routes to a trading venue, while the funds themselves remain in a wallet or account that only you control. The agent never receives the ability to withdraw capital or move it to an external address. It can only request buys and sells within limits you define in advance. This separation between instruction and custody means the agent acts as a trader with strictly bounded authority, not as a custodian of your assets.

How does an AI agent place an order without taking custody?

When people hear that an AI agent can trade with real money, they often assume the agent must hold the funds in its own wallet or account. That describes a custodial arrangement, and it is not how Felix works. When you connect an AI agent, you create a scoped API key that grants only the permissions you choose. The agent uses this key to send requests, but the key does not confer ownership of the underlying wallet or brokerage account. Your funds stay at a stock broker, a crypto exchange, a perps venue, an options venue, or a prediction market in an account that requires your personal approval for any withdrawal.

The API layer acts as a strict gatekeeper. It receives the agent's request, validates it against your preconfigured rules, and only then forwards it to the venue. If the agent attempts to request a withdrawal, a transfer to an unapproved address, or any action outside its scope, the infrastructure rejects the request before it reaches the market. This is non-custodial by construction, not by policy. The agent operates with a leash, not a vault key. Even if the agent is compromised or behaves unexpectedly, the attacker cannot drain your account because the scoped key simply does not have the permission to move funds off the platform. Withdrawal addresses are owner-approved only, and that approval list is maintained outside the agent's reach. The distinction between the agent's API key and your ownership of the account is fundamental. The API key is a bearer token that authenticates requests to the Felix infrastructure. It proves that the request comes from an authorized agent. However, the infrastructure itself is connected to the venue through a separate set of credentials that you established when you linked your account. The agent key cannot be used to log into the venue directly, nor can it view your withdrawal settings or bank details. It is a one-way door for orders, not a two-way tunnel for funds. How a Claude trading agent trades without taking custody of your funds

What path does an order take from the agent to the market?

The agent begins by formulating an intent. That intent might be to enter a position, reduce exposure, or rebalance a portfolio. The agent expresses this intent in plain US dollars, which is the unit it reasons about most naturally. The intent travels through the API, which performs a series of checks before it ever reaches a market. The API verifies that the key is valid, that the market is on the allowed list, that the dollar amount fits within the remaining budget cap, and that the proposed trade will not violate any position limit you have set.

Once the request passes those checks, the API normalizes it for the target venue. Stocks are measured in shares, crypto in token units, perpetual futures in contracts, options in lots with multipliers, and prediction markets in outcome shares. The API computes the precise quantity using the current market price and the venue's rules for lot size, tick size, and margin. It also maps generic order instructions, such as time in force or order type, into the format required by that specific venue. The exact request schema is in the docs; the shape looks like this:

curl -X POST ... \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"market":"example-market","side":"buy","dollar_amount":500}'

After the API submits the normalized order, the venue responds with a fill, a partial fill, or a rejection. The API then translates that response back into a uniform format so the agent can interpret the result without knowing the venue's native error codes or margin terminology. If the venue rejects the order because of insufficient margin, a halted symbol, or a price band violation, the API translates that rejection into a standard error that the agent can parse. The agent does not need to understand venue-specific error codes. This is particularly useful when an agent is designed to trade across multiple asset classes, because the same error-handling logic can apply to a stock rejection and a crypto rejection. This abstraction means you can point the same agent at a stock broker, a crypto exchange, or a prediction market without rewriting its core logic. The agent remains market-agnostic. However, the API cannot eliminate market risk. Slippage, volatility, and rejected orders still exist, and the agent can lose money on any trade. How to trade every market type through one API with real money

How do scoped keys and budget caps limit agent authority?

A scoped key is an API credential with explicit restrictions encoded into it at the infrastructure level. When you create the key, you define exactly what the agent is allowed to do. You can restrict it to specific market types, such as stocks or prediction markets, while excluding others. You can restrict it to spot purchases only, preventing the agent from accessing margin or perpetual futures. You can set a time bound so the key expires automatically after a day or a week. These restrictions are enforced by the API servers, not by instructions inside the agent's prompt.

Budget caps act as a hard ceiling on how much the agent can deploy over a given period. Suppose you set a daily budget of one thousand dollars. Once the agent has requested buys that sum to that amount, the API will reject any further buy orders until the period resets. Position limits prevent the agent from concentrating too much capital in a single trade or asset. You might allow the agent to trade ten different symbols but cap each position at five hundred dollars. These controls are durable because they live outside the agent. A prompt-level instruction can be misinterpreted, ignored, or overridden by a confused model. Infrastructure-level limits cannot be talked around.

You can also attach an exit plan, which is a pre-registered set of orders or triggers that protect the downside. The agent can initiate entries, but the exits may be governed by rules you set independently. For example, a stop order can be placed by the owner and left in the market so that if the price drops, the position closes even if the agent is offline or unresponsive. This separation of entry and exit authority is a key part of the non-custodial safety model. An exit plan can also include take-profit levels or time-based exits that remove emotion from the closing decision. These orders are registered with the venue under your authority, and the agent may be blocked from canceling them. This prevents a common failure mode where an agent removes its own safety orders to avoid admitting a loss. How to set guardrails for a trading agent without giving up custody

Why does dollar-based sizing matter for autonomous agents?

AI agents reason more naturally in dollars than in blockchain decimals, contract multipliers, or share lots. When an agent expresses an order as a dollar amount, the API handles the conversion to the venue's native units. This prevents a class of errors where an agent might confuse token decimals, contract sizes, or tick values. Suppose an agent intends to risk one hundred dollars on a crypto asset. If the agent had to specify the quantity in raw token units, it might miscount decimal places and accidentally request a position worth ten thousand dollars. By expressing the intent as a dollar amount, the agent delegates the precise unit math to the API.

Imagine an agent trading a prediction market where shares are priced at one cent each but traded in lots of one hundred. An order for one hundred dollars could be misinterpreted as ten thousand shares or one hundred shares depending on how the prompt is written. Dollar sizing removes this ambiguity. The API knows the current share price and the lot size, so it computes the correct quantity. This is also true in options, where contract multipliers are often one hundred, or in perpetual futures with varying margin requirements. The agent does not need to track these details. This normalization is especially important for agents that trade across multiple market types. A single strategy might move between stocks, crypto, perpetual futures, options, and prediction markets. Each venue uses different conventions for sizing, margin, and tick increments. The API abstracts these differences so the agent does not need separate logic for each venue. However, normalizing the order size does not normalize the outcome. The agent can still lose the full dollar amount it risks, and in leveraged markets such as perpetual futures or options, it can lose more than the initial dollar amount if the position moves against it. Dollar sizing is a safety convenience, not a guarantee. How to control the risks of dollar-based order sizing through a single API

How do paper trading and live authorization differ?

Felix offers a paper trading environment that uses the same API surface, the same guardrails, and the same kill switch as live trading. This lets you test the agent's logic, your budget caps, and your panic procedures without risking real money. Paper trading simulates fills, tracks hypothetical profit and loss, and generates the same webhooks and responses that the agent would see in production. You can observe how the agent sizes positions, how it handles rejected orders, and whether it respects the scoped limits you configured.

Paper trading also reveals whether the agent generates excessive order chatter. An agent that sends dozens of requests per minute might be flagged by the API's rate limits in live trading, but in paper mode you can observe the pattern without financial consequence. You can also test how the agent behaves when a market closes, when liquidity is low, or when an order is partially filled. These are edge cases that are hard to debug in live markets. When you are ready to trade with real funds, you must explicitly authorize a specific key for live access. This is a deliberate human step that the agent cannot perform on its own. A key created for paper trading will be rejected if it attempts to touch live endpoints, and there is no automatic escalation path. You should test the kill switch during paper trading. Verify that revoking the key instantly halts order flow, that flattening orders cancel all open positions, and that the agent receives a clear error when it tries to send further instructions. Only after you observe these behaviors and review the agent's simulated track record should you consider live authorization. Even then, trading can lose money, including the entire amount you allocate, so live authorization should be treated as a serious commitment rather than a casual toggle.

What happens when you trigger the kill switch?

The kill switch is a circuit breaker that you can trigger manually or activate automatically through a monitoring rule. When you pull the switch, the infrastructure performs three actions in sequence. First, it cancels all open orders associated with the agent's key so that no new fills can occur. Second, it sends flattening orders to close any open positions and return the account to cash or its base currency. Third, it revokes the API key so the agent cannot send further instructions. Because the system is non-custodial, this revocation is effective and final. The agent does not hold a private key, a seed phrase, or a master credential that could bypass the API layer. The scoped key is the only access path, and once it is dead, the agent is locked out.

You remain in control of the funds throughout the process, and the agent has no mechanism to restore its own access or create a new key. You can also configure automated triggers that activate the kill switch under conditions you define, such as a drawdown threshold or a period of unexpected inactivity. These rules run outside the agent, so they continue to work even if the agent stops responding. This architecture ensures that the ultimate authority over your capital always stays with you, not with the model. Manual activation is a button you press when you observe behavior you do not like. Automated activation is a rule you write in advance. Because the rule is enforced by the infrastructure, the agent cannot disable it. This is important because a compromised or malfunctioning agent might try to silence its own monitoring. The kill switch exists outside the agent's control loop.

Frequently asked questions