How to set guardrails for a trading agent without giving up custody

You do not need to transfer your funds to a third party to let an AI agent trade on your behalf. Non-custodial agent trading keeps your money in accounts and wallets that only you control, while the agent operates within strict boundaries that you define and can revoke at any moment. These boundaries, called guardrails, are enforced at the infrastructure level so the agent cannot override them, withdraw your funds, or exceed the limits you set. The result is that you keep custody, you keep the ability to shut everything down instantly, and the agent only gains the specific trading permissions you choose to grant.

What does non-custodial agent trading actually mean?

In most traditional automated trading setups, you deposit capital into an account controlled by a platform, exchange, or broker. The algorithm then trades that pooled or custodial balance. If the platform freezes withdrawals, suffers a breach, or mismanages funds, your capital is at risk regardless of how well the algorithm performs. Non-custodial design removes this dependency by keeping the underlying assets in wallets or brokerage accounts where you hold the ultimate control. The agent receives a scoped key that can instruct trades but cannot move funds to an unauthorized address or account. Withdrawal addresses are owner-approved only, meaning even a compromised or malfunctioning agent cannot empty your wallet. The funds sit where you put them, and the agent merely requests executions through an API that normalizes access across stocks, crypto, perpetual futures, options, and prediction markets. You remain the custodian, and the agent remains a delegate with limited powers. This distinction matters because it changes the risk profile from trusting an institution or an AI with your money to trusting only the infrastructure that enforces your explicit permissions. If the infrastructure is built correctly, the agent is physically incapable of actions you have not pre-approved. You can revoke the key at any time, and because the funds never left your control, revocation does not trigger a withdrawal process. It simply stops the agent from placing new orders. This immediacy is a core benefit of non-custodial architecture. You are not waiting for a support ticket or a multi-day outflow window. You click, and the agent loses access while your capital stays put.

What is the difference between prompt guardrails and infrastructure guardrails?

Many beginners try to control an agent by writing detailed prompts. They instruct the agent to trade only during certain hours, avoid large positions, or stop after a loss. These prompt guardrails are useful for setting intent, but they are not reliable limits. A confused agent, a misinterpreted data feed, or a creative reasoning loop can cause the agent to ignore or misread its own instructions. Infrastructure guardrails are different. They exist outside the agent's reasoning process and are enforced by the trading API itself. The API does not ask the agent whether it agrees with the budget cap. It simply rejects orders that violate the cap. This separation of policy enforcement from agent cognition is the foundation of safe agentic trading. You should use prompts to communicate strategy and use infrastructure guardrails to enforce absolute boundaries. Relying on prompts alone is like asking a driver to obey the speed limit without a speedometer or a speed bump. The combination of clear instructions and hard limits gives you control without requiring constant supervision.

Which guardrails should a beginner set first?

Guardrails are only useful if you configure them before the agent starts trading. Beginners should treat these as hard requirements, not optional suggestions. It is tempting to trust the agent because it sounds intelligent, but intelligence without boundaries is not a strategy. It is a liability. The most important controls are:

• ·A total budget cap. This is the maximum notional value the agent can have deployed across all positions at any given time. Once the cap is reached, the API rejects new orders that would increase exposure. This cap is your first line of defense against runaway accumulation.
• ·A per-trade or per-symbol position limit. This prevents a single large order or a concentrated bet from dominating your portfolio. Even if the agent detects what it believes is a strong signal, it cannot allocate more than your preset maximum to any one trade.
• ·Market scope. You decide whether the agent may trade stocks, crypto, perps, options, prediction markets, or some combination. A beginner should typically start with one market type and expand only after validating behavior. Each market has its own volatility and margin rules, so mixing them early increases complexity unnecessarily.
• ·An exit plan. This can include time-based exits, stop levels, or maximum holding periods that the system monitors automatically. The agent does not need to remember to exit because the infrastructure enforces the plan even if the agent crashes or loops.
• ·A loss threshold or drawdown trigger. If the agent loses a defined amount within a defined window, trading pauses and you receive an alert. This prevents a bad day from becoming a catastrophic day while you investigate what went wrong.

Together, these five controls form a baseline that keeps the agent inside a box you designed. You can read more about building this baseline in our guide on risk management for a first-time trading agent.

How do scoped keys and budget caps work?

A scoped key is an API credential that carries a specific permission set. Unlike a general trading key that might allow withdrawals, transfers, or account changes, a scoped key for agent trading is restricted to order placement and cancellation within the parameters you set. The system enforces these restrictions at the API level, not inside the agent's logic, which means a prompt injection or logic bug cannot bypass them. This is a critical distinction. Prompt engineering is useful for telling the agent what to do, but it is not a security boundary. A scoped key is a security boundary. Budget caps are expressed in plain US dollars. When the agent submits an order, the API checks the notional dollar value against your remaining budget. If the order would exceed the cap, it is rejected before reaching the market. This normalization is important because different venues use different contract sizes, margin systems, and token denominations. The API handles the conversion so the agent does not need to understand whether a perp contract is one dollar or one thousand dollars per point. The dollar-based abstraction removes an entire category of errors where an agent miscalculates a position size because it misread a decimal place or a multiplier. You remain in control because the key itself is bounded by the infrastructure. Even if the agent attempts to trade aggressively, the infrastructure blocks orders that violate your scoped permissions. For a deeper look at how these controls fit into a complete setup, see our article on how a single API keeps AI trading agents safe by design.

Why is a kill switch your most important control?

Every automated system eventually encounters an edge case, a bad data feed, or a strategy that behaves differently in live markets than in simulation. A kill switch is a manual or automated trigger that immediately flattens all positions and revokes the agent's API key. Because the system is non-custodial, flattening positions returns your capital to its base state within your own accounts, ready for your next decision. The agent cannot disable the kill switch, delay it, or override it. This is a crucial architectural property. The kill switch should be accessible outside the normal agent control flow, ideally through a separate channel or dashboard that you control directly. If the kill switch is mediated by the same process the agent uses, a runaway agent might interfere with it. Separation of control is essential. Some traders also configure automated kill conditions, such as a maximum daily loss or a sudden volatility spike, that trigger the same flattening and revocation sequence. Others prefer a purely manual switch, which gives them the final say but requires them to be available. The goal is not to predict every failure mode but to ensure that when something unexpected happens, the damage stops expanding. Think of the kill switch as a circuit breaker for your capital. It does not guarantee profits, but it guarantees that the agent cannot continue trading while you are asleep or unaware. Trading can lose money, including everything, but a kill switch ensures the agent is not the one making it worse after you have already decided to stop.

How does dollar-based order sizing reduce errors?

When an agent calculates position size, it is easy for logic errors or misinterpreted market data to produce wildly wrong numbers. A venue-specific contract might require size in contracts, coins, lots, or shares, each with its own multiplier and minimum increment. If the agent confuses these units, it might submit an order that is ten times too large or ten times too small. Dollar-based sizing removes this ambiguity. You tell the agent to buy one hundred dollars worth of an asset, and the API translates that into the correct number of shares, contracts, or tokens for the specific venue. The agent reasons in a human-readable unit, and the infrastructure handles the venue math. This is especially helpful when an agent trades across multiple market types, such as stocks and perpetual futures, where the sizing conventions differ dramatically. It also simplifies budgeting because your cap and your order sizes share the same unit. You do not need to maintain a lookup table of contract multipliers inside your agent's code. That said, dollar-based sizing is not foolproof. Slippage, leverage, and margin can still cause the actual risk to diverge from the nominal dollar amount. A leveraged perp position sized at one hundred dollars might control a notional exposure that is much larger. You should understand these edge cases, which we cover in our article on where dollar-based order sizing can mislead a trading agent.

What should you verify before going live?

Paper trading lets you observe how the agent behaves without risking capital, but it is only useful if you test the guardrails themselves. Before authorizing live trading, confirm that the budget cap actually rejects oversized orders. Try submitting an order that would exceed your limit and verify that the API returns an error. Confirm that the scoped key cannot perform actions outside its scope, such as requesting a withdrawal or trading a market you did not authorize. Test the kill switch manually during a paper session to see how quickly positions flatten and the key revokes. Review your exit plan to ensure it triggers under the conditions you expect. Check that your withdrawal addresses are correct and immutable, so you know where funds would go if you chose to withdraw manually. It is also worth observing the agent over several sessions to see if it repeats patterns that concern you, such as overtrading or ignoring signals. Paper trading reveals behavior, but only you can judge whether that behavior matches your risk tolerance. Finally, read through the practical checklist for running autonomous trading systems with real money to make sure you have not skipped a step. Only after these checks should you authorize a live key. Even then, consider starting with a live budget that is small enough to be informative but not destructive. Trading can lose money, and a live test is still a test.