How the safety model for MCP trading tools works from first principles

MCP trading tools connect large language models to live markets through a single API, but the connection is designed so that the agent can only spend within limits that the owner sets at the wallet and key level. The model is non-custodial by construction, meaning the owner retains control of the funds, the agent cannot withdraw to itself, and every safety rule is enforced outside the LLM's reasoning process. This article explains how that safety model works from first principles, starting with custody, moving through scoped permissions and budget enforcement, and ending with the kill switch.

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

An MCP trading tool is a bridge. On one side sits an AI agent running inside Claude, Cursor, or another MCP client. On the other side sits a set of financial venues: a stock broker, a crypto exchange, a perps venue, an options venue, and a prediction market. The tool translates the agent's intent into orders, but it does not take custody of the owner's capital. The funds remain in a wallet or brokerage account that the owner controls directly through private keys or standard brokerage authentication. The agent receives a scoped key that can sign orders and read positions, yet it cannot unilaterally move funds to a new address. Withdrawal addresses are owner-approved only, which means that even a fully compromised agent cannot empty the account into an external wallet it controls. This is the foundational difference between an agentic trading setup and a traditional custodial bot. In a custodial model, the bot or the platform holds the keys to the kingdom, and the owner must trust that the operator will not misuse them. In the MCP model described here, the agent holds only a tightly limited lease on a specific set of actions. The lease is revocable, time-bound, and strictly less powerful than the owner's own credentials. If the agent misbehaves, or if the owner's strategy changes, the lease can be canceled without moving funds or closing the underlying account. Non-custodial by construction means the safety property is not an aftermarket add-on. It is baked into the architecture. The API cannot accidentally become custodial because the protocol does not support it. The agent's key is derived from the owner's wallet in a way that preserves the owner's ultimate control, and the API provider never holds the owner's private keys. This removes a whole category of platform risk. If the API infrastructure were to suffer a breach, the attack surface would be limited to the scoped keys currently active, not to the aggregated deposits of every user. Non-custodial trading for AI agents covers the mechanics of this arrangement in more detail, but the principle is simple: the agent is a guest in the house, not the owner, and the locks on the doors are physical, not polite requests.

How do scoped keys prevent a runaway agent?

A scoped key is a credential that carries its own restrictions. It is not a master password. It is an authorization token that the infrastructure checks on every single request. Suppose the owner creates a key that is permitted to trade stocks and perps, but not options or prediction markets. The agent might ask to buy an option contract, and the LLM might generate a perfectly formed JSON request with the correct symbol and price, but the API will reject it because the key scope does not include that market. The enforcement happens at the API gateway, not inside the LLM's reasoning loop. This matters because LLMs are probabilistic. They can hallucinate parameters, misread instructions, or be jailbroken through clever prompting. A safety model that relies on the LLM to police itself is not a safety model at all. It is a hope dressed up as a system prompt. Scoped keys turn hope into architecture. The key defines a hard boundary around what the agent can touch, and that boundary is checked by deterministic code that does not parse nuance. The scope can also include position limits, so a key might be allowed to trade perps but only up to a certain notional size. This creates defense in depth. Even if the agent's strategy logic is flawed and repeatedly tries to pyramid into a losing position, the key scope acts as a backstop. Even if the MCP server itself were compromised, an attacker who extracted the key would still be trapped inside its scope. They could not expand permissions or remove withdrawal restrictions, because those invariants are bound to the key at creation time and validated by the settlement layer. How the safety model for trading agents differs from trading bots explores why this architectural boundary matters more for agents than for traditional deterministic bots, because agents have open-ended reasoning capabilities that make prompt-level guardrails inherently unreliable.

Why are budget caps enforced at the wallet level rather than in the prompt?

The most common mistake in LLM trading is to write a prompt that says, "Only spend up to one thousand dollars," and then trust the model to count. This is not a budget cap. It is a suggestion that the LLM may ignore, misunderstand, or simply fail to compute correctly when context length grows. A genuine budget cap is a programmatic rule enforced by the trading infrastructure, often at the smart contract or wallet level, that prevents any order from executing if it would push total exposure beyond the limit. The owner sets the cap before the agent starts. The agent may reason about trade sizing in plain US dollars, but the API normalizes venue-specific contract math and checks the cap against the actual notional value of the proposed order. If the cap is ten thousand dollars and the agent is already at nine thousand five hundred, a five hundred dollar order will pass and a one thousand dollar order will be rejected. The LLM is not consulted in this decision. It simply receives an error, the same way any over-budget API client would. This separation of concerns is critical. The LLM handles strategy and intent. The infrastructure handles limits and execution. Prompts are soft and malleable. Wallet-level rules are hard and cryptographic. The wallet-level enforcement also protects against collusion or confusion between multiple agents. If the owner runs three different strategies from three different MCP clients, they all draw from the same budget cap. The limit is global to the wallet, not per-agent, which prevents a fleet of agents from collectively exceeding the owner's risk tolerance. Relying on the former for financial security is like asking a conversational partner to remember your credit limit. Relying on the latter is like having the card itself decline the charge. How an AI agent trades within a hard budget it cannot exceed walks through the mechanics of this enforcement, but the first principle is straightforward: never let a probabilistic model be the authority on spending limits.

What happens when an agent hits a limit or receives a kill command?

When a limit is breached, the order is rejected at the gate. The agent may retry with a smaller size, or it may log the error and wait, but it cannot bypass the cap through persistence or creative prompting. If the owner decides the agent is behaving erratically, or if market conditions change suddenly, the owner can trigger a kill switch. The kill switch flattens open positions, cancels pending orders, and revokes the scoped key. It is an owner-level command that the agent cannot override, delay, or negotiate. The agent has no access to the key revocation endpoint. It does not even know the revocation key exists. Once the key is dead, the agent becomes a passive observer. It can still read market data if the owner permits it, but it can no longer place orders or manage positions. The flattening process is itself subject to safety rules. The kill switch does not dump positions into illiquid markets without regard for slippage. It follows a pre-configured exit plan if one exists, or it places market orders within the same scoped permissions. The goal is to stop the bleeding, not to cause a new wound through reckless liquidation. This is the final layer of the safety model. All the previous layers, custody, scoped keys, and budget caps, are designed to prevent disaster. The kill switch is designed to stop disaster if it is already in motion. The owner may also configure an exit plan, a predefined set of rules for how to close positions gracefully before the kill switch is needed. But when speed matters, the kill switch is absolute. How to build a kill switch your trading agent cannot override explains the implementation details, but the principle is that the switch must be external to the agent, irreversible from the agent's perspective, and executable by the human in a single action.

How does the API normalize risk across five market types?

Trading across stocks, crypto, perps, options, and prediction markets introduces a combinatorial risk surface. Each venue has its own tick sizes, margin formulas, leverage rules, and contract denominations. An agent that reasons in raw contracts might accidentally open a position ten times larger than intended because it confused the contract multiplier with the notional value. It might send an order for one hundred options contracts thinking it is risking one hundred dollars, when in reality it is exposing the account to thousands. The API addresses this by accepting orders sized in plain US dollars. The owner or the agent says, "Risk five hundred dollars on this trade," and the API translates that into the correct number of shares, contracts, tokens, or prediction market shares for the target venue. This normalization does not eliminate risk. Trading can lose money, including everything. What it does is remove a class of unit errors that are especially dangerous when an autonomous agent is placing orders across unfamiliar market structures. The agent thinks in dollars. The infrastructure thinks in venue-native units. The translation layer is deterministic, tested, and separate from the LLM's reasoning. It also means the owner can set a single budget cap in dollars and have it apply consistently across a portfolio that contains both stocks and perps, without manually converting between shares and contract sizes. Normalization also simplifies auditing. When every trade is recorded in a common unit, the owner can review a unified log and see exactly how much capital was deployed across all five markets. The agent does not need to understand the difference between a stock lot and a prediction market share. It expresses intent in the universal language of dollars, and the API translates intent into execution. The risk of leverage remains. The risk of adverse price movement remains. But the risk of a math error caused by mismatched units is sharply reduced.

Where does the human stay in the loop?

Live trading requires explicit owner authorization of a key. The agent cannot simply wake up and start trading real money. The owner must approve the key, set the scopes, define the budget cap, and optionally pre-approve withdrawal addresses. Before that authorization happens, the agent can operate in paper trading mode, where it executes against simulated markets with no real capital at risk. This lets the owner observe behavior, test the integration, refine prompts, and discover edge cases in the agent's logic without financial exposure. The authorization step also serves as a natural moment for the owner to review the agent's paper trading record. The owner can see whether the agent respected simulated limits, whether it made coherent decisions, and whether its behavior aligns with the intended strategy. This record becomes the basis for trust. The owner is not trusting the LLM's reasoning in the abstract. The owner is trusting the observed behavior of a specific agent operating under a specific set of rules. Even after going live, the owner retains the panic button. The kill switch is human-operated. Position limits are human-defined. The loop is tight at the start and looser during operation, but the human never leaves the circuit entirely. The safety model assumes the agent will eventually make a mistake, and it ensures that the mistake is bounded by rules the human set in advance. The human is not there to micromanage every trade. The human is there to set the guardrails, authorize the connection, and retain the power to disconnect. This is supervised autonomy, not unsupervised automation. The model respects the fact that markets are unpredictable and that LLMs are imperfect, and it places the ultimate control where it belongs, with the person whose money is at stake.