How position sizing keeps AI trading agents safe by design

Position sizing for AI agents is not a portfolio optimization technique. It is a safety mechanism enforced by the API before an order ever leaves the system. Every order is denominated in plain US dollars, and the infrastructure rejects any request that would breach the owner’s hard caps. This means the agent cannot accidentally or deliberately size a position large enough to threaten the wallet it controls.

Why is position sizing a safety boundary rather than a performance tweak?

An LLM agent does not understand leverage, contract multipliers, or tick sizes. It generates text that gets parsed into actions, and without strict boundaries, a misinterpreted token can produce a catastrophic order. A human trader might notice that one Bitcoin is worth tens of thousands of dollars, but an agent might simply emit the string 'buy 1' without knowing whether that means one dollar, one share, one coin, or one contract. When the agent is connected to a perps venue or an options venue, the difference between those interpretations can be the difference between a trivial test and a liquidation event. Trading can lose money, including everything, so the infrastructure must treat sizing as a hard boundary rather than a hint. The API enforces this boundary without relying on the agent’s reasoning.

Developers sometimes confuse position sizing with portfolio optimization. They ask the agent to 'allocate capital efficiently' or to 'maximize risk-adjusted returns.' These are legitimate research questions for human quants, but they are dangerous instructions for an autonomous agent with live market access. An agent told to optimize can easily overfit to recent volatility or to misinterpret a temporary price spike as a signal to increase size. The safety model does not ask the agent to optimize. It tells the agent the maximum number of dollars it is allowed to expose, and the API enforces that number as a ceiling. Optimization happens inside the ceiling, but the ceiling itself is immutable.

Because the agent is an LLM, it is also prone to hallucination and repetition. A looping agent might attempt the same trade dozens of times in seconds. If each attempt is subject to a dollar limit, the damage is bounded. Without that limit, a looping agent can drain a wallet faster than a human can react. The position limit is therefore a rate limit on exposure, not just a cap on individual trades. It ensures that no matter how confused the agent becomes, it cannot concentrate risk beyond the owner’s tolerance.

How does the API translate dollar limits into venue constraints?

Different market types use different native units. A stock broker might count shares. A perps venue might count coins or contracts. An options venue might use lot sizes with multipliers. A prediction market might use outcome shares with binary payoffs. The API normalizes all of this into a single denominator: US dollars. When an agent submits an order, the system calculates the notional dollar exposure that the order would create at the target venue. It then checks that exposure against the owner-defined position limit and budget cap. If the math does not fit, the order is blocked.

The agent does not need to know that a particular perps contract uses a specific margin formula, or that an options lot represents a hundred underlying units. It submits a dollar amount, and the API handles the conversion. This removes an entire class of error where an agent miscalculates notional value because it read the wrong field in a venue schema. It also means an owner can move an agent from one market type to another without rewriting its prompt or its internal logic. The same dollar cap works for stocks, crypto, perps, options, and prediction markets. You can explore this further in How to trade every market type through one API with real money.

Suppose an agent wants to open a position it estimates at two hundred dollars. The API checks the current market price, computes the exact share or contract count needed to hit that dollar value, and then verifies the resulting notional exposure against the limit. If slippage or a sudden price move would push the position over the cap, the API can reject the order or reduce the size to fit. The agent does not need to predict slippage or to manage partial fills. It requests a dollar target, and the infrastructure either hits the target or reports that the target is out of bounds.

What happens when an agent tries to exceed a cap?

The request is rejected at the API layer. No order reaches the venue. The agent receives an error indicating that the proposed size violates its limits, and it can choose to retry with a smaller amount or to abandon the trade. This is pre-trade risk control, not post-trade damage control. The owner’s wallet is never debited for a breach attempt, and the position limit cannot be bypassed by a creative prompt or a multi-step strategy.

Budget caps and position limits serve different purposes, and both are enforced independently. A budget cap limits the total amount of capital the agent can deploy over a given period. A position limit restricts the size of any single open position at a given moment. For example, an agent might have a two thousand dollar daily budget and a five hundred dollar per-position limit. It could open five positions of four hundred dollars each, or twenty positions of one hundred dollars each, but it could never open a single position of six hundred dollars. The API tracks these counters in real time and atomically checks them before every order.

Atomic checking means there is no race window. If an agent fires two orders simultaneously, both are evaluated against the same limit state. The first order that passes validation consumes budget, and the second order sees the reduced cap. The API does not allow both orders to slip through by checking them in parallel against stale values. This is critical for fast agents that may issue multiple requests in the same second. You can read more about the underlying architecture in How a single API keeps AI trading agents safe by design.

Every attempted order, whether accepted or rejected, is logged. Audit trails let the owner see exactly when the agent approached a limit and what it tried to do. This observability is critical for debugging agent behavior without granting the agent more trust than it deserves. You can learn more about this in How audit logs and observability enforce hard limits on trading agents.

How do scoped keys and budget caps work together?

Scoped keys restrict which markets an agent can access and what actions it can take. These scopes are independent of the dollar limits, but they work together to create a tightly controlled environment.

• ·which market types the agent may trade
• ·whether it may open long positions, short positions, or both
• ·specific symbols or universes it is allowed to touch
• ·the maximum frequency or order types it may submit

Budget caps sit on top of scopes. An agent with a scoped key that only allows prediction markets might still have a five hundred dollar budget cap. Even if the agent is compromised or mis prompted, it cannot escape the prediction market scope, and it cannot spend more than five hundred dollars. The combination of scope and cap means that a breach of the agent’s reasoning layer does not automatically become a breach of the owner’s wallet. The API is the final authority, not the agent.

Owners can set these parameters when they authorize a key for live trading. Paper trading exists for testing, and live trading requires explicit owner authorization. The transition from paper to live does not change the agent’s code. It only changes the key that the agent uses, and the key carries the hard limits. This makes it easy to verify behavior in a sandbox before any real money is at risk.

Developers should think of the scoped key as a contract between the owner and the infrastructure. The agent is merely a party that acts within the contract. If the agent asks for something outside the contract, the API refuses. This separation of concerns lets developers iterate on agent logic without worrying that a bad prompt will rewrite the safety rules. The rules live in the key, not in the agent.

Where does the kill switch fit into the sizing model?

Position limits prevent ruin from accumulation. The kill switch prevents ruin from speed. An owner can trigger a panic button that immediately flattens all open positions and revokes the agent’s key. This is a complementary control, not a replacement for sizing. Sizing limits keep the agent inside a safe envelope during normal operation. The kill switch ejects the agent from the envelope entirely when the owner decides something has gone wrong.

The kill switch is especially important because agents operate faster than humans. An agent might open dozens of positions in minutes. Even if each position is small, the owner might want to stop the strategy for reasons unrelated to size. Perhaps the market regime has shifted. Perhaps the agent is looping on a bad signal. The kill switch does not wait for the agent to respect a limit. It acts immediately, closing positions and cutting access. After it fires, the agent cannot resume until the owner issues a new key.

Flattening is executed as a series of exit orders submitted by the API on behalf of the owner. These orders are subject to the same venue constraints as any other orders, but they are not subject to the agent’s budget caps because they reduce exposure rather than increase it. Once the positions are closed and the key is revoked, the agent has no remaining authority. The owner can then inspect the logs, adjust the limits, and decide whether to reauthorize the agent.

Why is non-custodial design essential to position limit enforcement?

All of these controls depend on the fact that the API does not hold the owner’s funds. The wallet is under the owner’s control, and the agent receives only a scoped key that can spend within limits. The agent can never withdraw funds to itself or to an external address that the owner has not pre-approved. This means that even if every other limit fails, the funds still reside in the owner’s wallet. The API can revoke the key, and the owner can move the funds independently.

Non-custodial architecture changes the trust model. In a custodial system, the owner must trust the platform not to steal or lose the funds. In a non-custodial system, the owner only needs to trust the platform to enforce the limits it has configured. The platform cannot run away with the money because it never has full control. The agent cannot run away with the money because it only has a scoped key. The owner remains the ultimate authority.

Developers who build agentic trading systems should treat position sizing as infrastructure, not as a suggestion they hope the agent follows. The agent’s prompt can say 'be conservative' but the API must say 'five hundred dollars maximum, enforced.' Prompts are instructions. Limits are guarantees. Guarantees belong in the infrastructure layer. You can find a practical guide to setting this up in How to run a non-custodial trading agent through MCP: a practical checklist.

How do developers configure these limits in practice?

The exact request schema is in the docs; the shape looks like this. Owners send a configuration object that ties a scoped key to its dollar limits. The API stores these parameters and evaluates them against every order submitted under that key.

curl -X POST ... \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{\n    "position_limit_usd": 500,\n    "daily_budget_usd": 2000,\n    "allowed_markets": ["stocks", "perps"]\n  }'

The response confirms the limits are active, and subsequent orders from the agent are checked against them. If the agent connects through MCP tools, the same limits apply. The MCP server does not bypass the API; it is just another client. Whether the agent runs inside Claude, Cursor, or a custom REST client, the hard caps remain the same. This uniformity is what makes the safety model reliable across different environments.