How beginner algorithmic traders keep self-custody when using an AI agent

Self-custody in algorithmic trading means your funds remain in a wallet or account that only you control, even while an AI agent places orders on your behalf. The agent receives a scoped key that lets it trade within boundaries you set, but it cannot withdraw funds, change those boundaries, or move money to an unapproved address. This design keeps ownership separate from execution, so the agent can manage positions without ever taking possession of your capital.

What does self-custody mean when an agent trades for you?

When you trade manually, you log into a brokerage or exchange and submit orders yourself. When you switch to an algorithmic agent, it is tempting to assume you must hand over custody so the software can act quickly. That is not the case here. The Felix model is non-custodial by construction. Your funds sit in a wallet or account that you own, and the agent receives a scoped key that only authorizes trading activity. The key does not grant withdrawal rights, and the agent cannot add new withdrawal addresses on its own. Withdrawal addresses are owner-approved only, which means any destination for your capital must be explicitly whitelisted by you before the agent ever runs. This separation is important because it removes the single point of failure that exists when you deposit funds onto a centralized platform and allow an automated system to operate from that platform's internal balance. In this architecture, the agent is an executor, not a custodian. It sees market data, calculates sizing in plain US dollars, and sends orders through one API that normalizes venue-specific contract math. Whether the agent is trading stocks, crypto, perps, options, or prediction markets, the underlying capital remains in your control. The API handles the translation between your dollar-denominated instructions and the native contracts of each venue, so you do not have to manage margin formulas or token decimals yourself. For beginners, this distinction can be subtle. You might think that giving an agent a key means giving it access to your money. In reality, you are giving it access to a narrow pipe that only permits trades. You retain the ability to revoke that pipe instantly, and you retain the ability to move your funds independently at any time. The agent cannot lock your capital, cannot pause your withdrawals, and cannot change the rules of engagement. This is what self-custody means in an algorithmic context. You are still the owner, and the agent is a temporary operator with a strictly limited license.

How does the API prevent the agent from taking your funds?

The safety model rests on the idea that permissions should be narrow and revocable. When you create a key for your agent, you scope it to specific actions. A scoped key can place orders, cancel orders, and read balances, but it cannot initiate withdrawals or increase its own budget. This is not a policy promise enforced by the agent's logic. It is a structural limit enforced by the infrastructure. Even if the agent were prompted to act maliciously, or if the large language model behind it produced an unexpected instruction, the key simply lacks the capability to move funds out of your account. Budget caps are another hard limit. You define a maximum amount of capital the agent can deploy, and the API rejects any order that would push exposure beyond that cap. This is useful for beginners who want to experiment with small amounts before scaling. Position limits work similarly. You can restrict the agent to a maximum number of contracts, shares, or units per market, which prevents a runaway sequence of orders from concentrating your capital in a single position. How an AI agent trades within a hard budget it cannot exceed explains the mechanics of these caps in detail. Because the API unifies access to five market types, you do not need to manage separate keys for a stock broker, a crypto exchange, a perps venue, an options venue, and a prediction market. One key, one API. The normalization layer converts your plain dollar instructions into the required format for each venue, but the custody layer never changes. The funds stay where you put them, and the agent can only trade within the sandbox you define. This design also simplifies auditing. Every action the agent takes is tied to a single key that you issued, so you can trace every order back to a specific permission set and time window.

What happens if the agent makes a mistake or the market moves against you?

It is important to state plainly that trading can lose money, including everything. Self-custody protects you from theft by the agent, but it does not protect you from market risk, bad strategy, or unexpected volatility. If the agent enters a position and the market moves against it, the loss is real and comes from your own funds. The value of the safety model is that it limits the scope of damage and gives you tools to stop it quickly. Exit plans are one such tool. You can configure automatic stop conditions that flatten positions when a threshold is reached. These are not suggestions given to the agent. They are enforced by the infrastructure. If the plan says close all positions after a five percent drawdown, the system does so without waiting for the agent to agree. The panic or kill switch goes further. When activated, it immediately flattens all positions and revokes the agent's key. Access is cut off within seconds, not after a confirmation dialog that the agent might try to negotiate. Before you reach that point, you should test in the paper trading environment. Paper trading exists for testing, and it lets you observe how the agent behaves when it sees real market data but uses simulated balances. Live trading requires explicit owner authorization of a key, which means you must consciously upgrade from paper to real money. This upgrade step is a deliberate friction point designed to prevent accidental live execution. How to design prompts that keep trading agents within bounds covers how to write instructions that align with these safety features. You should also understand that the agent's speed is a double-edged sword. It can react to market conditions faster than a human, but it can also make errors faster. A misinterpreted data feed or a poorly worded prompt can lead to a series of orders that would take a human minutes to execute manually. The safety model assumes that speed is a risk and builds guardrails accordingly. That is why the hard limits exist at the infrastructure level. They act as a circuit breaker that operates independently of the agent's reasoning speed.

How do MCP tools and scoped keys enforce these limits?

Agents connect through MCP tools or the REST API. MCP, or Model Context Protocol, is the interface that lets AI editors and autonomous systems interact with external functions. When an agent connects to the trading infrastructure through MCP, it does not receive raw credentials or unrestricted API access. Instead, it receives a tool definition that describes what actions are available and what parameters are required. The tool layer, not the large language model, enforces the hard limits. For example, if the agent attempts to place an order that exceeds the scoped key's budget cap, the tool returns an error before the order ever reaches a venue. If the agent tries to query a function outside its scope, the tool refuses. This architecture matters because it means a misaligned prompt or an hallucinated strategy cannot bypass your controls. The limits live in the infrastructure, not in the agent's memory or reasoning. How MCP trading tools enforce hard limits that agents cannot cross describes this architecture in more detail. The scoped key is generated by you, and its permissions are immutable from the agent's side. You can rotate or revoke it at any time through the dashboard or programmatically. Because the key is tied to a specific agent instance and a specific set of markets, a compromise in one part of your system does not automatically grant access to the rest of your capital. You can partition risk by creating separate keys for separate strategies, each with its own budget and position limits. For beginners, this is a critical comfort. You do not need to trust the agent's internal reasoning or the stability of the large language model. You only need to trust the key permissions you configured, which are deterministic and auditable. If the agent suggests a trade that violates your rules, the infrastructure simply says no. The agent cannot argue, cannot override, and cannot escalate. The boundary is mechanical.

Why is paper trading necessary before you authorize live trading?

Paper trading lets you validate your strategy and your safety configuration without risking real capital. It is a necessary step because it reveals behavior that is hard to predict from static backtests. The agent may interpret a prompt differently than you intended, or it may interact with market data in a way that produces unexpected order sequences. Watching this happen with simulated money is far safer than discovering it during live execution. However, paper trading is not identical to live trading. Fills in paper environments are typically simulated against the order book, and they may not account for the liquidity gaps or slippage you will experience when your order actually reaches a venue. The emotional and systemic reality of live markets, where your own capital is at risk, also changes how you monitor the agent. Because live trading requires explicit owner authorization of a key, you have a natural checkpoint. You must intentionally move from the paper environment to the live environment, and during that transition you should review every safety setting. Check that your budget cap reflects the amount you are genuinely willing to lose. Confirm that your withdrawal addresses are correct and limited to destinations you control. Verify that your exit plan and kill switch are active. Paper trading is the rehearsal. Authorization is the decision to step on stage. During the paper phase, pay attention to how the agent handles edge cases. What does it do when a market gaps down? Does it respect the position limit when volatility increases? Does it attempt to place orders that get rejected by the tool layer, and does it recover gracefully? These observations will tell you whether your prompts and your infrastructure settings are aligned. If they are not, fix them in paper before you expose real money to the same behavior.

What should you check before authorizing live trading?

Authorization should be a deliberate checklist, not a quick toggle. The following steps are essential before you move from paper to live trading.

1. 01Confirm your scoped key permissions. The key should only allow trading on the markets you intend to use, and it should carry the exact budget and position limits you designed. How to build scoped API keys for a trading agent step by step walks through this process.
2. 02Test your panic switch. Trigger it while the agent holds paper positions and verify that it flattens everything and revokes access immediately.
3. 03Review your withdrawal allowlist. The agent should not be able to send funds anywhere except addresses or accounts you have pre-approved.
4. 04Set your exit plan thresholds conservatively. A beginner algorithmic trader should start with tight limits that can be relaxed later as the strategy proves itself.
5. 05Read your prompt carefully. The prompt is the instruction set that guides the agent's decisions, and it should explicitly reference the safety boundaries you configured. How to design prompts that keep trading agents within bounds offers guidance on writing these constraints into the agent's context.

Finally, start with a small live budget, even smaller than your paper testing allocation. The goal of your first live weeks is to validate infrastructure and monitoring, not to generate returns. Returns are never guaranteed, and the priority is to confirm that your self-custody setup behaves exactly as you expect when real money is on the line. You should also document your configuration. Write down the budget cap, the position limits, the markets you authorized, and the date you activated live trading. This documentation helps you review your progress and spot drift. If you decide to increase the budget later, do so only after a defined period of stable behavior and only after re-checking your kill switch and allowlist. Self-custody gives you control, but control requires attention. The safety model is robust only when you verify it regularly.