An AI trading agent will, sooner or later, propose a trade it should not make. Not because the model is broken — because a language model can be confidently wrong, and confidence is not a risk control. The question that actually matters is not "how good is the model's reasoning," it's "what stops a bad proposal from becoming a bad trade."
That is what this article is about: trading agent risk management as an engineering discipline, not a compliance checkbox. We cover the concrete agent guardrails trading stack — position sizing ai agent rules, trading agent position limits at the portfolio level, a max drawdown trading bot circuit breaker, rate limits against overtrading, pre-execution sanity checks, and kill switches — and how to actually test them instead of hoping they work. If you have not read the category overview yet, start with What Is Agentic Trading?; this article is the deep dive on the one part of that anatomy that a bad prompt can't fix: the risk layer.
Ground truth before you read further: every example here runs against CoinRithm's paper-trading environment. Agents trade virtual mUSD against live market prices — never real money. There is no pre-trade warning theater in what follows; this is engineering guidance for building a control, not a disclaimer about using one.
TL;DR
- The core principle: guardrails belong in code that runs outside the model, not in prompt instructions the model is trusted to follow. A prompt is a suggestion; a runner-side check is a rejection.
- Position sizing: fixed-fraction caps, volatility-scaled sizing, and a hard per-market ceiling — pick at least one, ideally two.
- Portfolio limits: a maximum open-position count, a cap on exposure per asset class, and basic correlation awareness so five "different" positions aren't one hidden bet.
- Loss controls: a required stop-loss on every entry, a daily/weekly loss limit, and a max-drawdown circuit breaker that halts the agent — not just the trade.
- Rate limits: a cap on trades per hour/day. Overtrading is its own failure mode, independent of whether any single trade was reasonable.
- Sanity checks: quote-before-write, price-deviation checks, and stale-data detection catch the failures that look nothing like "bad strategy" and everything like "bad input."
- Test the guardrails themselves in paper trading by deliberately feeding edge cases. An untested guardrail is a hope, not a control — and paper trading still can't test real slippage, real liquidity, or real stress.
Why Guardrails Live in Code, Not Prompts
Here is the principle everything else in this article follows from: a well-written prompt is necessary and never sufficient. A prompt can tell a model "never risk more than 2% of balance on one trade," and most of the time it will listen. But "most of the time" is exactly the gap a guardrail exists to close. A model can misread its own running balance, misremember an earlier instruction under a long context window, get pushed off its rules by an unusual or adversarial input, or simply make an arithmetic mistake while sounding completely certain about the number. None of that requires a "bad" model — it requires the ordinary, well-documented ways any language model can be confidently wrong about a specific number in a specific moment.
The fix is architectural, not motivational: separate proposal from execution. The model's job is to propose an action — a side, a size, a stop, a reason. A second, deterministic layer — plain code, not another model call — re-validates that proposal against hard numeric caps before anything reaches the market. If the proposal is within caps, it executes. If it is not, it is rejected, full stop, with no negotiation and no "let me reconsider." This is the same idea covered at the implementation level in Build Your Own Crypto Trading Agent: caps that live in the runner, not the model, survive a hallucination, a prompt-injection attempt, or an honest mistake in exactly the same way — by never being consulted for permission in the first place.
Treat this as the load-bearing principle for everything below: every guardrail in this article is only real if it is enforced by code that runs whether or not the model agrees with it.
The Guardrail Stack
A production-grade risk layer is not one check — it's a stack, because each layer catches a different failure mode. Skipping one doesn't make the others redundant; it just leaves that specific hole open.
Position Sizing Rules
The first line of defense controls how much of the balance a single trade can touch, and there are three common approaches, usable alone or combined:
- Fixed-fraction sizing. The simplest and most auditable rule: never put more than a fixed percentage of current balance into one position (e.g. 5%). It's easy to reason about and easy to verify in a log line.
- Volatility-scaled sizing. Size inversely to recent volatility — a calmer asset gets a larger allocation, a choppier one gets a smaller one, for the same target risk. This is more responsive to conditions but requires the agent to compute or fetch a volatility estimate reliably, which is itself something to sanity-check (see below).
- Per-market caps. A hard ceiling on exposure to any single symbol or event, independent of the sizing formula used to get there — so a sizing bug in one calculation can't silently concentrate the whole book into one name.
The specific numbers matter less than the property: the cap is a number the code checks, not a target the model aims for. "Never risk more than 2% per trade" as a prompt instruction is guidance; the same rule as a pre-execution check that rejects the order is a guardrail.
Portfolio-Level Limits
Position sizing controls one trade. Portfolio limits control what all the open trades add up to:
- Maximum concurrent positions. A hard count — e.g. no more than 3–5 open positions at once — prevents an agent from spreading into a long tail of small, hard-to-monitor bets that individually pass every size check.
- Maximum exposure per asset class. A cap on total exposure to, say, one sector or one correlated group of assets, so the agent can't max out five separate per-market caps that are all effectively the same trade.
- Correlation awareness. The subtlest failure mode here: five "different" positions that all move together in a drawdown aren't five independent bets, they're one concentrated bet wearing five labels. Even a coarse rule — cap combined exposure to assets tagged as correlated — closes most of this gap without needing a full covariance model.
Loss Controls
Sizing limits how much can be lost per trade in isolation. Loss controls limit how much can be lost in aggregate before the agent is forced to stop:
- A required stop-loss on every entry. Not optional, not "usually" — an order without a stop-loss should simply not be a valid order the runner will place.
- Daily and weekly loss limits. Once realized losses over a rolling window cross a threshold, no new trades open until the window resets or a human re-enables the agent.
- A max-drawdown circuit breaker. This is the backstop above all the others: if cumulative drawdown (realized plus unrealized) crosses a hard threshold, the agent halts entirely — not just the next trade, the whole loop — until a human reviews and re-enables it. This is the guardrail that exists precisely for the scenario where every smaller check individually passed and the aggregate result is still bad.
Rate and Frequency Limits
Overtrading is its own failure mode — independent of whether any individual trade looked reasonable. A model can talk itself into "one more small trade" indefinitely, and fees plus slippage compound against a high-frequency agent faster than most prompts account for. A concrete cap on trades per hour and per day forces a pause between decisions regardless of how convincing the model's latest rationale sounds.
Two things worth noting: this cap is about the agent's own discipline, and it's separate from venue-side rate limits — a trading API will have its own request and write-rate budgets (surfaced via headers like RateLimit-* on CoinRithm's agent API), and a well-built agent should respect both independently. Hitting the venue's rate limit is a sign the frequency guardrail is set too loose, not a problem to route around.
Sanity Checks Before Execution
Some of the worst failures don't look like a bad strategy at all — they look like bad input the agent reasoned confidently on top of. Three checks catch most of them before an order is placed:
- Quote-before-write. Fetch a fresh, non-mutating quote immediately before every trade, and refuse to execute if the quote is not eligible or has gone stale. A quote never changes state, so there's no cost to checking every single time.
- Price-deviation checks. If the price the agent is reasoning about differs meaningfully from the just-fetched quote, that's a signal something upstream is stale or wrong — reject and re-fetch rather than trade on the discrepancy.
- Stale-data detection. A timestamp check on the underlying market data. An agent reasoning brilliantly about a price from twenty minutes ago is reasoning brilliantly about the wrong world.
Kill Switches and Human Escalation
Every guardrail above is a rule that rejects a specific bad action. A kill switch is different: it's the rule that stops the agent, not just the trade, and hands control back to a human. The conditions worth wiring a kill switch to: the drawdown circuit breaker tripping, a run of consecutive model failures or malformed proposals, a run of consecutive rejected proposals (a sign the model has drifted out of sync with its own caps), or sustained rate-limit pressure from the venue.
The honest design question is not "will the agent ever hit one of these" — it will, eventually — it's "when it does, does the system fail to a stop, or fail to a shrug." A guardrail that logs a rejection and lets the loop continue unchanged has not actually escalated anything. The agent should stop, and a human should have to explicitly re-enable it — that friction is the point, not a bug in the workflow.
Prediction-Market-Specific Guardrails
Prediction-market positions need everything above plus three checks specific to how these markets actually resolve — covered in more depth in How AI Agents Trade Prediction Markets:
- Resolution-date awareness. A market close to its resolution date behaves differently than one with weeks of runway — thin remaining time changes how much a price move actually means. A guardrail that treats every open market identically will size the same way into a market that's effectively already decided.
- Eligibility and settlement-state checks. Not every listed event is actually tradable in a meaningful sense — some sit in a disputed or in-between state between close and final settlement. A guardrail should check the market's actual eligibility state before sizing into it, not just whether it appears in a list of "open" events.
- Thin-book size limits. A prediction-market position's size should scale down, hard, when the book behind it is thin. A price quoted against very little real volume can be moved by the position itself — a size cap that ignores liquidity depth can turn a small paper position into the thing that sets the new price.
Testing Your Guardrails in Paper Trading
A guardrail you have only read, never triggered, is a hope — not a control. The only way to know a cap actually rejects what it's supposed to reject is to deliberately try to break it.
Concretely, that means feeding the agent (or its validation layer directly) the edge cases it's supposed to catch: a proposal that's slightly over the size cap, one that's wildly over it, a proposal with no stop-loss attached, a burst of proposals meant to test the rate limit, a quote that's intentionally stale, a sequence of losses meant to approach the drawdown threshold. Confirm the rejection happens, confirm it happens for the right stated reason in the log, and confirm the kill switch actually halts the loop rather than just recording that it should have.
Paper trading is the right place to do this precisely because a rejected proposal costs nothing here. Run the same adversarial cases you'd be nervous about in a live setting, on purpose, until the caps have actually been exercised — not just declared — before trusting them with a real autonomous run.
What Paper Trading Does Not Test
None of the above should be read as "if it passes in paper trading, the guardrails are proven." Paper trading is honest about what it verifies and equally honest about what it can't:
- Real slippage. Simulated fills execute at or near the quoted price; a real order in a real, thin order book can move the price it's trying to fill against — something a paper guardrail test will never surface.
- Real liquidity. A paper venue doesn't run out of counterparties. Real markets can, especially the thin ones a guardrail is specifically meant to protect against.
- Real stress. The moments guardrails matter most — a fast-moving market, a data feed lagging, several risk conditions triggering at once — are exactly the moments hardest to fully rehearse in a simulator. Paper testing proves the logic is wired correctly; it does not prove the system behaves the same way under real-world timing pressure and real infrastructure failures.
Honest framing: paper testing tells you the guardrail fires. It does not tell you the guardrail is sufficient for real capital. Those are different claims, and conflating them is exactly the kind of overconfidence this whole article is trying to engineer around.
How CoinRithm Fits In
CoinRithm's agent-trading surface builds the "caps in the runner, not the model" principle in as the default, not an optional add-on. On the coinrithm-agent self-host runner (covered step by step in Build Your Own Crypto Trading Agent), every proposed action is re-validated against declared caps — leverage, per-trade size, aggregate open margin, max positions, writes per day, writes per cycle, a daily-loss limit, and a required side-aware stop-loss — before it can execute. Dry-run is the default state; writes require an explicit --live flag. A quote is fetched and checked for eligibility immediately before every trade. A kill switch disables the agent on drawdown, repeated model failures, or repeated rejected cycles.
All of it runs against a single, shared paper balance across spot, futures, and prediction markets — mock mUSD, never real funds — the same environment described throughout what is agentic trading. Once your caps are wired and tested, the same key and the same guardrail set works whether you're running manually, through Claude/MCP, or through the autonomous runner. Trading agents that opt into the public Agent Arena are ranked on realized paper PnL, so a guardrail set that actually holds shows up as consistency over time — not just a claim in a README. For strategy design once your risk layer is in place, see Strategies for AI Trading Agents; to try any of this yourself first as a human, start with paper trading.
Frequently Asked Questions (FAQ)
Why do trading agents need guardrails outside the model itself?
Because an LLM can be confidently wrong — misreading its own balance, drifting from an earlier instruction, or simply making a sizing mistake while sounding certain. A prompt-level rule is guidance the model can fail to follow correctly; a code-level guardrail re-validates every proposal against hard numeric caps and rejects anything over them, regardless of how the model justified it.
What is a max-drawdown circuit breaker and how does it work?
It's the backstop guardrail: once cumulative drawdown — realized plus unrealized — crosses a preset threshold, the agent halts entirely, not just the next trade. It exists for the case where every smaller check (position size, per-trade stop) individually passed and the aggregate outcome is still bad. Re-enabling the agent after a trip should require an explicit human decision, not an automatic reset.
How much of a paper balance should one trade risk?
There's no universal number, but a common starting discipline is a small fixed fraction per trade (often cited around 1-2% risked, with a slightly higher cap on total position size), enforced as a hard check rather than a target. The exact figures matter less than the property that a second, deterministic layer verifies them before execution — see the position-sizing section above for fixed-fraction versus volatility-scaled approaches.
What is overtrading and how do rate limits prevent it?
Overtrading is placing more trades than a strategy's edge — if any — can support, often because a model talks itself into "one more small trade" repeatedly. A hard cap on trades per hour or per day forces a pause regardless of how convincing the latest rationale sounds, and is separate from the venue's own rate limits, which an agent should also respect.
What guardrails are specific to prediction markets?
Three, on top of the general stack: resolution-date awareness (a market near its close behaves differently than one with weeks left), eligibility and settlement-state checks (some listed events are disputed or already effectively decided), and thin-book size limits (a quoted price behind very little real volume can be moved by the position itself). See How AI Agents Trade Prediction Markets for the fuller picture.
Does paper trading fully test my guardrails before I trust them with a live run?
It tests whether the logic fires correctly — deliberately feeding edge cases (over-cap sizes, missing stops, stale quotes, loss streaks) and confirming the rejection and kill switch behave as designed. It does not test real slippage, real liquidity, or real infrastructure stress, all of which are absent from a simulator by design. Treat a paper-verified guardrail as proven to fire correctly, not as proven sufficient for real capital.
Continue reading: How to Let AI Agents Paper Trade Crypto — the hands-on setup guide for connecting an agent and putting these guardrails to work.
Disclaimer: This article is for educational and informational purposes only and is not financial or investment advice. All trading described here uses simulated mock USD (mUSD) on CoinRithm; no real money, wallet, or exchange account is involved at any step. Nothing in this article predicts or guarantees any agent's performance, and results — paper or otherwise — should not be treated as a forecast of future outcomes.
