How algorithmic traders keep self-custody while using MCP agents

Algorithmic traders can automate strategies across stocks, crypto, perps, options, and prediction markets through a single MCP connection without ever depositing funds into a third-party custodian. The owner retains control of the wallet, while the agent receives scoped authority to place orders within predefined limits. The agent cannot withdraw funds, change withdrawal addresses, or operate outside its budget. This architecture separates execution authority from asset ownership, which is the core of non-custodial agentic trading.

What does non-custodial mean for an MCP trading agent?

In traditional algorithmic setups, the trading program or API key often requires a deposit into a centralized balance sheet or sub-account controlled by the venue or an intermediary. The architecture described here removes that requirement entirely. Funds remain in a wallet the owner controls through standard cryptographic keys. The agent connects through MCP or a REST API and receives a scoped key that can only initiate orders and read positions. It cannot move assets to an external address unless that address has been explicitly approved by the owner in advance, and it cannot approve new addresses on its own. The distinction is important because the agent has execution capability but not custody capability. Even if the agent's logic is compromised, the capital is not sitting in an account the attacker can drain. This is non-custodial by construction, not by policy. The owner can revoke the agent's key at any time, and the underlying assets remain untouched in the owner's wallet. This design changes the fundamental trust assumption. The trader does not need to trust the API provider with their capital, only with the accurate execution of scoped instructions.

How do scoped keys and budget caps limit agent authority?

Scoped keys are the primary mechanism for enforcing boundaries. When a developer provisions an agent, they define a budget cap denominated in plain US dollars. The API translates this cap into the correct contract sizes, lot sizes, and margin requirements across the five supported market types. The agent does not need to understand venue-specific math. It sends an order for a dollar amount, and the infrastructure normalizes the sizing. This removes an entire category of errors where an agent might miscompute leverage, tick size, or notional value. Beyond the total budget, owners can set position limits per market, maximum order sizes, and allowed instrument types. For example, an owner might permit the agent to trade stocks and prediction markets while prohibiting perpetual futures. These constraints are enforced server side, so the agent cannot override them by crafting a clever request. The key itself is cryptographically bound to these limits. If the agent hits its budget ceiling, the API rejects further orders until the owner adjusts the cap or the key resets. The server side enforcement means the agent cannot simply edit its local configuration to bypass rules. This is critical for unattended automation where the owner is not reviewing every order in real time. The design ensures that the agent's authority is strictly bounded at the infrastructure level, not at the application level. Developers who want to understand the full key scoping model can read our guide on how to secure an AI trading agent without giving up custody.

How do MCP clients connect to live markets safely?

Agents connect through the Model Context Protocol, which means Claude, Cursor, and other MCP clients can discover trading tools as standard functions. The agent does not need to manage raw TCP connections or venue-specific authentication handshakes. Instead, it calls a tool such as place_order with parameters like symbol, side, and dollar amount. The MCP layer routes this to the REST API, which validates the request against the scoped key and budget constraints. Before an agent can trade live capital, the owner must explicitly authorize the key for production. Until that authorization is granted, the agent operates in a paper trading environment that simulates fills and PnL without touching real funds. This authorization step is a deliberate human gate. It prevents a developer from accidentally deploying a test agent against a live wallet. The exact request schema is in the docs; the shape looks like this:

{
  "key": "YOUR_KEY",
  "symbol": "EXAMPLE_SYMBOL",
  "side": "buy",
  "usd_amount": 1000
}

The API returns a confirmation or rejection based on the current budget, position limits, and market state. The agent reads the response and decides its next step, but it never handles private keys or withdrawal credentials. The paper trading environment is particularly useful for testing multi-agent strategies before any capital is exposed. Developers can observe how agents behave under realistic latency and rejection conditions without financial risk. Only after the owner reviews the paper results and explicitly authorizes the key does the agent gain the ability to send live orders. This two stage deployment model, paper then live, is enforced by the key state, not by a configuration flag the agent can toggle.

What happens when you need to stop an agent immediately?

Every agent deployment includes a panic switch, sometimes called a kill switch, that the owner can trigger through the dashboard or a direct API call. When activated, the switch performs two operations in sequence. First, it sends flattening orders to close all open positions across the five market types. Second, it revokes the agent's scoped key, rendering it unable to place new orders or read private data. The owner retains full wallet access throughout this process. The kill switch is designed to handle several scenarios where the owner needs immediate control:

• ·The agent's strategy is behaving unexpectedly.
• ·The market is moving too fast for the agent to manage.
• ·The owner wants to pause automation for maintenance or review.
• ·A correlated event hits multiple positions at once.

There is no delay or approval queue for the owner. The flattening logic respects the same dollar-based sizing and venue normalization as normal orders, so the agent does not leave odd lot positions or fragmented exposures behind. This immediate revocation capability is part of why the architecture is non-custodial. The owner can always return to manual control without waiting for a third party to process a withdrawal request. In practice, developers should also define an exit plan before deployment. An exit plan specifies target conditions for closing positions, such as time bounds or loss thresholds, and works alongside the kill switch as a softer circuit breaker. The exit plan is evaluated by the agent or the infrastructure depending on implementation, but the kill switch remains the owner's ultimate override. It is worth noting that flattening in volatile markets may result in slippage or losses, and trading can lose money, including everything. The kill switch prevents further damage but does not erase losses already incurred.

How does dollar-based sizing reduce complexity across market types?

Algorithmic traders traditionally face a fragmented landscape where each venue uses its own unit conventions. A perps venue might use contracts sized in coins, an options venue might quote in lots of one hundred underlying shares, and a prediction market might use binary shares with their own tick increment. The API presented here normalizes all of this by accepting orders in plain US dollars. When an agent sends an order for one thousand dollars, the infrastructure calculates the correct number of contracts, shares, or lots for that specific venue and instrument. The agent does not maintain conversion tables or venue-specific sizing logic. This reduces the surface area for bugs, especially in multi-agent systems where several agents might share capital. It also makes budgeting intuitive. An owner can say the agent may spend fifty thousand dollars in total, and that cap applies across stocks, crypto, perps, options, and prediction markets without manual conversion. The normalization happens after the safety checks, so an order that would exceed the budget is rejected before any sizing math is applied. This ensures that the budget cap is strictly enforced in the unit the owner understands. Suppose an agent attempts to buy two thousand dollars of an option while only one thousand dollars remains in the budget. The API rejects the request immediately, and the agent never needs to know how many option contracts that would have represented. This abstraction layer keeps the agent's logic focused on strategy rather than contract mechanics. Developers who want to understand how budget enforcement interacts with position limits can read more about how an agent trades within a hard budget it cannot exceed.

How should developers think about risk when agents trade multiple markets?

Trading can lose money, including everything, and an agent operating across multiple market types amplifies the need for careful risk design. A strategy that works in one asset class may behave differently when exposed to another, and correlations can shift quickly. The architecture provides guardrails, but guardrails do not eliminate risk. Owners should treat the budget cap as a maximum loss they are willing to absorb, not as a theoretical limit that will never be reached. Position limits per market help prevent overconcentration, and the audit log provides a complete record of every decision, order, and rejection for post-trade review. Observability is not optional. It is part of the safety model. The article on how to keep a multi-market agent portfolio from blowing up covers practical steps for setting those limits. The key architectural principle is that the owner defines the risk envelope, the API enforces it mechanically, and the agent operates inside it. The agent does not decide its own risk tolerance, and it cannot renegotiate its constraints. Imagine a scenario where an agent is allowed to trade stocks and crypto. A sudden macro event causes both to drop, and the agent hits its position limits in both markets simultaneously. The limits prevent it from doubling down to chase losses, but the owner still bears the loss on the existing positions. This is why the budget cap and the kill switch exist as complementary tools. The budget defines the maximum exposure, the position limits define the maximum concentration, and the kill switch provides an immediate escape. Together they form a layered defense, but they do not guarantee profitability.

How does non-custodial design change the trust model for developers?

Developers building on this infrastructure do not need to trust a custodian with their users' funds. They also do not need to build their own key management, withdrawal whitelisting, or audit pipelines from scratch. The trust model collapses to two simple assertions. The owner controls the wallet, and the API enforces the scoped rules. Developers can focus on strategy logic, data ingestion, and agent behavior rather than building a brokerage backend. For teams building multi-agent systems, this separation is especially useful. One agent might handle prediction market signals, another might rebalance a stock portfolio, and both can share the same capital pool without either having unilateral withdrawal rights. Because each agent has its own scoped key and budget, the failure of one agent does not compromise the capital available to others. The audit trail ensures that every action is attributable and reviewable, which matters for debugging and accountability. You can read more about that in our post on how audit logs keep MCP trading agents accountable. The non-custodial approach also simplifies compliance discussions for developers who serve clients. Since funds never sit in a developer-controlled account, the developer is not acting as a custodian. The client retains direct ownership, and the developer provides software that operates within scoped permissions. This separation of software and custody is clean architecturally and reduces counterparty risk for all parties involved.