AI Agent Guardrails for Trading: Caps, Allowlists, Approvals
AI agent guardrails are limits on what an agent can do, how much and how often, and when a human must approve. For an agent that trades, the guardrails that count are enforced outside the model: per-trade and daily caps, asset filters, rate limits, approval before trades, no withdraw tool and a kill switch.
What are AI agent guardrails?
What are AI guardrails?
What are AI guardrails, in the phrase most explainers use? Controls on what a model may say. IBM's guide to AI guardrails is the definition page that ranks for that broader term. Content filters matter. They do not bind a tool call. A filter can block a sentence and still let an agent submit an order.
AI agent guardrails are the action layer: what an agent can do, how much, how often, and when a human has to approve. Builders, security leads, and anyone connecting a model to an account that can pay need that layer. A nicer prompt is not it.
The failure has a name. In the OWASP Top 10 for LLM applications, LLM06:2025 Excessive Agency is "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM". Hallucination and prompt injection are triggers. Stolen keys and MCP authentication sit with AI agent security. Here they only explain why the check sits where the model cannot edit it. The root causes are "excessive functionality; excessive permissions; excessive autonomy."
The NIST AI Risk Management Framework puts limits on automated action in the risk program, not only in a prompt. A wrong size, a wrong asset, or a loop is money leaving the account. AI trading guardrails are that idea applied to orders.
The core rule: enforce limits outside the model
A rule in a system prompt is a request. A rule checked by the server is a guardrail. Models are wrong sometimes, and text they read can steer them. If the model can ignore the check, you have a preference, not a guardrail.
OWASP states that as complete mediation: "Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not." The downstream system is the account, broker, or wallet API that submits the order. It applies the same rules on every request, whichever client sent it.
Store intent in a profile. Do not store the control there. The trading profile the agent saves is intent only; where it disagrees with the app, the app wins. On Moby, the limits this page names are in this sentence:
The profile can say "be aggressive." The server still checks those three limits on every buy. Use that split for any spending agent.
Prompt guardrails vs enforced guardrails (llm guardrails)
LLM guardrails usually mean checks around the model: a system prompt, plus filters on the input and the output. LangChain's guardrails docs show that pattern. Middleware can stop a bad string before a tool runs. It helps, and it still lives in the app the agent runs in. Another client, or a prompt that talks around the filter, can miss it.
Use every layer. Rely on the last one, the check the model cannot edit.
| Layer | Example | Can the model bypass it? |
|---|---|---|
| System prompt rule | "Never spend more than X." | Yes. The model can ignore it, or an injection can talk around it. |
| Input and output filter | LangChain-style middleware on text in and text out. | Partly. It helps, and it still sits inside the app the agent runs in. |
| Client tool settings | Codex enabled_tools, disabled_tools, and default_tools_approval_mode (auto, prompt, writes, approve). See the Codex config reference. |
The model does not edit the file. Another client can be set differently. Good hygiene, on the client. |
| Server-side account limits | Caps, asset filters, and rate limits on the account that executes the action. | No. Every request is checked, whichever client sent it. |
Set enabled_tools, disabled_tools, and approval mode on the client anyway. Those files are not the account. Another host with a looser config still has to pass the server.
The MCP Security Best Practices describe a "progressive, least-privilege scope model", and they treat token passthrough as an anti-pattern. Mint a credential for the agent. Do not hand it a token from a broader session.
Ten guardrails for an agent that can spend money
Use this as a checklist for any agent that can spend. Each item is the control, the failure it prevents, and where the check has to live. Moby is the worked example. The only Moby limits named here are max per trade, daily buy volume and market-cap range.
1. Minimal tools
Do not ship a tool the agent must never call. That is excessive functionality: a withdraw or a transfer left in because it was easy to expose. A prompt that says "never withdraw" loses to one tool call. OWASP's line is "Limit the extensions that LLM agents are allowed to call to only the minimum necessary." If the job is research and trade, that is the list. On Moby the missing tool is explicit. It cannot withdraw, transfer or send your funds. There is no tool for it.
2. Scoped, revocable credentials
A wallet private key can move funds out. Mint a credential for the agent, one you can create, rotate, and revoke, and do not pass through a token from a broader session. On Moby the key starts with moby_agent_. It is not a wallet private key. You create, rotate, and revoke it from the Agent tab.
3. Separate funds
Do not let the agent spend the wallet you use for everything else. Fund a separate wallet with only what you assign. That balance is a boundary on which funds can be touched, not a forecast of profit or loss. On Moby there is one agent per user. That agent has its own wallet, separate from your main wallet.
4. Per-trade cap
A per-trade cap is the maximum size of one action. It stops a bad order, a duplicate, or the wrong contract from taking the balance you assigned. The server refuses the buy. The model does not get a second vote. On Moby that cap is max per trade, checked server-side on every buy. It does not hold what the position is worth later.
5. Daily cap
A daily cap stops a loop from repeating the per-trade cap until the assigned balance is gone. On Moby that control is daily buy volume, checked on every buy together with max per trade. It limits new buys. Selling, and a move in the price, can still lose money.
6. Asset allowlist and filters
A filter blocks the wrong asset: a lookalike ticker, an illiquid name, or something outside the mandate. A list, a block list, a market-cap range, or a risk score can do that job, but the server has to run it. A prompt is not the filter. For Moby, the allowlist in the title is the market-cap range you set in the app, checked on every buy with the two caps.
7. Rate limits
A rate limit counts actions per minute and per day. A burst of small buys can build a large position before anyone looks, and a retry will do it by accident. Put the count on the server that submits the order. A short window stops the burst. A day window stops a quiet loop. The count sits beside the size caps and the asset filter. It does not replace them.
8. Human approval
A person should approve high-impact actions before they run. OWASP says "Utilise human-in-the-loop control to require a human to approve high-impact actions before they are taken." Start with approval on every action, and loosen it only after the logs match the policy you wrote. Approval is a pause, not a cap, so the server still checks size when a human says yes. On Moby the optional switch is "Ask before every trade." Max per trade, daily buy volume and market-cap range are still checked on every buy when that switch is off.
9. Fresh quotes
A quote is a price with a clock. The quiet failure is a checklist that looks fine and a fill that is not the trade you approved, because the market moved after the price was fetched. Expire the quote. If it is stale, fetch a new one and run the caps and the filter again. Measure the window in seconds on the server that sends the order, not in the model's memory.
10. Kill switch and audit
Revoke access in one step, and log both the orders the server accepted and the ones it refused. OWASP also recommends logging and monitoring. A refusal in the log is how you know a guardrail is real. Practice the revoke before you need it: remove the credential and confirm the next call fails. On Moby, revoke the key from the Agent tab and the agent stops at once. A trade that already filled is not undone.
Set the caps on the account that submits the order, then let the agent work inside them.
How to set guardrails for AI agents (step by step)
Set guardrails for AI agents before the first live action. By the third step the server should refuse a bad request even if you never write a system prompt.
- List the actions the agent needs; remove every other tool.
- Give it its own credential and its own funds.
- Set caps (per action, per day) and filters before first use.
- Start with approval on every action; loosen only after review.
- Test with a small amount and read the logs.
- Know how to revoke in one step.
What guardrails do not do
Guardrails limit the size and type of mistakes. They do not make a decision good, and they do not make a trade profitable. Review the trades, and start with an amount you can afford to lose.
Server-side caps apply to buys. Selling and market moves can still lose money. Daily buy volume can stop new buys once that volume is used. It does not hold the value of an open position. Price can fall after a fill, a sell can execute worse than the quote, and a token can go to zero.
Do not read a guardrail as a floor under losses. These controls refuse some orders. They do not insure the ones they accept. Position sizing, stop-loss, and portfolio risk are covered in AI trading risk management. Whether automated trading is a sound idea is the question in is AI trading legit.
Frequently asked questions
What are AI agent guardrails?
AI agent guardrails are controls that limit what an AI agent can do, how much it can do and how often, and when a human has to approve an action. They differ from content filters, which control what a model says rather than what it does.
How do you set guardrails for AI agents?
Give the agent only the tools it needs, its own credential and its own funds. Set caps per action and per day, filter what it can act on, require approval at first, test with small amounts, log everything and make sure you can revoke access in one step.
What are the types of AI guardrails?
Common types are capability limits (which tools exist), permission limits (scoped, revocable credentials), spending caps, asset or action filters, rate limits, human approval, and monitoring with a kill switch. Content guardrails that filter inputs and outputs are a separate layer.
Why do AI agents need guardrails?
Models can hallucinate, misread data or be manipulated by prompt injection. OWASP calls the resulting risk Excessive Agency, caused by excessive functionality, permissions or autonomy. Guardrails cap the damage when the model gets something wrong.
What is a technical guardrail for AI?
A technical guardrail is a limit enforced by software the model cannot change, such as a server-side spending cap, a rate limit or a missing tool. A rule written only in a prompt is not a technical guardrail, because the model can ignore it.
Are prompt instructions enough as guardrails?
No. A prompt instruction is a request the model may ignore or be tricked around. Use prompts to state intent, but enforce limits in the system the agent calls, so every request is checked against your rules.
What guardrails does a Moby Agent have?
You set your agent's limits on max per trade, daily buy volume and market-cap range from the Moby app, and Moby checks them server-side on every buy your agent makes. The agent has its own wallet, cannot withdraw funds, and stops at once if you revoke its key.
Do guardrails make AI trading profitable?
No. Guardrails limit the size and type of mistakes an agent can make. They do not make its decisions good, and you can still lose money. Start small and review every trade.
Try it with a Moby Agent
Set up a Moby Agent with its own wallet and your spending guardrails, then connect it to the AI you use.
You set your agent's limits on max per trade, daily buy volume and market-cap range from the Moby app, and Moby checks them server-side on every buy your agent makes.
Moby Agents trade Solana tokens, paid in USDC, including tokenized stocks. The liquid tokenized stocks on that list are the xStocks tickers AAPLx, MSFTx, GOOGLx, AMZNx, METAx, NVDAx, TSLAx, AVGOx, TSMx, COINx, MSTRx, CRCLx, SPYx, QQQx and GLDx.
AI Trading on Base, BNB Chain and Robinhood Chain is coming soon. There is one agent per user, with its own wallet, separate from the main wallet in the app.
Moby Agents connect to Codex, Claude Code and Grok. Claude Code means the Claude Code CLI.
A 0.75% swap fee (minimum $0.90 per swap), plus onchain fees.
Moby Agents connect through Moby MCP. The host steps for Codex are in the Codex MCP setup guide. The product frame is agentic trading.
Trading crypto and tokenized stocks is risky and you can lose money. Guardrails limit what an agent can do; they do not guarantee returns. Nothing on this page is investment advice.