AI Trading Agent Guardrails: How to Let an Agent Trade Without Risking Your Account

AI agents can now research a market, size a position and place the order themselves. Connect Claude Code, Codex or another agent to an exchange and it will trade around the clock, faster than you can. The question is no longer whether an agent can trade for you, but how to make sure it only trades the way you intended.

That's what guardrails are: limits on what an agent is allowed to do with your money, enforced somewhere the agent can't override. This guide covers why agents need them, which limits matter, and the three places you can enforce them.

Why AI trading agents need guardrails

A traditional trading bot follows code you wrote. An AI agent follows instructions it interprets, and it acts on information it reads. That makes it more capable and less predictable. Four kinds of failure show up in practice:

• Mistakes. Models misread numbers, confuse tickers and hallucinate details. A misplaced decimal becomes a real order.
• Bugs. The code around the model can resend orders, ignore balances or mis-size positions. It runs exactly as written, wrong or not.
• Manipulation. Agents read text you don't control: posts, news, token descriptions, web pages. Prompt injection hides instructions in that text. OWASP's Top 10 for Agentic Applications (December 2025) ranks this first, as "agent goal hijack": an attacker redirecting what the agent is trying to do (OWASP). When an agent called Freysa was told never to release its prize pool, a participant talked it into sending the full 13.19 ETH (about $47,000) anyway (Cointelegraph, The Decoder).
• Compromised access. Keys and credentials leak through logs, configs and shared machines. In the public record so far, leaked keys and plain mistakes have cost agent owners more than manipulation has (see How AI Agents Actually Lose Money).

None of these needs a malicious agent. They need only an agent with more authority than its limits allow for.

The limits that matter

Good guardrails match the strategy. A conservative portfolio agent and an active perps agent need different numbers, but the same kinds of limits:

Two details make limits robust.

Check the account, not just the order. An order can look fine on its own and still be dangerous. A $500 buy is small, unless the account already holds $20,000 of the same asset at 4x leverage. Account-level limits (leverage, concentration, equity floor) should be checked against the account as it would be after the trade.

Treat closing differently from opening. If limits block an agent from reducing risk, they can trap you in a losing position. A good guardrail lets a genuine close-out (a reduce-only order) through, while still blocking new risk.

Where you can enforce limits

Where a limit lives matters as much as what it says. There are three places it can live.

1. In the prompt. "Never use more than 2x leverage." It's easy to write and the agent will usually follow it. But a prompt is a request, not a rule. A model can misread it, code can bypass it, and prompt injection is designed to override it. Use it to guide behavior, never to protect capital.

2. At the exchange. API-key permissions (no withdrawals, IP allowlists) and venue risk settings (maximum leverage, position limits) are enforced by the exchange, which the agent can't change. Use them. But they're coarse and differ by venue, and a trade-only key still lets an agent do a lot of damage through trades alone. We cover this in Is It Safe to Give an AI Agent Your Exchange API Key?.

3. At signing, outside the agent. The strongest place is the moment an order is signed. If every order must pass your limits before a signature exists, a bad order can't reach the exchange, however it was produced. The agent can propose anything; only what passes gets signed.

What enforcement at signing looks like in practice

You can build a signing layer yourself, but it's harder and riskier than it looks. It's a service that holds the key, checks each order against your rules, and signs only what passes, which makes it the most security-critical code you run. One bug in a check, one stale balance or one leaked key, and every limit it was meant to enforce is gone. If you do build one, keep the key away from the agent entirely, check against fresh account data, make refusals final rather than retryable, and log every decision.

Pakt is a ready-made version of this layer for trading agents:

• You define the limits once (markets, size, leverage, concentration, price protection, reserves and more) and approve them with a signer you hold.
• Your agent proposes orders. Pakt checks each one against your limits and your account's projected state after the trade, and signs only if every rule passes.
• The checks can't be talked around. Verification happens inside secure hardware (a TEE), and a zero-knowledge proof shows each order satisfies your exact rules. An agent can't change your rules or obtain an arbitrary signature.
• Refusals are final. A refused order gets no signature and never reaches the venue. Only you can change the limits.
• It's non-custodial. Your funds stay at your venue, and Pakt never holds your keys.

Pakt is live for Hyperliquid perpetuals, in beta. It connects to Claude Code, Codex, Gemini, OpenCode and other MCP-compatible agents.

A starting set of guardrails

If you're setting up an agent for the first time, start tight and loosen with evidence:

1. Allocate a small, separate amount the agent can trade, in its own sub-account or wallet.
2. Allow only the markets your strategy needs. For most, that's a handful of liquid ones.
3. Cap each trade at a small fraction of the allocation.
4. Cap leverage low. 1–2x is a sensible start for an untested strategy.
5. Set an equity floor below which the agent can't open new positions.
6. Block withdrawals and transfers entirely unless the strategy needs them.
7. Keep exits open: make sure reduce-only orders can always get through.
8. Review refusals. Each one is the guardrail doing its job, and a signal about how your agent behaves.