How non-custodial trading works step by step

Non-custodial trading means your funds stay in a wallet you control while an automated agent places trades on your behalf through scoped permissions. The agent can commit capital up to limits you define, but it cannot withdraw funds to itself or to any address you have not explicitly approved. This design separates the act of trading from the act of holding money, so the infrastructure provider never takes possession of your balance and a compromised agent cannot exit with your capital. The following sections walk through the setup, the controls that keep the wallet under your ownership, and the risks that remain even when custody is never transferred.

What does non-custodial mean in practice?

In a traditional custodial setup, you transfer money to a platform that holds it in a pooled account or internal ledger. The platform records your balance and settles trades against that deposit. If the platform freezes withdrawals, mismanages reserves, or suffers a security breach, your capital is at risk because you no longer control the private keys to those specific funds. You are dependent on the platform's solvency and honesty to recover your money. Non-custodial trading removes that dependency. Your capital remains in a wallet that you create, seed, and back up. The trading infrastructure connects to this wallet through a narrow programmatic channel that is limited to trading actions. The agent can sign orders and manage positions, but it cannot sign a transaction that moves your base capital to an arbitrary destination. Settlement occurs either directly on chain from your wallet or through a broker account that remains in your legal ownership, with the platform acting only as a routing and verification layer. This model is consistent across asset classes. Whether the agent is buying equities through a stock broker, swapping tokens on a decentralized venue, or opening perpetual futures at a perps venue, the custody relationship stays the same. You hold the keys. The agent holds only a temporary, restricted credential. If the trading infrastructure disappears, your funds are still in your wallet. If the agent is compromised, the attacker gains the ability to trade within your limits, but they cannot sweep the wallet.

How does the wallet stay under your control?

Control starts with key ownership. When you set up non-custodial trading, you either connect an existing wallet or generate a new one that you alone control. The platform never asks for your seed phrase or private key. Instead, you grant a scoped role or API key that is bound to specific trading functions. Withdrawal addresses are owner-approved only. This is a critical architectural rule. The agent can send profits or unused collateral back to a wallet address you have pre-approved, but it cannot register a new withdrawal destination. Even if the agent's logic is hijacked through a prompt injection or a compromised model, the underlying infrastructure will not sign a transfer to an unapproved address. The credential is mechanically incapable of general fund movement. Several overlapping controls reinforce this boundary. Budget caps set a maximum notional value the agent can commit in a given period. Position limits restrict concentration in any single symbol or market. A time-bound expiry can automatically invalidate the agent's key after a set date. Most importantly, a panic or kill switch lets you flatten all open positions and revoke the scoped key in a single action, returning full trading control to you immediately. These mechanisms are described in How to set guardrails for a trading agent without giving up custody. Because the enforcement layer sits outside the agent, the limits are not dependent on the agent's reasoning. A misaligned instruction or a hallucinated strategy cannot override the cap. The API evaluates every order against the owner-defined box before it is signed and sent to the market.

What limits does the agent actually have?

The agent operates inside a rigid permissions box that you configure before any live capital is exposed. These constraints are structural, not advisory. They are enforced by the API and, where applicable, by smart contracts that sit between the agent and the market. The agent cannot negotiate around them, and a bug in the agent's logic cannot bypass them because the validation occurs outside the agent's environment.

• ·A budget cap sets the total notional exposure the agent can commit across all orders in a day or across the lifetime of the key.
• ·A position limit defines the maximum size per symbol, expressed in plain US dollars, so the agent does not need to compute venue-specific contract multipliers or decimal adjustments.
• ·An approved market list restricts the agent to specific asset classes, such as equities, crypto, or prediction markets, while blocking unauthorized venues.
• ·An exit plan places pre-scheduled or conditional orders that close positions if prices move against you, and the agent cannot cancel these protective orders without explicit owner approval.

These controls are rooted in the safety model discussed in How the safety model for MCP trading tools works from first principles. The central idea is that the limits should be simple and deterministic. They do not try to predict whether a trade is good or bad. They simply prevent any single sequence of orders from exceeding the capital or concentration boundaries you have chosen. This separation of strategy from safety means you can iterate on the agent's logic without worrying that a coding error will drain the wallet.

How do you authorize and revoke access?

Access follows a two-stage pattern: simulation first, then explicit live authorization. When you build an agent, you connect it through MCP tools or the REST API and run it in paper trading mode. This mode uses a dedicated test key and simulated balances. You can observe how the agent interprets natural language prompts, how it sizes orders, and how the safety layer responds to edge cases such as duplicate requests or oversized intents. No real money is at risk during this phase, and the paper key cannot accidentally touch live markets. When you decide to trade live, you must take a deliberate owner action to authorize a new live key. The system does not auto-promote paper credentials. The live key inherits the guardrails you tested, and you can adjust them before activation. You might lower the budget cap for the first week, restrict the agent to a single market type, or set a short expiry so the key automatically becomes invalid after a trial period. Revocation is immediate and unilateral. The kill switch flattens open positions and invalidates the scoped key in a single operation. You can trigger it manually or through a webhook you control. Because the funds are in your wallet, revocation does not require a withdrawal request, a waiting period, or platform approval. The agent simply loses the ability to sign new orders, and any pending orders that have not yet reached the venue are canceled. If you are building your first agent, How developers can paper trade safely with AI agents offers a practical starting point.

What happens when the agent places an order?

When the agent decides to trade, it constructs an intent denominated in plain US dollars. The API then normalizes this intent into the precise units required by the destination venue, whether that venue speaks in shares, lots, tokens, or contracts. You do not need to embed venue-specific math, tick sizes, or margin formulas into your agent logic. The agent sends an instruction to buy a specific dollar amount of an asset, and the platform translates that into the correct order parameters. The scoped key signs the normalized intent. Before the order is routed, the API checks it against your guardrails. If the intent would exceed the budget cap, violate a position limit, or target an unapproved market, the request is rejected and the agent receives an error. The agent cannot retry with a modified size to sneak past the limit, because the validation is based on the total notional impact, not the text of the request. If the intent passes validation, it is forwarded to the relevant stock broker, crypto venue, perps venue, or prediction market. Settlement depends on the market infrastructure. For on-chain venues, settlement may occur through a smart contract that locks collateral from your wallet and releases it according to the trade outcome. For traditional brokers, settlement follows the standard clearing cycle, but the cash and securities remain in your brokerage account under your legal ownership. In all cases, the agent never takes possession of the proceeds. Profits, losses, and collateral adjustments flow back to accounts or wallets you control. The platform acts as a router and enforcer, not a custodian.

What risks remain even with non-custodial design?

Non-custodial architecture removes the risk that the platform or agent will steal your funds, but it does not remove market risk. The agent can still lose money on individual trades, and a sequence of losing trades can exhaust the entire budget you allocated. If you use leveraged instruments such as perpetual futures or options, losses can exceed the initial margin and consume your collateral rapidly. You can lose everything you have allocated to the agent, and you should trade only with capital you can afford to lose. There are also operational risks that sit between the agent and the market. A bug in the agent's reasoning, a misinterpreted data feed, or a delay in the API connection can cause unintended orders. The safety limits are designed to catch these errors, but they are calibrated to your predefined thresholds, not to real-time market conditions. A sudden gap in liquidity or a rapid price move can fill orders at levels far from your expectations before an exit plan triggers. Finally, key management remains your responsibility. If your owner seed phrase or private key is exposed, an attacker can bypass all agent-level restrictions by acting directly as the owner. Non-custodial trading protects you from a compromised agent, but it cannot protect you from a compromised owner key. Store your recovery phrase offline, review your guardrails regularly, and treat the kill switch as a safety net of last resort, not a guarantee of profit.