How to avoid common risk management mistakes with MCP trading agents

Developers connecting trading agents through MCP often treat risk controls as an afterthought, assuming that a language model will respect implicit limits or that non-custodial infrastructure alone prevents losses. This leads to hard limits that are too broad, prompt instructions that are too vague, and a false sense of safety when the agent can still place orders that drain a budget within minutes. Trading with real money can lose the entire budget, including the principal, and no control layer can eliminate that possibility. The most common mistakes are not in the trading logic but in how boundaries are scoped, enforced, and monitored across the MCP layer.

Why do broad budget caps fail in practice?

Suppose a developer sets a daily limit of one thousand dollars. It sounds reasonable until the agent places twenty orders in a single minute because the model interpreted a signal as urgent. The cap prevents total account depletion across the whole day, but it does not prevent rapid depletion within an hour, and it does not distinguish between a single tested position and a spray of untested entries that all move together. Budget alone is a blunt instrument. It does not know whether the agent is trading one asset or five assets that are highly correlated. A concentrated bet and the same amount split across correlated markets are different exposures, but a simple cap treats both the same.

To make a budget useful, add:

• ·a per-order maximum in US dollars
• ·a per-position maximum in US dollars
• ·a maximum order frequency per minute
• ·a maximum number of open positions

Without these companions, the agent can concentrate risk into one bad trade or diffuse it across dozens of correlated micro-trades that sum to the same exposure. How to run an AI trading agent with real money, safely covers how to layer these controls so that no single setting carries the entire burden. These constraints cap the damage from any single decision and force the agent to slow down.

Developers also forget that budget caps are often keyed to the API key, not the trading strategy. If the agent switches strategies or markets mid-session, the same cap applies indiscriminately. A strategy that requires patience and one that requires frequency should not share the same velocity profile. The API should allow scoped budgets so that a key assigned to a perps strategy cannot accidentally spend the options budget. When every strategy shares one master key, the budget becomes a commons that any aggressive behavior can deplete. Scoped keys turn a shared pool into a set of isolated compartments, which is essential when multiple agents or strategies run in parallel.

How does prompt design become a risk surface?

It is tempting to write natural language instructions like 'do not risk too much' or 'be conservative' and assume the agent will comply. These phrases are not enforceable constraints. They are interpreted differently across contexts, model versions, and temperature settings. What looks like a clear instruction to a human is a fuzzy prior to a language model, and trading agents act quickly enough that a single misinterpretation can open a position before a human notices. Even when developers include numbers in the prompt, the agent might round, approximate, or ignore units, turning a carefully stated limit into a meaningless suggestion.

Risk management should live in the API and the key scoping, not in the prompt. The prompt can describe the strategy, but the hard stops must be set in infrastructure that the agent cannot negotiate. If the maximum position size is two hundred dollars, that limit should be enforced by the key, not by hoping the model remembers a sentence from the system prompt. How prompt design breaks trading agents in 2026 explains why relying on prompt wording for safety is a structural error. API rejections give the agent a concrete error to reason about; prompt constraints fail silently.

A common symptom of this mistake is the 'prompt bloat' anti-pattern, where developers add more and more safety sentences to the system prompt. This increases token cost, slows inference, and still does not guarantee compliance. The correct approach is to keep the prompt focused on market reasoning and to let the infrastructure enforce the financial boundaries. If the agent tries to exceed a limit, the API should reject the call and return a clear error, which the agent can then reason about. The boundary becomes a hard fact in the environment, not a suggestion in the context window.

What is the difference between a kill switch and a stop loss?

Many developers conflate a stop loss with a kill switch, which leaves them exposed when the market gaps or the agent loops. A stop loss is a trading order. It executes at the market when a price is reached, but it can fail to fill at the expected level during volatile periods. It is a tactical tool for managing individual trades, not a guarantee of capital preservation. It depends on the venue's liquidity and the speed of execution.

A kill switch is an infrastructure control. It flattens open positions, cancels pending orders, and revokes the API key so the agent cannot trade again until the owner explicitly reauthorizes access. It does not depend on market price or liquidity. It is a circuit breaker on the agent itself. How trading with an agent changes security from first principles discusses why this distinction matters for non-custodial agent design. The kill switch removes the agent's ability to act, which is the only reliable way to stop a runaway process that is placing orders faster than market orders can be filled.

The mistake is to assume that a stop loss will protect the account from a runaway agent. An agent with a bug can place orders faster than stop losses can be filled, or it can place orders in markets where stop losses are not available. A kill switch is the only control that removes the agent's ability to act. It should be tested in paper trading before live trading begins, and the owner should know exactly how to trigger it without relying on the agent's cooperation. Testing a stop loss is a backtesting exercise; testing a kill switch is an infrastructure drill that requires simulating a revoked key and verifying that the agent cannot reconnect with a cached credential.

Why does dollar-based sizing still need position limits?

Felix normalizes orders into plain US dollars so that developers do not need to calculate contract sizes, tick values, or margin multipliers. This removes a common source of human error, but it does not remove the need for position limits. A developer might think that a two hundred dollar order is inherently safe because the number is small, yet an agent can accumulate many such orders across correlated markets or repeatedly layer into the same trade. Dollar sizing can also obscure the effects of leverage, so the position limit must account for the effective exposure, not just the margin posted.

Dollar sizing clarifies the order, but position limits cap the exposure. A limit that says 'max open notional of five hundred dollars' prevents the agent from opening 25 overlapping positions that each looked reasonable in isolation. The same logic applies across market types. A stock position and a perps position in the same underlying can create hidden concentration that dollar sizing alone does not reveal. How one API routes orders across five market types for AI agents shows how a single API can still enforce cross-market caps. The API must see the total picture even when the agent sees only one market at a time.

Developers should also set per-order frequency limits. Dollar sizing makes it easy to reason about each click, but an agent can click many times per second through an MCP tool. A position limit without a rate limit is like a speed limit without a speedometer. The infrastructure should count orders per minute and reject bursts that exceed the intended trading cadence. If multiple agents share the same account, scoped keys prevent one agent from spending another's budget, which is a common failure mode when developers reuse a single master key across every MCP client. Rate limits and position limits together form a mesh that catches errors in both size and speed.

How should MCP tool scoping match financial boundaries?

An MCP server can expose one broad tool or many narrow tools. The mistake is to give the agent a single tool called 'trade' and expect the prompt to decide which markets are appropriate. If the tool supports stocks, crypto, perps, options, and prediction markets, the agent can technically reach all of them unless the key itself restricts the scope. The tool is the hand, but the key is the lock. Giving the agent a broad tool without a narrow key is like giving it a master password and asking it to be selective. The prompt cannot reliably enforce selectivity because the model's reasoning about which market is appropriate can drift with context.

Scoped keys should map directly to the financial boundaries of the strategy. If the agent is only authorized to trade perps with a daily budget of three hundred dollars, the key should enforce exactly that. The MCP tool can remain generic, but the key should reject any request outside its scope. This separation of concerns lets developers reuse the same tool definitions across different agents without rewriting prompts for every boundary.

The exact request schema is in the docs; the shape looks like this:

{
  "key_name": "agent-perps-only",
  "budget_cap_usd": 300,
  "allowed_markets": ["perps"],
  "max_position_usd": 150,
  "panic_action": "flatten_and_revoke"
}

This illustrative shape shows how the key configuration can encode the budget, the market, and the kill switch in one place. The agent does not see these numbers in the prompt; it sees them only when the API accepts or rejects its tool call. This is the correct place for enforcement, because the API cannot be persuaded by clever reasoning or context window drift. The key is the contract between the owner and the infrastructure, and it should be the final authority on what is allowed.

What does monitoring an agent actually require?

Monitoring is often reduced to checking profit and loss, which is a lagging indicator of risk. By the time the P&L shows a problem, the agent has already breached the boundary. Real monitoring starts with audit logs of every MCP tool call, including the parameters, the timestamp, and the API response. This creates a trail that is independent of the agent's internal reasoning. Monitoring should also include alerts on rejection spikes. A sudden increase in API rejections because the agent is hitting position limits is often the first sign that the strategy or the model is diverging from its intended behavior.

The kill switch must be reachable by a human without going through the agent. If the only way to revoke the key is to ask the agent to revoke itself, the control is broken. The owner should have a direct dashboard or command that flattens and revokes, ideally with a latency measured in seconds, not minutes. This is why non-custodial design matters. The funds sit in the owner's wallet, and the owner can sever the agent's access without the agent's consent.

Before any live trading, the entire stack should be exercised in paper trading. This includes the budget caps, the position limits, the rate limits, and the kill switch. Paper trading proves that the API rejects out-of-bounds requests and that the agent handles those rejections gracefully. It does not prove the strategy is profitable, but it does prove the risk controls are real. Only after the owner explicitly authorizes the key for live trading should real money be at stake. The transition from paper to live should be a deliberate configuration change that requires human approval, not a toggle that the agent can flip on its own by calling a tool.