// AI AGENTS THAT TRADE

Risk limits for AI trading agents: why hard server-side caps

2026-07-16 · Mithril

Every AI trading agent has risk limits. The only question is whether they are written in a system prompt — where they are suggestions — or enforced in a server the model cannot reach — where they are physics. This post is about the difference, and about the specific limit stack a prediction-market agent needs before it places its first live order.

Prompts are not controls

The naive approach looks responsible: "You must never risk more than $100 per trade. Never hold more than 500 contracts in one market. Always confirm before trading." Written into the system prompt, tested a few times, works fine. Here is why it isn't a control:

• Models violate instructions under confusion. An LLM that has misread a price (Kalshi quotes 42 in cents; Polymarket quotes 0.42 in decimals — a 100× confusion waiting to happen) will cheerfully compute that a $4,200 order is "under the $100 limit."
• Models violate instructions under adversarial input. Prompt injection is not exotic. If your agent reads anything external — news pages, market descriptions, comments — an attacker gets to write into the same context your limits live in. "Ignore previous constraints" attacks are crude and still work often enough to matter.
• Instructions decay in long contexts. An agent 200 tool calls into a session weights its recent trajectory heavily. A constraint stated once at the top is exactly the kind of thing that stops binding.
• There's no audit trail. When a prompt-level limit fails, you find out from your P&L. Nothing rejected the order; nothing logged a violation.

The security literature has a name for the correct posture: the model is an untrusted principal. You don't have to believe your agent is malicious — you have to build as if its output could be arbitrary, because sometimes it will be. Trading firms already know this pattern: the trader does not get to be their own risk desk, however trustworthy. The limits live with someone whose job is to say no.

Enforced server-side — in an execution layer that sits between the model and the venues — a limit has the property that matters: no sequence of tokens the model can emit will lift it.

The limit stack

Six controls, roughly in order of how quickly you need them.

1. Notional caps

The foundation. Two numbers:

• Per-order cap: the maximum dollar value of any single order. Catches fat fingers, unit confusion, and hallucinated conviction in one check.
• Per-day (or per-window) cap: total notional across all orders in a rolling window. Caps the damage of a runaway loop — an agent that retries a timed-out order, or re-derives the same "great trade" every cycle, burns through its daily budget and then simply stops filling.

Set these embarrassingly low at first. An agent that would have made $40 extra with higher caps costs you nothing to throttle; an agent with no caps costs you everything once.

2. Per-market position limits

A cap on net contracts held in any single market. This is the concentration control: without it, an agent can pass every per-order check while stacking its entire budget into one contract it has become convinced about — the LLM version of averaging down. Binary contracts make this especially important, because a single resolution event takes the whole position to zero or one.

3. Slippage bounds

Notional caps bound how much you trade; slippage bounds control how badly. Prediction-market books are thin — a market order for even a few hundred contracts can walk several cents deep (see slippage in thin books). A slippage bound rejects or truncates any execution worse than X cents from the reference price at order time. Agents are particularly exposed here because they often reason from a price quoted seconds — or turns — before the order actually goes out.

4. Kill switch

One switch, instantly effective, that blocks all new orders (and ideally cancels resting ones) across every venue. Requirements: it must work when the agent is misbehaving because of its inputs — so it cannot itself be a tool the agent controls — and it must fail closed. Read access can survive the kill switch; write access must not. If you take one thing from this post: never run an autonomous agent you cannot stop with one action from your phone.

5. Subaccount isolation

Run each agent (or each strategy) against its own subaccount with its own limits and its own funded balance. Isolation does three things: it hard-caps the worst case at the subaccount's balance; it makes one agent's runaway loop unable to consume another strategy's headroom; and it turns attribution from forensics into bookkeeping — every fill belongs to exactly one agent. It's the same reason prop firms give traders books, not the firm's master account.

6. Independent record-keeping

Not a limit, but the thing that makes limits verifiable: every order, rejection, and fill logged by the execution layer, not narrated by the model. Models fabricate fills and misremember positions; the execution log is the ground truth you reconcile against. On fills, an execution receipt — venue, price, fees, timestamp — is the strongest form of this record (why receipts matter).

Sizing the numbers

There's no universal answer, but a defensible starting recipe for a new agent:

The pattern to internalize: limits are the promotion path. A new agent earns wider limits with a track record, exactly like a junior trader. The prompt can be ambitious from day one; the caps should not be.

Keep prompt-level guidance anyway

None of this means you delete the risk language from the system prompt. Instructions still shape behavior in the common case, reduce how often the server has to reject, and make the agent explain itself. The right frame: prompts are the first line of defense and the server is the last, and you only get to call something a risk system if the last line exists.

This split — agent proposes, server disposes — is the core of the safe-agent architecture covered in the hub post, How to let an AI agent trade prediction markets safely, alongside its sibling control, key custody. It's also how Mithril is built: every order an agent sends through the API or the hosted MCP server passes notional caps, position limits, slippage bounds, and a kill switch enforced server-side, with no tool exposed that lets the model change any of them. The MCP tutorial shows the setup — limits first, connection second.

Venue mechanics and product details change. Everything above reflects public documentation as of July 2026 — confirm against current docs before trading real money.