How to let an AI agent trade real money without giving up custody

Non-custodial agentic trading means your funds remain in a wallet you control, and the agent receives only the scoped permission to place orders within limits you define. The infrastructure never takes custody of your capital, cannot withdraw to its own addresses, and can be shut down instantly if behavior diverges from your plan. Before you authorize live trading, you should verify the wallet setup, key scope, budget caps, and exit controls. This checklist walks through each step in the order that minimizes the chance of an irreversible mistake.

What does non-custodial trading mean in practice?

Non-custodial trading means that your capital never leaves an account or wallet that you control. In a custodial model, you deposit funds onto a platform and trust that platform to hold them. In the Felix model, your funds remain at a stock broker, a crypto venue, a perps venue, an options venue, or a prediction market, and you issue a scoped key that lets the agent trade on your behalf without ever granting ownership or withdrawal rights. The infrastructure is designed so that the agent can spend within the limits you set, but it cannot withdraw to itself, change account ownership, or move funds to an unapproved address. This is enforced at the key and contract level, not merely by policy. Because the API abstracts venue-specific math, you state orders in plain US dollars. If you instruct the agent to buy one hundred dollars of an asset, the API handles the conversion to shares, contracts, tokens, or prediction market shares behind the scenes. You receive position reports back in the same dollar terms, so you do not need to manually adjust for contract multipliers, lot sizes, or decimal precision. The agent operates across five market types through one integration, but the non-custodial property holds for each: your stocks sit in your brokerage account, your crypto sits in your wallet, and your prediction market positions sit in your account at the venue. You can revoke access at any time, and the worst-case exposure is limited to the trading budget you have allocated, not your entire net worth.

How do you secure the wallet and API keys?

Start with the principle of least privilege. The wallet or account that holds your funds should be protected by hardware signing, multi-signature, or standard brokerage authentication, depending on the asset class. For crypto and perps, consider a hardware wallet or a multi-signature contract that requires your explicit approval for any withdrawal. For stocks and options, use a standard brokerage account that you own, and ensure that the API key you generate is restricted to trading functions only. When you create the trading key, scope it exclusively to order placement, position queries, and balance reads. It must not have withdrawal permissions, account modification rights, the ability to generate sub-accounts, or access to your personal identity documents. If the venue supports IP whitelisting, bind the key to the specific server or client that runs the agent. Maintain a separate, offline-approved list of withdrawal addresses. This list should be small, static, and verified out of band. If the agent is compromised, it cannot send funds to an attacker-controlled wallet because the infrastructure rejects any destination not on your pre-approved list. Store the key material in an encrypted environment, such as a secrets manager or an encrypted local store, and inject it at runtime. Never write the key into the agent's prompt, system instructions, or context window. If you are connecting via MCP, the key is held by the client application and injected into tool calls; the language model sees only the tool schema, not the credentials. Rotate keys after initial setup, after any software update that touches the trading stack, and after any panic event. You should also verify that the API endpoint you connect to is the legitimate one by checking its certificate and DNS records, rather than relying on a link provided by the model. A comprehensive guide to this layer is available in How to build a practical security checklist for AI trading agents.

What limits should you set before the agent starts?

Before the agent places its first order, define hard constraints that the infrastructure enforces independently of the agent's reasoning. These limits should be non-negotiable and configured at the infrastructure level, not inside the agent's logic, because the agent may misinterpret data or encounter a prompt injection that attempts to override its instructions.

• ·Set a total budget cap denominated in US dollars. This is the maximum amount the agent can deploy across all positions. If the cap is reached, the API rejects further orders until you manually reset or increase it.
• ·Define a maximum position size per instrument, expressed in dollars, so the agent cannot concentrate the entire budget in a single volatile asset.
• ·Restrict the markets and instruments the agent can access. If your strategy does not require leveraged products, disable access to perps and options entirely.
• ·Add a daily or weekly loss threshold that triggers an automatic pause. When this threshold is hit, the agent cannot place new orders, and you receive a notification requiring manual reactivation.
• ·Specify take-profit levels, stop-loss levels, or time-based exits for every strategy you deploy. The agent should not hold a position indefinitely while you are away.

An exit plan is not optional. Specify take-profit levels, stop-loss levels, or time-based exits for every strategy you deploy. The agent should not hold a position indefinitely while you are away, especially in markets that gap or expire. The API normalizes order sizing in plain US dollars, so you can state these limits in intuitive terms rather than venue-specific contract units. You can learn more about configuring these controls in How to set guardrails for a trading agent.

How do you test everything without risking capital?

Felix offers paper trading that mirrors the live execution path, including latency, error handling, and limit enforcement. Use this environment to run the agent through multiple market conditions, including volatile periods, so you can observe how it interprets data and whether it respects the boundaries you set. During testing, deliberately trigger every safety mechanism. Hit the budget cap with a large hypothetical order and confirm that the API rejects it. Open a position that exceeds your per-instrument limit and verify that the infrastructure blocks the trade. Trigger the kill switch while positions are open and ensure that the system flattens them and revokes the key. Test network failures by disconnecting the client mid-order to see how the agent handles partial fills and errors. Paper trading is only useful if you treat it as a full rehearsal, not a simplified game. The agent should connect through the same MCP tools or REST API that it will use in production. If you use Claude, Cursor, or another MCP client, verify that the tool definitions and parameters are identical in paper and live modes. You should also confirm that the key used for paper trading is distinct from the live key, and that the live key requires a separate, explicit owner authorization step. This prevents any accidental path from simulation to real capital. Never assume that because the agent behaves in paper mode, it will behave identically when real slippage and emotion enter the picture, but paper trading does catch configuration errors and logic bugs before they cost money.

What is a kill switch and how do you test it?

A kill switch is a panic mechanism that flattens open positions and revokes the agent's access in seconds. It exists because no automated system should be allowed to trade without a human-retained off switch that works even if the agent, the host server, or the model provider is compromised. Flattening means closing all open positions, canceling all resting orders, and disabling the API key so that no further instructions are accepted. To test it, place a small position in the paper environment, trigger the switch, and verify that the position closes at market or limit, that all pending orders are canceled, and that the key is invalidated. Many beginners assume that simply stopping the agent process is enough, but a process crash does not cancel resting orders or close leveraged positions. A proper kill switch is infrastructure-level, not client-level. You should also confirm that you can trigger it from a separate device or account, in case the machine running the agent is compromised or locked. Store the trigger credentials outside the agent's environment. If your kill switch requires a second factor, such as a hardware token or a phone confirmation, test that path as well. Some users forget to test the switch under load, so simulate a scenario where the agent is placing rapid orders and then trigger the switch to measure the response time. Review What beginners get wrong about kill switches for trading agents for additional mistakes that can render a switch ineffective.

How do you move from paper to live trading responsibly?

Moving to live trading should be a deliberate, multi-step process rather than a single toggle. First, re-verify that the production key is scoped correctly, that your withdrawal address list is still accurate, and that your budget cap reflects money you can afford to lose entirely. Trading can lose money, including the entire allocated budget, and you should never allocate capital that you need for living expenses or debt obligations. Authorize the live key explicitly through the owner approval flow. The agent cannot self-promote from paper to live, and the infrastructure should require a distinct human action, such as signing a message or confirming through a separate authenticated session. Start with the smallest meaningful budget that still produces realistic execution, observe the first few orders for slippage, timing, and fee impact, and confirm that the reporting matches your expectations. Compare the live fills to the paper fills for the same signals to detect any drift in execution quality. Only after days or weeks of consistent behavior should you consider increasing the budget cap or expanding the allowed markets. Do not scale up because the agent had a lucky streak in its first week. Instead, scale up because the safety mechanisms have been tested, the logs are clean, and the agent's reasoning remains stable across different market regimes. Keep a trading journal that records why you gave the agent a specific instruction, what the outcome was, and whether any limit was triggered. This documentation is invaluable when you need to debug or explain the system to yourself later. You can avoid many early mistakes by reading What beginners get wrong when they first let an AI agent trade.

Non-custodial agentic trading gives you automation without surrendering control. If you verify the wallet setup, scope the keys tightly, test every limit in paper mode, and keep a working kill switch, you remove the largest structural risks before the agent ever touches real capital. The remaining risk is market risk, which is unavoidable and can cost you the full budget you allocate. Treat that budget as the price of a controlled experiment, and size it accordingly.