How a single API changes safety for trading agents versus bots

A trading bot executes a fixed script against one account with static credentials, while a trading agent reasons across multiple markets and adapts its decisions in real time. When both connect through a single API, the safety model must shift from simple password rotation to scoped permissions, budget caps, and custody preserving controls that the owner can revoke instantly. This change matters because an agent with broad access can reshape an entire portfolio faster than a bot, so the infrastructure must limit what it can do without limiting why it was built. The API becomes the trust boundary, and its design determines whether the agent is a useful tool or an uncontrolled liability.

What is the difference between a trading bot and a trading agent?

A trading bot is typically a deterministic program that reads a price feed and executes a fixed rule. It might buy when a moving average crosses above a threshold on a single venue, and it stores a static API key in a configuration file. Because the logic is explicit, the failure modes are usually predictable: a stale tick, a mistyped parameter, or a server outage. The safety model for a bot is therefore perimeter based. If the key leaks, you rotate it. If the server crashes, you restart it. The risk is bounded by the script itself, which rarely changes its own instructions. A trading agent, by contrast, makes context dependent decisions. It may connect through MCP tools to an LLM client such as Claude or Cursor, or it may call a REST API directly from a remote process. The agent interprets portfolio state, market data, and prompts to decide whether to enter a stock position, hedge with a perp, or rebalance across markets. Because the agent can adapt, its failures are emergent. It might misread a prompt, hallucinate a strategy, or create unintended correlations across a stock broker and a perps venue. You cannot simply wrap an agent in a firewall and expect it to behave. The safety model must constrain each action dynamically rather than rely on the determinism of the code. The agent is not just faster than a bot; it is qualitatively different in how it can misunderstand its environment.

Why does a single API change the attack surface?

Traditionally, a bot connects to one venue with one credential. If that key leaks, the exposure is limited to that venue's account balance and the bot's trading pair configured in advance. An agent that trades through a single API touches five market types: stocks, crypto, perps, options, and prediction markets. The API normalizes order sizing into plain USD, handles venue specific contract math, and routes instructions to the appropriate backend. This removes friction for the agent, but it also removes the natural speed bumps that separate venues provide. When the API becomes the unified gateway, its safety layer must be richer than any single venue's native controls. A stock broker might offer trading permissions but not withdrawal whitelists. A perps venue might handle margin differently than an options venue. The agent does not need to understand these differences, but the attacker does not either. A compromised agent with a single API key could attempt to move across markets faster than an owner can react. The safety model must therefore centralize defense at the API layer with scoped keys, budget caps, and a unified kill switch. The attack surface shifts from many isolated accounts to one deep integration point, so the API must be designed so that compromise does not mean total loss. The normalization of order sizing is especially important for safety. A bot that calculates its own lot sizes or margin requirements can accidentally submit an oversized order due to a unit mismatch. The API prevents this by accepting notional values in USD and translating them into the correct contract terms internally. However, this convenience also means the agent faces no native friction from the venue's interface. Without API level budget caps, an agent could deploy capital across multiple markets in seconds. The infrastructure must deliberately reintroduce friction in the form of owner approved limits, not as an accident of poor UX, but as a designed safety feature.

How do scoped keys and budget caps work in practice?

The classic bot safety model relies on a single API key with broad trading permissions. If the key leaks, the owner rotates it and checks logs. This model assumes the key is a binary gate: either the bot trades or it does not. An agent trading across five markets needs a more granular approach. Scoped keys allow the owner to define exactly what the agent can do before it starts. One key might allow a $500 daily budget across crypto and perps with a maximum position size of $200 per trade. Another key might permit options strategies but only with defined risk. The agent cannot escalate its own privileges because the API enforces the scope independently of the agent's reasoning. Budget caps are expressed in plain USD, which means the owner thinks in dollars rather than contracts or margin tiers. The API normalizes the notional value of a perp position, an options leg, or a stock order so the agent does not need to compute venue specific math. This prevents unit errors, but it also lets the API enforce a global spending ceiling across all markets. If the agent has spent $400 of its $500 daily cap, a $200 order is rejected regardless of whether the agent believes it has found an opportunity. The limit is mechanical. Scoped API keys let owners roll their own policy or use an agent ready API that handles the enforcement. The exact request schema is in the docs; the shape looks like this:

{
  "market": "perps",
  "direction": "buy",
  "notional_usd": 150,
  "instrument": "EXAMPLEPERP"
}

The key point is that the API checks the notional USD value against the scoped budget before the order reaches any venue. The agent does not bypass this check because it never holds an unscoped key. The owner can issue multiple keys with different scopes for different strategies, which means a compromise in one agent does not cascade into the entire portfolio.

What does custody preserving mean when an agent trades across five markets?

Custody preserving means that funds remain in a wallet the owner controls. The agent can place orders and manage positions, but it can never withdraw funds to itself or to an address the owner has not approved in advance. This applies uniformly across all five market types. Whether the agent is trading stocks through a stock broker, crypto through a chain wallet, perps through a perps venue, options through an options venue, or prediction markets through a prediction market, the settlement layer respects the owner's wallet. The API routes instructions, but it does not hold custody. This design is critical because an agent with reasoning capabilities might be manipulated through prompt injection or social engineering. A compromised bot might simply place bad orders. A compromised agent might attempt to justify a withdrawal by fabricating a reason to rebalance or exit. The API blocks this at the infrastructure level. Withdrawal addresses are only those approved by the owner, and the agent cannot add new ones. Even if the agent's key leaks, the attacker can only trade within the scoped limits, not steal the underlying capital. However, custody preserving does not mean free of risk. The agent can still lose the budgeted amount through poor trades or volatile markets. Trading can lose money, including everything allocated to the agent. The safety model ensures that the maximum loss is bounded by the owner's chosen cap, not by the total account balance. The owner, not the thief, defines the loss boundary. The owner can inspect the wallet directly on the blockchain or through the broker interface at any time, which provides transparency that custodial models do not.

How should kill switches and exit plans work for agents?

A bot can often be stopped by killing a script on a single server. An agent may be distributed across multiple processes, MCP clients, or cloud functions. The owner cannot rely on shutting down a local process to guarantee safety. The kill switch must be API enforced. When the owner triggers it, the API should flatten positions across all markets and revoke the agent's key immediately. This must work even if the agent is unresponsive, hallucinating, or actively hostile. Exit plans such as stop losses, take profits, and time based exits must also be API enforced rather than agent enforced. An agent that is supposed to exit a position at a certain threshold might ignore the rule because of a prompt misunderstanding or because the process crashed. If the exit plan lives in the API, the order is submitted regardless of the agent's state. The API treats the agent as untrusted and the owner as the final authority. Before going live, owners should audit your guardrails and start with hard limits. The kill switch should be tested in paper mode to ensure it can flatten a multi market portfolio without leaving residual exposure. The owner should verify that the agent cannot override, delay, or ignore the switch. If the API allows the agent to cancel the kill command, the safety model is broken. The owner should also confirm that exit plans execute even when the agent is offline, because an agent that relies on its own logic to exit is an agent that can fail silently.

How do you test safety before authorizing real money?

Paper trading exists so that the agent can use the same scoped keys, the same API, and the same logic without risking capital. The orders route to simulated markets. The owner can verify that budget caps block oversized requests, that the kill switch flattens positions correctly, and that exit plans trigger at the intended thresholds. This is not a test of profitability. It is a test of safety mechanics. Live trading requires explicit owner authorization of a key. The API should not allow a paper key to become live by default. This prevents accidents where an agent tested in simulation is accidentally deployed with real money. During paper testing, the owner should also observe how the agent behaves when it hits a limit. Does it retry aggressively? Does it log errors clearly? These behaviors reveal whether the agent respects boundaries or attempts to argue around them. After paper testing succeeds, the owner can authorize a live key with the same scopes or tighter ones. keep a portfolio safe across markets by starting with a small budget and monitoring correlation across markets. Even after authorization, trading can lose money, including everything allocated to the agent. Paper mode proves the guardrails work. It does not prove the strategy works. The owner should treat live authorization as a deliberate, revocable decision, not a single setup.