How to build a trading agent that handles real money safely

An agentic trading system is software that uses an AI model to decide when to place, modify, or close orders across multiple markets, but it is not an unsupervised black box that operates outside human boundaries. Before it touches real money, the developer must implement hard limits, non-custodial access, and explicit owner authorization so the agent can execute within a bounded scope but can never steal funds or exceed its budget. Trading can lose money, and an agent can execute mistakes faster than a human, so the safety envelope is the primary defense rather than an afterthought. This guide walks through the architecture, safety controls, and connection patterns you need to build such a system responsibly.

What does an agentic trading system actually do?

At its core, the system is a continuous loop that ingests data, reasons about state, and emits instructions. The agent, which may be an LLM or a deterministic program, observes prices, signals, or portfolio composition and decides whether to place, modify, or cancel orders. That decision is handed to an execution layer that translates intent into a concrete request. The agent itself does not hold money, manage private keys, or store brokerage credentials. It holds only a scoped credential that allows it to send instructions to a single API. The API then routes those instructions to the correct market, whether that is a stock broker, a crypto venue, a perps venue, an options venue, or a prediction market. Because the API unifies these five market types behind one interface, the agent can reason in plain US dollars rather than learning venue-specific contract multipliers, leverage tiers, or tick sizes. A request to buy one hundred fifty dollars of exposure is expressed the same way across all markets, and the infrastructure normalizes the math. The data pipeline feeds the agent, but the agent should not blindly trust it; stale or corrupt data should be caught by sanity checks in the strategy code before an order is ever formed. If the agent sends an invalid request, the API rejects it and returns a clear error, which the agent can then incorporate into its next reasoning cycle. The developer's responsibility is to build the reasoning loop and validate the strategy logic. The infrastructure handles settlement, margin tracking, and position reconciliation. This separation of concerns lets you iterate on the strategy without rebuilding plumbing for each market.

How do you keep funds non-custodial while the agent trades?

Non-custodial means the owner of the capital retains full control of the underlying wallet or brokerage account at all times. The agent receives a scoped key that can submit orders within predefined boundaries, but it cannot withdraw funds, change account ownership, disable safety controls, or create new keys. Withdrawal addresses are owner-approved only, and the agent key has no permission to alter them. This model is enforced by construction, not by policy or trust. Even if the agent is compromised or the key is leaked, an attacker cannot sweep the account because the key simply lacks the privileges. Because the owner never transfers funds into a third-party pool, disconnecting the agent is as simple as revoking the scoped key. This separation also protects the developer: because the agent never holds the root keys, the developer cannot be accused of custody or control over the owner's funds. The API sits between the agent and every market, and it enforces these boundaries at the infrastructure level. You can read more about the architecture in non-custodial trading for AI agents. When you connect a stock broker or a crypto venue, the owner still authenticates directly with that venue and authorizes the API connection. The agent never sees the root password, seed phrase, or master API key. The scoped key is a separate credential with a narrow permission set. If you revoke it, the underlying account remains untouched.

What safety controls should you wire in before going live?

Safety controls are hard constraints enforced by the API and the key infrastructure, not polite suggestions embedded in a system prompt. You should treat them as part of the deployment checklist, not as an afterthought. The controls exist to bound the agent's behavior so that even if the strategy is flawed, the data is stale, or the model hallucinates an order, the resulting damage is limited to a predefined envelope. You configure these controls when you create the scoped key, and the API rejects any request that violates them. Test every control in paper mode before attaching real capital, because a misconfigured limit is only discovered when it is triggered.

• ·Scoped keys: the credential is limited to specific markets, order types, and maximum sizes. It cannot be reused for admin functions or account management.
• ·Budget caps: a hard ceiling on the total notional value the agent can deploy across all positions. Once the cap is reached, the API rejects new orders until the owner resets or raises the limit.
• ·Position limits: a per-symbol or per-market maximum that prevents the agent from concentrating too much capital in one direction or instrument.
• ·Exit plans: automated rules for take-profit, stop-loss, or time-based exits that execute independently of the agent process. They fire even if the agent crashes or hangs.
• ·Panic/kill switch: an owner-operated mechanism that immediately flattens all open positions and revokes the agent's key, stopping all further activity.

These controls work in layers. A scoped key narrows what the agent can touch. A budget cap ensures that even if the strategy fails repeatedly, the damage is bounded. Position limits prevent a single bad signal from turning into a concentrated loss. Exit plans remove the requirement that the agent be online to manage risk, and they execute with infrastructure-level reliability rather than model-level intent. The kill switch gives the owner a single action to stop everything, regardless of what the agent is currently doing. You should configure all of these before you generate the live key, and you should test them in paper mode to confirm they trigger as expected. For detailed guidance on configuring budgets, see How to set spend caps and drawdown limits for trading agents. For an explanation of why key scoping matters, see Why AI agents need scoped API keys when trading real money.

How do you connect the agent to markets?

There are two connection patterns for developers. If your agent runs inside an MCP client such as Claude, Cursor, or another compatible host, you can expose trading actions as MCP tools. The agent invokes a tool, the MCP server validates the request against the safety controls, and then routes it to the API. If you are building a standalone service or a custom bot, you can call the REST API directly from your code. REST is better for scheduled or event-driven systems, while MCP is useful when you want the model to interactively confirm a trade before submission. In both cases, the agent authenticates with the same scoped key, and the same budget caps, position limits, and kill switch apply. The choice depends on whether you want the LLM to reason inside a chat interface or inside a headless process that runs on a schedule or event trigger.

# The exact request schema is in the docs; the shape looks like this
curl -X POST "https://api.felix.trade/..." \
  -H "Authorization: Bearer YOUR_KEY" \
  -d '{
    "market": "perps",
    "symbol": "BTC",
    "side": "buy",
    "notional_usd": 150
  }'

The API returns the normalized result, and the underlying venue handles settlement. The agent does not need to know contract multipliers, margin tiers, or decimal precision. It simply states the dollar amount and the desired direction. This uniformity reduces the complexity of multi-market strategies because the developer does not need to maintain separate sizing logic for a stock broker, a perps venue, and a prediction market. For a practical walkthrough of running an agent through MCP, see How to run a non-custodial trading agent through MCP: a practical checklist.

What does the authorization path look like for live trading?

Paper trading exists so you can test the full loop, including data ingestion, reasoning, order formatting, error handling, and safety control triggers, without risking capital. You should run paper mode until you are confident that the agent behaves predictably under different market conditions, including volatile periods and low-liquidity windows. When you are ready to trade real money, the owner must explicitly authorize the key for live access. This is not a hidden toggle or a default setting. The owner reviews the attached budget cap, the allowed markets, the position limits, and the approved withdrawal addresses, then confirms the authorization. The authorization event is logged with a timestamp and the exact parameters, creating an audit trail for later review. If you change the budget or market scope after initial authorization, the owner must approve the updated configuration before the new limits take effect. Until that approval happens, the key is blocked from live order submission. This deliberate friction prevents accidental deployment and creates a clear audit boundary. The owner acknowledges the risk and the scope before any real capital moves. If you are both the developer and the owner, you still perform this step to force a final review. Trading can lose money, including the entire budget allocated to the agent, so this review step is essential. After authorization, the agent operates within the live envelope, but the owner can still adjust the budget, revoke the key, or hit the kill switch at any time.

How do you monitor and shut down safely?

An agentic system is not finished when it starts trading. You need observability into what the agent is doing, what the API is enforcing, and what the market positions look like in real time. Logs should show the agent's decisions, the API's validation results, and the market's fill confirmations. You should also monitor the account level independently of the agent, using the venue's native interface or a separate portfolio tracker, so you can detect drift or bugs that the agent does not report. You should set external alerts for budget cap utilization and kill switch events so you are notified even if you are not watching the logs. The most important control is the panic switch. If the strategy behaves unexpectedly, if market conditions shift violently, or if you simply want to stop, the owner can trigger the kill switch. This action flattens all open positions and revokes the agent key in one step. The agent cannot override this. It is a unilateral owner action that takes precedence over any open order or pending instruction. After a shutdown, you should review the logs, compare the agent's intended trades against actual fills, and inspect whether any safety control was triggered correctly. Adjust the strategy or limits, and generate a new scoped key if you choose to resume. Never restart live trading after an incident without inspecting the root cause and confirming that the envelope of risk is still appropriate.