How AI agents rebalance portfolios without taking custody of your funds

AI agents can rebalance portfolios without ever taking custody of your funds by operating through scoped API keys that only permit trading within owner-approved budgets and venues. The owner retains the withdrawal keys, while the agent receives limited spending authority that it cannot escalate or redirect to external addresses. This arrangement removes counterparty risk from the agent itself, but it introduces operational risks that must be constrained through hard caps, position limits, and an override mechanism the agent cannot disable. The goal is to let the agent optimize allocations while keeping the owner in sole control of capital movement.

What does non-custodial rebalancing actually mean?

In a non-custodial setup, the trading agent never holds the private key to the wallet or account that stores your funds. Instead, the owner creates a scoped key that grants the agent permission to place orders, read balances, and cancel existing orders, but explicitly denies withdrawal rights. The underlying funds remain in a wallet the owner controls, and any withdrawal address must be pre-approved by the owner before the system will allow a transfer. This means that even if the agent is compromised, the attacker cannot steal the funds. They can only trade within the boundaries set by the owner. Rebalancing adds a layer of complexity because the agent is not placing a single trade and stopping. It is continuously monitoring the portfolio weights across multiple asset classes, including stocks, crypto, perpetual futures, options, and prediction markets, and it is adjusting positions to match target allocations. Because the agent operates across five market types through one API, the owner must think in terms of aggregate exposure rather than siloed account limits. The API normalizes venue-specific contract math and denominates orders in plain US dollars, which helps the agent reason about allocation percentages without manually converting contract sizes, but the owner still bears responsibility for setting the constraints that govern those orders. Trading can lose money, including everything, and non-custodial architecture does not remove market risk.

Why does rebalancing carry different risks than single-trade agents?

A single-trade agent typically executes one order in response to a specific signal and then waits for the next instruction. The risk window is narrow and the failure modes are limited to that one transaction. A rebalancing agent, by contrast, runs on a schedule or a trigger and evaluates the entire portfolio at once. It may decide to sell portions of three assets and buy portions of four others in a single cycle. Each of those transactions carries its own slippage, latency, and fee profile. The cumulative cost of a rebalance cycle can be larger than a single concentrated trade, especially if the agent is working across venues with different liquidity profiles. More importantly, the sequential nature of rebalancing creates path dependency. If the agent sells an asset first and the market moves before it completes the corresponding buy, the portfolio can sit in cash during a sharp move, or worse, it can be temporarily overweight in a volatile asset that was meant to be trimmed. The agent does not experience market anxiety; it follows logic. If that logic is not bounded by drawdown limits, the agent can continue rebalancing into a falling market, effectively averaging down according to a formula that does not account for your total risk tolerance. Rebalancing also increases the surface area for API errors. A single-trade agent that receives a malformed response can abort. A rebalancing agent that receives a partial fill on the first leg of a seven-leg rebalance may proceed with the remaining legs, leaving the portfolio in an unintended state unless the owner has configured explicit abort conditions. Trading can lose money, including everything, and the additional complexity of multi-asset rebalancing does not reduce that possibility.

How to evaluate AI portfolio rebalancing step by step provides a framework for testing these multi-step sequences before they touch live capital. The evaluation should include not just the final allocation, but the intermediate states and the total transaction costs incurred during the cycle.

How should you limit what the agent can spend?

The first and most important control is a hard budget cap. This is a protocol-level limit, not a prompt instruction, that prevents the agent from deploying more than a specific US dollar amount across all venues. If the agent attempts to place an order that would cause total exposure to exceed the cap, the API rejects the request. This cap is enforced independently of the agent's reasoning, so a misaligned model or a hallucinated target allocation cannot override it. How an AI agent trades within a hard budget it cannot exceed explains how these limits are structured at the infrastructure level. Beyond the global budget, you should set nested limits. A per-venue cap prevents the agent from concentrating too much capital in a single market type, such as perpetual futures. A per-asset cap prevents any single ticker or contract from consuming the entire budget. A per-order maximum prevents a single malformed instruction from allocating everything to one position. These limits work in concert: the agent is bound by the most restrictive applicable cap at every level.

Position sizing is another critical variable. Rebalancing targets are typically expressed as percentages, but the agent must translate those percentages into dollar values and then into venue-specific units. If the agent uses stale net-asset-value data, or if it miscalculates the value of a perpetual futures position because it ignores funding rates, it can overbuy or oversell. You should define the sizing formula explicitly in the agent's configuration, and you should cross-check the output against API-side limits. The API denominates orders in plain US dollars, which reduces arithmetic errors, but the agent still needs accurate input data. You should also enforce a cash buffer. A rebalancing agent that targets 100% invested capital has no room for settlement delays, margin fluctuations, or failed orders. By reserving a small percentage of the budget as uninvested cash, you give the agent room to operate without accidentally triggering margin calls or attempting to spend unsettled proceeds.

What controls prevent an agent from locking your capital?

Rebalancing agents need to place orders to execute their strategy, but every open order locks buying power until it fills or cancels. If the agent places limit orders across multiple assets and does not cancel unfilled orders promptly, your capital can be frozen in limbo. The portfolio may show the correct target weights on paper, but the actual tradable balance can be zero. You should configure order lifetime limits so that orders expire automatically after a short duration, or require the agent to use cancel-replace logic rather than stacking new orders on top of old ones. This is especially important when rebalancing across markets with different trading hours. A limit order placed in a stock broker before market close can sit overnight, while a crypto order on another venue might fill immediately. The agent must be aware, or must be constrained, so that it does not leave stale orders that block the next rebalance cycle.

Settlement timing is another source of capital lockup. When the agent sells an asset in a stock broker, the cash may not settle for the standard settlement period. If the agent immediately attempts to buy another asset using the proceeds, it may attempt to trade with unsettled funds. Depending on the account type and venue rules, this can trigger restrictions or penalties. The agent should be configured to check available buying power, not just theoretical balance, before placing the next leg of a rebalance. You can also enforce a settlement-aware cash buffer or stagger the rebalance schedule so that sell orders settle before buy orders are placed. The API abstracts much of the venue-specific math, but settlement cycles are a function of the underlying market infrastructure and must be respected in the agent's timing logic.

How do you stop the agent if the market moves against it?

A panic or kill switch is non-negotiable for any agent that manages real money. This is a mechanism that flattens positions and revokes the agent's access, and it must be controlled exclusively by the owner. The agent cannot override it, negotiate around it, or delay its execution. How to build a kill switch your trading agent cannot override covers the technical implementation, but the operational principle is simple: the owner must retain the ability to stop all trading instantly. The kill switch should be more than a manual emergency button. It should function as an automated circuit breaker. If the portfolio drops by a predefined percentage during a single rebalance cycle, or if the agent attempts to exceed its budget cap more than once, the switch should trigger automatically. Once invoked, the agent's key is revoked, open orders are canceled, and the portfolio is flattened according to a preconfigured exit plan.

Exit plans are part of the same safety layer. Rebalancing implies periodic buying and selling, but you should also define conditions under which the agent must halt rebalancing into a specific asset. If an asset falls below a threshold, the agent should not automatically average down to maintain the target weight unless you have explicitly enabled that behavior. Without this rule, the agent can turn a rebalancing strategy into an accumulator of declining assets. You should set per-asset drawdown limits that pause new purchases while still permitting sales if the target weight has dropped. This keeps the agent from fighting trends with your entire budget. The exit plan should also address take-profit logic. If a rebalancing sell order is triggered because an asset has exceeded its target weight, the agent should execute it as a market order or a tightly bounded limit order. Letting the agent place open-ended limit orders in pursuit of a better fill can leave profits unrealized and capital locked.

When should you move from paper trading to live funds?

Felix provides paper trading for testing, and live trading requires explicit owner authorization of a key. You should not authorize live trading until you have observed the agent complete multiple full rebalance cycles in paper mode without breaching limits or leaving stale orders. Paper trading lets you verify that the agent respects hard budgets, handles partial fills correctly, and aborts sequences when a leg fails. Only after this behavior is consistent should you attach a live key. When you do transition, start with a small fraction of your intended capital. Fund the account with a limited amount and set the agent's budget cap to that subset. This lets you observe the agent's behavior with real slippage and real latency without exposing your full portfolio. If the agent performs correctly, you can raise the budget cap without regenerating keys, which preserves the audit trail and lets you scale exposure gradually rather than in large steps.

A practical checklist for non-custodial AI trading is a useful reference for verifying that you have configured all controls before authorizing live access. The checklist covers scoped keys, budget caps, approved withdrawal addresses, and kill switch testing. Review it before each escalation in capital.

How do you audit and verify non-custodial controls?

Non-custodial architecture is only as strong as its configuration. You should review the scoped permissions, budget caps, and approved withdrawal addresses on a regular schedule, not just at setup. The API provides a unified audit trail across all five market types, which means you can see every order, every limit check, and every kill switch invocation in one place. Review this log after each rebalance cycle. Look for rejected orders that indicate the agent is bumping against its caps, and look for partial fills that might have left the portfolio in an unintended state. You should also verify that the agent is not creating new patterns that you did not anticipate. For example, if the agent begins trading a new asset that was not in the original mandate, it may be interpreting a broad instruction too literally. Scoped keys can prevent this by restricting the agent to a whitelist of assets, but you must set that whitelist explicitly.

Auditing also means testing the kill switch periodically. Revoke and reauthorize a test key to ensure the revocation path works. Check that the panic flattening logic sells positions in the correct order and does not trigger unintended taxable events or settlement issues. Because the agent trades across stocks, crypto, perps, options, and prediction markets, the flattening sequence matters. You may want to flatten the most liquid venues first and the least liquid last, or you may want to prioritize venues with the highest margin risk. Define this sequence in advance and verify it during paper trading.