How AI agents trade autonomously without ever taking custody of your funds

AI agents can execute trades across stocks, crypto, perpetual futures, options, and prediction markets without ever holding your funds or approving withdrawals. The owner retains the wallet, and the agent operates within a strictly bounded scope that prevents it from moving assets to any address the owner has not pre-approved. This design means autonomous trading is a matter of delegated execution, not delegated custody. The agent decides when and what to trade, but it cannot decide where the underlying assets rest.

What does autonomous trading mean when you keep custody?

In older models of automated trading, autonomy often required custody. You deposited funds into a platform, gave the platform rules, and trusted it to execute and to return your capital. The platform held the private keys or the legal title, and your recourse was contractual. That arrangement conflated execution with custody, which meant that a failure of the execution layer could lead to a loss of the custody layer.

A non-custodial agent reverses that relationship. The owner holds the wallet and issues a scoped key to the agent. The agent sees prices, forms decisions, and sends instructions, but the instructions are only valid if they stay within the owner's limits. Settlement still flows to and from the owner's wallet. The agent never takes possession of the asset, and it never holds the owner's private key. If the owner decides the agent is no longer useful, the owner revokes the key and the agent has no further access. There is no withdrawal request to process and no support ticket to file. The separation is immediate and cryptographic.

The owner uses one API and one key to reach five market types, but custody remains singular. The agent does not need separate accounts at a stock broker, a perps venue, an options venue, or a prediction market. The infrastructure routes orders and normalizes settlement back to the owner's wallet. This unification simplifies oversight, because the owner sees all agent activity through a single set of controls rather than a fragmented dashboard.

How is non-custodial access enforced by design?

The enforcement starts at the key layer. The owner generates a trading key that is cryptographically distinct from the wallet key. The trading key is capable of signing orders, reading balances, and requesting cancellations, but it is incapable of generating valid signatures for withdrawals, ownership transfers, or limit changes. These restrictions are not implemented as UI checkboxes; they are structural properties of the key itself. The infrastructure layer that receives agent instructions validates the key's scope before forwarding anything to a market venue. non-custodial agent trading

Because the agent never sees the wallet's primary key, a compromise of the agent server does not compromise the wallet. An attacker who gains control of the agent gains only the ability to send instructions within the existing scope. They cannot broaden that scope, because the infrastructure will reject requests that require a higher authorization level. They also cannot add a new withdrawal address, because the trading key is mathematically unable to satisfy the multi-factor or owner-only approval required for that action.

This is what non-custodial by construction means. It is not a policy that an operator might change. It is a property of the system that holds as long as the cryptography holds. A policy-based promise could be revised by a company board or a regulator. A construction-based guarantee is enforced by the code that runs the routing layer. As long as the owner retains the primary key, the architecture prevents the agent from becoming a custodian.

What controls sit between an agent and your wallet?

Even with non-custodial keys, an agent that trades poorly can still harm the owner. That is why several layers of controls sit between the agent's intent and the owner's funds. The owner sets a budget cap, which is the maximum notional value the agent may deploy at any given moment. This cap is global across all five market types, so the agent cannot exhaust its allowance in one venue and then migrate to another. Position limits restrict how large a single position can become relative to the total budget, preventing dangerous concentration. evaluate trading agent guardrails step by step

An exit plan defines the conditions under which the agent must reduce or close positions. These conditions can include time limits, drawdown thresholds, or target completions. The panic switch is a manual override that flattens all positions and revokes the agent's key in a single action. All of these controls are enforced by the same routing layer that normalizes orders, so the agent cannot bypass them by using a different API method or by requesting a trade in a different market. The controls are pre-trade gates, not post-trade alerts. Once a limit is reached, the infrastructure returns a rejection, and the order never leaves the system.

The global budget cap is especially important because the agent trades across multiple market types. Without a unified cap, an agent might build correlated risk by taking a stock position and a crypto position that respond to the same macro factor. The owner sets a single number, and the infrastructure tracks exposure across all venues. When the cap is reached, the agent receives a clear rejection and must either free up budget by closing existing positions or wait for owner intervention.

How do MCP and REST connections preserve the custody model?

Agents connect to the infrastructure through two primary paths. One is a direct REST API that accepts signed requests from any program the owner runs. The other is a set of MCP tools that allow an AI assistant inside an editor or chat client to invoke trading actions. In both cases, the connection is authenticated with the same scoped key, and the same budget caps, position limits, and kill switches apply. The MCP server does not receive broader permissions simply because the interface is conversational. mcp trading safety first principles

A common concern is that a language model with access to trading tools might behave unpredictably. The safety model treats the LLM as an untrusted client. The LLM may propose an order, but the infrastructure evaluates that proposal against the owner's hard limits before any execution occurs. The LLM cannot increase its own budget, disable its own exit plan, or invoke the panic switch. The owner remains the only party capable of changing constraints or revoking access.

Developers sometimes ask whether the MCP path is less secure because it feels more conversational. The answer is that both paths end at the same validation layer. The REST API is suited for headless programs that run on a server. The MCP tools are suited for assistants that run inside an AI code editor. The custody model is identical because the authentication and authorization layer is shared. The interface is a matter of workflow preference, not a matter of trust.

Orders are sized in plain US dollars, and the API normalizes venue-specific contract math. This means the agent does not need to calculate contract sizes, margin multipliers, or tick values. It simply specifies a dollar amount and a direction. The infrastructure translates that into the appropriate native format for the relevant venue. This reduces the error surface, because the agent is less likely to make a mistake in unit conversion that could lead to an oversized order. The exact request schema is in the docs; the shape looks like this.

{
  "tool": "place_order",
  "arguments": {
    "market_type": "perps",
    "direction": "buy",
    "notional_usd": 100,
    "instrument": "EXAMPLE"
  }
}

In this example, the agent proposes a one-hundred-dollar position. The infrastructure checks the proposal against the global budget cap, the per-market position limit, and the current exit plan. Only if all constraints are satisfied does the order proceed. The agent does not need to know the venue's margin formula, and it cannot accidentally request a larger size by misusing a multiplier.

This normalization also means that the owner can compare risk across market types using a single unit. A one-hundred-dollar position in a perps venue and a one-hundred-dollar position in an options venue consume the same budget cap amount. The owner does not need to learn each venue's native sizing conventions to audit the agent's exposure. This simplifies oversight and reduces the chance that a unit mismatch leads to an unintended position size.

What risks remain even with perfect controls?

Architecture can prevent theft, but it cannot prevent trading losses. An agent operating within its limits can still lose the entire budget allocated to it. Markets can move quickly, liquidity can evaporate, and an exit plan that looked conservative in testing may prove too slow in a volatile session. Trading can lose money, including everything assigned to the agent. The controls are designed to protect the rest of the wallet and to prevent unauthorized withdrawals, not to guarantee profitable outcomes.

Suppose an agent is given a budget of one thousand dollars and a position limit of two hundred dollars per trade. It could still enter five sequential losing trades and exhaust the budget. The controls prevent a single catastrophic error, but they do not prevent a series of small errors from adding up. That is why many owners pair budget caps with daily or weekly trade count limits, or with a mandatory cooling-off period after a drawdown threshold is hit.

Even the best exit plan cannot guarantee execution at a favorable price during a gap or a liquidity crunch. The agent will send the close order, but the market fills it at the price available. That is a feature of automated trading in general, not a flaw of the agent model. The owner should size the budget cap with the assumption that the entire amount could be lost in adverse conditions.

There is also the risk of owner misconfiguration. If the budget cap is set too high, or the exit plan is defined with loose thresholds, the agent will follow those rules faithfully. The infrastructure enforces the configuration it is given, but it does not judge whether that configuration is prudent. That is why paper trading exists. It lets you observe the agent's behavior against live market data without risking capital. You should run paper trades long enough to see how the agent behaves across different market conditions before you authorize live trading.

How do you evaluate a setup before going live?

Before you authorize a key for live trading, review the scope of the key, the size of the budget cap, and the logic of the exit plan. Confirm that the withdrawal whitelist contains only addresses you control. Verify that the panic switch is reachable without the agent's cooperation, and that you know how to trigger it. Review the agent's prompt or source code to confirm it does not ask for permissions that exceed what the scoped key provides. practical checklist first llm trading agent

Live trading requires explicit owner authorization of a key. Until you provide that authorization, the system remains in paper mode. This is a deliberate friction point. It exists so that you can notice if the agent's behavior diverges from your intent before any capital is at risk. Once you authorize live trading, the same controls continue to apply, but real dollars are now on the line.

After going live, monitor the agent's behavior against the paper trading baseline. If the agent's live trades diverge significantly from its paper behavior, check whether the prompt or the market data feed has changed. Controls are static, but markets are dynamic. A well-designed setup is one where the owner can intervene quickly and where the agent cannot outrun its own safety rails. Revisit your controls periodically. An agent that was safe at a small budget may need tighter limits if you later increase its allocation.