How to start an AI trading agent with hard limits

An AI trading agent can only operate safely if it is physically unable to exceed boundaries set by its owner. Hard limits are constraints embedded in the trading infrastructure so that the agent cannot spend more than a defined budget, open positions beyond a set size, or withdraw funds to unauthorized addresses. Setting these limits before the agent receives its first market data is the difference between a controlled experiment and an open-ended liability. This article explains how to configure those boundaries using non-custodial infrastructure, scoped keys, and programmable safety controls.

What are hard limits and why do they matter?

Soft limits, such as instructions in a prompt or a note in the system message, rely on the agent to interpret and obey them. An agent can misunderstand context, fixate on a perceived opportunity, or act on a corrupted data stream. A poorly worded prompt might tell the agent to "be conservative," but the agent's internal reasoning could define conservative differently than you do. Hard limits remove this ambiguity. They are enforced by the API and the wallet infrastructure, not by the agent's reasoning. If the agent attempts to submit an order that would breach a hard limit, the API rejects it before any funds move. This is important because trading can lose money, including everything, and an agent with unrestricted access can compound errors far faster than a human can react. The goal is to contain the agent's operational envelope so that even a malfunction or adversarial prompt cannot expand it. Hard limits are the difference between a tool that works within a known perimeter and a tool that can wander into unintended territory.

Imagine you tell the agent to buy a dip when it detects a ten percent drop. Without a hard position limit, the agent might interpret this as a signal to deploy the entire wallet into a single asset. With a hard limit of five hundred dollars per position, the API rejects the oversized order and the agent is forced to stay within the boundary. The agent does not need to agree with the limit. It simply cannot bypass it. This is why hard limits are the foundation of safe agentic trading. They protect you from the agent's worst interpretation of your instructions.

How does non-custodial setup protect your funds?

In a non-custodial model, your funds sit in a wallet that you control. The agent receives a scoped key that lets it trade, but it cannot withdraw funds to itself or to any address you have not pre-approved. Withdrawal addresses are owner-approved only. This means that even if the agent's logic is hijacked or its key is leaked, the attacker cannot sweep the wallet. They can only trade within the remaining budget, and only within the markets and order types permitted by the key. You remain the custodian at all times. The infrastructure is built so that the agent can spend within limits but can never take possession of the funds.

This design principle applies across all five market types. Whether the agent is interacting with a stock broker, a crypto venue, a perps venue, an options venue, or a prediction market, the custody model remains the same. Your capital never moves to an intermediary account that the agent controls. Instead, the agent requests trades and the API settles them against your wallet within the approved boundaries. This is fundamentally different from custodial models where you deposit funds to a third party and hope their internal controls are sufficient. Here, the controls are yours to set. If you want a step-by-step review of these controls, our non-custodial trading checklist covers the full setup.

Which controls should you configure before the first trade?

Before the agent connects to any market, you should define the exact conditions under which it is allowed to operate. These controls create a container that the agent can trade inside but cannot break. Consider the following categories.

• ·Budget caps: Set a maximum amount of US dollars the agent can deploy over a day, week, or month. Once the cap is reached, new orders are rejected until the period resets.
• ·Position limits: Define the maximum notional size for any single position and the total gross exposure across all markets. This prevents a single bad signal from creating an outsized loss.
• ·Approved markets: Restrict the key to specific market types (stocks, crypto, perps, options, or prediction markets) rather than granting universal access.
• ·Order types: Limit the agent to plain market or limit orders if complex order types are unnecessary for your strategy. This reduces the chance of unintended execution paths.
• ·Time windows: Allow trading only during certain hours to reduce overnight or low-liquidity risk. This is especially useful when starting out.
• ·Exit plans: Predefine how the agent should close positions, either through trailing stops, time-based exits, or manual triggers. An exit plan is a hard limit on how long a position can remain open.

These controls are not suggestions. They are parameters enforced by the API. If you set a daily budget cap of one thousand dollars, the agent cannot place a trade that would push its daily total to one thousand and one. The system normalizes venue-specific contract math into plain US dollars, so the cap applies consistently whether the agent is trading on a stock broker, a perps venue, or a prediction market. Because the API abstracts the underlying contract sizing, you do not need to calculate lot sizes, leverage multipliers, or tick values. You state the limit in dollars, and the infrastructure enforces it. This normalization is particularly valuable when the agent operates across multiple markets. A perps venue and an options venue may use entirely different margin systems, but your hard limit is expressed in the same unit. You can learn more about designing these constraints in our guide on how to build guardrails for a trading agent.

How do scoped keys enforce boundaries?

A scoped API key is a credential with permissions narrower than full account access. Instead of giving the agent a master key, you issue a key that can only perform specific actions. For example, you might create a key that can buy and sell stocks and crypto, but cannot touch options or perps. You might further restrict that key to a maximum order size of five hundred dollars and a maximum daily spend of two thousand dollars. The API checks every request against these scopes. If the request violates any boundary, it is rejected before it reaches the market. This happens regardless of how the agent is connected. Agents can connect through MCP tools from Claude, Cursor, and other MCP clients, or through the REST API directly. In either case, the scoped key is the same. The connection method does not change the hard limits.

Scoped keys are particularly important because they protect against both agent error and key compromise. If the agent is connected through an MCP tool and the session is manipulated, the key cannot do more than its scope allows. You send an order in plain US dollars, and the API handles the normalization across the underlying venue. This abstraction means your limit logic stays the same regardless of whether the agent is trading on an options venue or a crypto exchange. You do not need to rewrite your safety logic when you add a new market type. One key, one API, and five market types all share the same enforcement layer. For a deeper look at key design, read our article on scoped API keys for trading agents.

How do you test limits before going live?

Paper trading lets you observe how the agent behaves under the exact same scoped keys and hard limits, but without real money at risk. You should test three failure modes before authorizing live trading. First, attempt to exceed the budget cap and confirm the API rejects the order. Second, try to open a position larger than the limit and verify it is blocked. Third, trigger the kill switch and ensure it flattens all positions and revokes the key immediately. Paper trading exists for testing this logic. Only after you have validated the behavior should you authorize live trading with explicit owner approval of the key.

Testing should also include observing how the agent responds to rejection. A well-designed agent will log the rejection and adjust its plan. A poorly designed agent might loop, sending the same rejected order repeatedly. It is better to discover this behavior in paper trading than with real money. You should also verify that the time window limits work correctly. If the agent is restricted to trading between 9 AM and 4 PM, an order submitted at 4:01 PM must be rejected. This process is part of running an AI trading agent with real money, safely, which we cover in how to run an AI trading agent safely.

What happens when a limit is breached or you need to stop?

Hard limits are designed to prevent breaches, but you also need a final layer for emergencies. A panic or kill switch flattens all open positions and revokes the agent's access in a single action. Once revoked, the key is useless. The agent cannot place new orders, and any pending orders are canceled. This is distinct from an exit plan, which is a predefined strategy for closing positions under normal conditions. The kill switch is for abnormal conditions: a flash crash, a logic loop, or a sudden change in your risk appetite. You should locate the kill switch before you start trading, and you should test it during the paper trading phase so that you know the latency between pressing the button and seeing zero exposure.

Flattening means closing all open positions, which may result in realized losses. The kill switch does not guarantee that you exit at a favorable price. It guarantees that the agent stops trading. This is a critical distinction. Some traders hesitate to use a kill switch because they fear locking in a loss. However, an agent that continues trading during a malfunction can turn a small loss into a total loss. The kill switch is the ultimate hard limit because it removes the agent's ability to act at all. After it is triggered, you can inspect the logs, adjust the limits, and issue a new scoped key when you are ready to resume.

Frequently asked questions