How to run a non-custodial trading agent through MCP: a practical checklist

Non-custodial MCP trading means the agent executes orders through one API but cannot withdraw funds or exceed scoped limits. The owner keeps custody of the wallet and approves only specific trading actions and budget caps. Before you connect an MCP client to a live account, verify that the agent can trade but cannot move capital to an external destination. A practical checklist covers key scoping, spend limits, paper testing, and a kill switch before any live capital is exposed, because trading can lose the entire allocated budget.

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

In a non-custodial setup, the agent does not hold your assets in an account it controls. Instead, you connect a wallet or brokerage relationship that you own, and the agent receives scoped permission to place orders within that environment. The trading API built for AI agents normalizes order sizing in plain US dollars across stocks, crypto, perpetual futures, options, and prediction markets, but the agent never has the ability to withdraw funds to an external address or change ownership of the account. Withdrawal addresses, if supported by the underlying venue, are owner-approved only and cannot be altered by the agent. This architecture is non-custodial by construction, not by policy. Even if the agent is compromised, the blast radius is limited to the trading budget you have explicitly authorized. You should verify this property before you grant any access. Read the permission model and confirm that the API separates trading actions from administrative or withdrawal actions. If the underlying venue conflates these permissions, you may need to add external controls or reconsider whether that venue is appropriate for agentic trading. The goal is to ensure that the worst-case scenario is a loss of the allocated trading budget, not a loss of the entire wallet balance. Non-custodial design also simplifies compliance and operational transparency, because the owner retains final control over where funds reside at all times. You should also confirm that the API provider does not commingle your funds with other users in a pooled account. In a properly non-custodial arrangement, your capital sits in your own wallet or brokerage account, and the API merely routes signed instructions. If you cannot identify the underlying account or wallet address, pause the setup and ask for clarification. Transparency about fund location is a prerequisite, not an optional feature.

How do you scope API keys before connecting an agent?

Scoped keys are the foundation of safe agentic trading. Before you connect Claude, Cursor, or another MCP client to your trading infrastructure, you should create a key that is restricted to trading actions only. That means the key can place and cancel orders, read balances and positions, and query market data, but it cannot perform administrative functions or initiate withdrawals. You should also bind the key to a specific IP range or runtime environment if your setup allows it, so the credentials are not useful if extracted elsewhere. Store the key in a secrets manager or environment variable, never in a repository or prompt context. If you need to rotate credentials, do so before the agent starts its session, because revoking a live key will immediately halt trading. You can learn more about safe runtime practices in our guide on how to run an AI trading agent with real money safely. In addition to action scoping, consider time scoping. Some systems allow you to issue keys that expire after a set duration. Short-lived keys force you to reauthorize the agent periodically, which adds friction but also prevents a forgotten key from running unattended for months. You should also label keys clearly so you know which agent or strategy they belong to. If you run multiple agents, each should have its own key with its own limits. Never reuse a master key across different strategies, because a bug in one agent could exhaust the budget allocated to another. Logging and audit trails should record which key placed which order, so you can trace any anomaly back to the exact source. When you generate the key, disable any permissions that are not strictly necessary. If the agent does not need historical data, do not grant data export rights. If it does not need to modify alerts or notifications, leave those endpoints unpermissioned. The principle of least privilege applies to algorithmic trading just as it applies to any other software system. Review the permission list quarterly, because API providers may add new endpoints that default to enabled for existing keys.

What budget and position limits should you set first?

Budget caps exist to prevent an agent from deploying more capital than you intended. You should set a hard spend limit in US dollars at the API level, separate from any strategy logic inside the agent. This cap should be low enough that losing it entirely would not change your financial situation. Position limits are equally important. An agent should not be allowed to open a position so large that a normal market move would wipe out the allocated budget. You can configure these constraints through the API before the agent sees a price feed. For a deeper walkthrough on sizing, see our article on how to set spend caps and drawdown limits. In addition to a spend cap, define a drawdown limit. If the agent loses a predetermined percentage of its budget, trading halts automatically and the key is suspended until you review the logs. These limits are not suggestions. They are circuit breakers that protect you from both market volatility and agent error.

• ·Hard spend cap in absolute US dollars
• ·Per-market position size limit
• ·Daily or hourly order count limit
• ·Drawdown threshold that suspends the key

When you set these limits, think in absolute dollars, not in percentage returns. An agent does not know your net worth, so a strategy that risks two percent per trade might still hit a cumulative drawdown that exceeds your comfort level. The API should enforce the dollar cap regardless of what the agent believes is a good opportunity. You should also set per-market limits if you are trading across multiple asset classes. For example, you might allow five hundred dollars in prediction markets and two thousand dollars in stocks, with no ability to reallocate without owner approval. This prevents the agent from chasing volatility in a single market and concentrating risk. Finally, write down the rationale for each number. If you later feel tempted to raise a limit during a winning streak, refer back to your written rationale to avoid emotional decisions. Consider also setting a maximum order count per day or per hour. An agent that places dozens of orders in a short window may be malfunctioning or falling into a high-frequency loop that racks up fees. Order count limits act as a rate limit on the agent's activity, giving you time to intervene if the behavior diverges from the expected pace.

How do you test the full loop before live trading?

Paper trading lets you observe how an agent behaves when it believes it is trading real money, without exposing capital. You should run the agent against the paper environment for enough time to cover multiple market conditions, including periods of high volatility and low liquidity. Watch for unexpected behaviors such as repeated order amendments, excessive frequency, or positions that drift outside stated limits. Test the revocation path during paper trading. Manually trigger the kill switch and confirm that the agent flattens positions and loses access within the expected time window. You should also test the reconnection flow. If the MCP server restarts, does the agent resume with the same constraints, or does it need to renegotiate permissions? Document every failure mode you observe. Only after the agent behaves predictably in paper should you authorize live trading, and that authorization should require an explicit owner action rather than a default setting. During paper testing, simulate edge cases that are rare but costly. Disconnect the network briefly while an order is in flight. Provide the agent with conflicting instructions and observe which constraint it prioritizes. Introduce a sudden price gap and verify that the agent does not double down in an attempt to average down. If the agent uses news or external signals, test with a fabricated headline to see if it places an impulsive trade. Paper trading is only useful if you treat it as an adversarial exercise. Once you move to live trading, start with the smallest budget allowed by your limits. The first live trades are still part of the test. Monitor them manually and compare execution prices to the paper simulation. Discrepancies in slippage or latency can change strategy performance, so you should not assume that paper results will repeat exactly. If your agent relies on external data sources, test what happens when those sources lag or fail. A delayed price feed can cause the agent to trade on stale information, and a missing signal might trigger a default action that you did not intend. Know exactly how the agent behaves when it is partially blind, and confirm that it defaults to inaction rather than to an aggressive fallback.

What is the kill switch and when do you use it?

A kill switch is a panic button that flattens open positions and revokes the agent's API access in a single action. You should use it when the agent behaves in ways you did not anticipate, when market conditions move faster than your safeguards, or when you simply need to stop trading for external reasons. The kill switch is not a substitute for proper limits, but it is the final layer of defense. In a well-designed setup, pressing the kill switch does not require you to log into multiple venues or chase open orders across different interfaces. Because Felix offers one API for every market, the switch acts across stocks, crypto, perps, options, and prediction markets from a single call. You should verify the kill switch during paper trading and keep the trigger mechanism accessible outside the agent's own runtime. If the agent is hosted on a cloud server that fails, you must still be able to reach the switch from your phone or laptop. You should define clear criteria for when to press the switch. Ambiguity leads to hesitation, and hesitation leads to larger losses. Common triggers include an order that exceeds the position limit, a string of losses that hits the daily drawdown threshold, or any trade placed outside the approved market hours. Some operators also use the kill switch before major macroeconomic announcements when they want to be flat. The important point is that the decision is made in advance, not in the heat of the moment. After you trigger the switch, review the logs before you re-enable trading. Determine whether the agent misbehaved, the market moved unusually, or your limits were set incorrectly. Do not simply restart the agent without adjusting the setup, because the same failure will likely recur. Ensure that the kill switch does not depend on the same infrastructure that runs the agent. If both live on the same virtual machine, a single failure could disable both. Separate the control plane from the execution plane.

How do you monitor and audit agent activity?

Continuous monitoring is necessary because an agent can misinterpret signals or loop on a flawed logic branch. You should stream order and position logs to a system you control, not just the MCP client window. Review logs daily at first, looking for order sizes, symbols, and directions that match the strategy you described. Set alerts for anomaly patterns, such as orders larger than the position limit or trading outside approved market hours. Keep a manual trade journal alongside the agent's logs so you can compare intended versus actual behavior. Auditing also means reviewing the API key access log. If the key is used from an unexpected IP or at an unusual time, revoke it immediately and investigate. Over time, you can reduce monitoring frequency, but never eliminate it entirely. The goal is to catch divergence early, before a small error becomes a large loss. Monitoring should also include a periodic review of the agent's code or prompt. If you use an LLM through MCP, the model may interpret instructions differently after an update. Compare recent trades to the original strategy document and note any drift. You should also monitor the underlying API for changes. If the platform updates its order schema or market identifiers, the agent may start sending malformed requests. A good audit trail captures not just what the agent did, but what the API returned. If an order is rejected, the agent should log the reason and stop rather than retry blindly. Build a dashboard that shows open exposure, available budget, and recent drawdown in one view. This reduces the chance that you will overlook a problem because it is scattered across multiple screens or logs. Share the monitoring dashboard with a trusted second party if possible. A second set of eyes reduces the chance that you will rationalize away anomalous behavior because you are emotionally invested in the strategy. Even a brief daily check by a colleague or partner can surface issues that you have normalized.