How an AI agent trades within a hard budget it cannot exceed

A hard budget limit on an AI trading agent is only meaningful if the agent cannot override it. Felix lets an AI agent trade stocks, crypto, perpetual futures, options, and prediction markets using a small budget that the agent itself cannot exceed. The architecture relies on a non-custodial wallet that you control, scoped API keys with pre-set spending caps, and a policy layer that rejects any order pushing the agent past its limit. Even if the agent's reasoning fails or its prompt is manipulated, the infrastructure blocks the transaction before it reaches a venue. This means the agent can trade, but it cannot overspend, withdraw funds, or expand its own authority.

What does a hard budget limit actually mean?

A hard budget limit is a ceiling set by the owner, not a suggestion the agent is asked to follow. The agent receives a scoped key that carries its constraints as policy, so the limit is enforced by the infrastructure rather than by the agent's internal reasoning. If the agent attempts to place an order that would exceed its remaining budget, the API rejects the request before it is translated into a venue-native format. The agent does not have the ability to modify the key, raise the cap, or route around the check. This distinction matters because an agent that relies on its own logic to stay within bounds can be jailbroken, confused, or simply buggy. By moving enforcement outside the agent, the limit becomes a structural property of the system, not a behavioral preference. The budget is expressed in plain US dollars, which makes it easy to reason about, and it is checked against every order in real time. There is no batch processing delay or end-of-day reconciliation that could allow a temporary overage. The limit is atomic with respect to each order attempt.

How does the wallet architecture keep funds under owner control?

The system is non-custodial by construction. Your funds sit in a wallet you control, and the agent receives only a scoped key that permits trading within boundaries you define. The agent can spend within limits, but it can never withdraw funds to itself or to an address that you have not pre-approved. Withdrawal addresses are owner-approved only, so even a compromised agent cannot move capital out of your control. This separation between trading authority and custody is the foundation of the budget model. Because the agent never holds the underlying private keys to the wallet, it cannot restructure accounts, change beneficiaries, or move funds to a different chain. The most it can do is place orders that fall within its scoped permissions, and those orders are further filtered by the budget cap. If the agent needs more capital, it cannot mint a new key or escalate its privileges. It must wait for the owner to issue a new scoped credential with a higher limit, which is a deliberate human action. The wallet itself may be a hardware device, a multi-signature arrangement, or a standard software wallet, but the agent never sees the seed material. Its entire universe of action is the scoped API key, and that key is deliberately narrow. How an AI agent executes orders while you keep full custody explains the mechanics of this separation.

Where do the safety controls live?

Safety controls exist at multiple layers so that no single failure can expose the full account. The controls include scoped keys, budget caps, position limits, exit plans, and a panic switch that flattens positions and revokes access. Together they form a set of hard guardrails that operate independently of the agent's logic.

• ·Scoped keys. The API key issued to the agent is bound to a specific budget, market scope, and set of allowed actions. It cannot be used to access other accounts or functions.
• ·Budget caps. A dollar-denominated ceiling is attached to the key. The API tracks running spend against this cap and rejects orders that would breach it.
• ·Position limits. Maximum position size per market and total portfolio exposure are enforced at the API layer, preventing concentration risk.
• ·Exit plans. Pre-defined conditions can trigger automatic reduction of exposure, such as reaching a drawdown threshold or a time-based rollover.
• ·Panic switch. You can flatten all positions and revoke the agent's key instantly, cutting off access without needing to contact a venue.

Each layer addresses a different failure mode. Scoped keys limit blast radius if a credential is leaked. Budget caps prevent runaway spending during a loop or irrational strategy. Position limits stop the agent from concentrating the entire budget in one volatile instrument. Exit plans provide automated de-risking when conditions degrade. The panic switch gives the owner an immediate override. Because these controls live in the infrastructure, they do not depend on the agent interpreting a prompt correctly. The agent could be misled by bad data or a malicious instruction, but it cannot override the API policy. How to build guardrails for a trading agent covers these layers in more detail.

How does the API normalize risk across different markets?

Orders are sized in plain US dollars, and the API normalizes venue-specific contract math so the agent does not need to understand notional calculations for each market type. Whether the agent is trading a stock, a crypto perpetual, an option, or a prediction market contract, it submits a dollar amount and the API handles the conversion. This reduces the risk of sizing errors caused by different tick sizes, margin systems, or contract multipliers. The normalization layer is also where the budget cap is enforced consistently. Because every order is converted to a common dollar value before it is checked against the limit, the agent cannot obscure its true exposure by trading in a market with unusual contract math. Suppose you set a budget of one thousand dollars. That limit means the same thing across a stock broker, a perps venue, an options venue, and a prediction market. The API translates the agent's intent, verifies the resulting dollar impact, and only then forwards the order if the remaining budget allows. The agent does not need to know whether a venue uses linear or inverse contracts, or how margin is calculated. It simply states the desired dollar exposure, and the infrastructure checks that exposure against the remaining budget. One API for every market simplifies the integration, but the normalization layer also ensures that budget caps are evaluated on equal terms regardless of the underlying instrument.

What happens when the agent tries to exceed its limit?

When an order would breach the hard budget, the API returns a rejection before any venue interaction occurs. The agent sees the refusal and can adjust its plan, but it cannot force the transaction through. If repeated failures suggest the agent is stuck in a loop or behaving erratically, the owner can invoke the panic switch to flatten positions and revoke the key. The architecture treats the budget as a physical boundary, not a soft prompt. The rejection is not a suggestion to the agent. It is a terminal response from the infrastructure. The agent may log the failure, revise its strategy, or request guidance, but the dollars remain unspent. This is important because an agent that trades on its own reasoning may develop unexpected strategies. It might attempt to average down repeatedly, chase losses, or split large orders into smaller ones to avoid detection. The budget cap catches all of these behaviors because it counts total exposure, not just individual order size. Even if the agent sends a hundred tiny orders, the sum is still bounded by the cap. Trading can lose money, including everything, but the agent cannot lose more than the budget you allocate. The risk of ruin is bounded by the owner's initial authorization, not by the agent's discretion. If the budget is exhausted, the agent can no longer place orders, and the owner retains the remaining capital in the underlying wallet.

How should you test limits before authorizing live trading?

Felix offers paper trading so you can observe how the agent behaves within its budget constraints without risking real capital. You can verify that the agent respects rejections, handles position limits correctly, and responds to the kill switch. Paper trading uses the same API paths and enforcement logic as live trading, so a limit that holds in simulation will hold in production. When you are ready to trade live, you must explicitly authorize a key for real money, which is a separate step from paper testing. This authorization gap ensures that no agent can accidentally transition from simulation to live execution. During testing, you should deliberately stress the budget cap. Submit orders that would breach the limit and confirm they are rejected. Trigger the panic switch and verify that positions flatten and the key is revoked. Test across multiple market types to ensure the dollar normalization works as expected. Only after you have observed the guardrails under failure conditions should you attach real funds. Testing also reveals whether the agent's retry logic is safe. A well-built agent should back off after a rejection, not hammer the API with smaller orders in an attempt to sneak past the limit. A practical checklist for non-custodial AI trading provides a step-by-step review of these controls before you go live.