How safety is built into AI portfolio rebalancing from first principles

AI portfolio rebalancing is safe only when the agent cannot withdraw funds, cannot exceed its budget, and can be stopped instantly by the owner. Felix builds this safety model from first principles by making the agent non-custodial, enforcing scoped dollar limits, and providing a kill switch that revokes access and flattens positions. The agent can trade across stocks, crypto, perps, options, and prediction markets through a single API, but it never holds the owner's capital. If the agent is compromised or misconfigured, the owner's wallet remains untouched and the damage is bounded by pre-set caps, though trading can still lose money, including everything.

What makes automated portfolio rebalancing dangerous?

Portfolio rebalancing seems mechanical. You define target weights, compare them to current holdings, and trade the difference. When an AI agent performs this loop, the risk is not just a bad trade. It is the accumulation of small errors at machine speed. An agent can misread an order book and place a market order that fills far outside the expected range. It can rebalance too frequently, turning a small fee into a steady drag. It can fail to notice that a market is closed or that a perpetual swap has diverged from the spot price, and it can keep buying into an asset that has halted. Without a boundary, the agent might also concentrate the portfolio into a single position that the owner never intended. Suppose the agent is authorized to trade options without limits. It might write naked calls to raise cash for a stock purchase, creating liabilities that the owner never approved. The deeper risk is authority. If the agent controls a wallet that can withdraw to any address, then a bug or breach does not just lose money on trades. It loses everything. Rebalancing therefore requires a safety model that treats trading loss and theft as separate threats and stops both.

Why is non-custodial control the foundation?

The first principle of safe agentic trading is that the owner must keep the keys to the treasury. In the Felix model, funds sit in a wallet the owner controls. The agent receives an API key that lets it place orders and read balances, but the key cannot withdraw funds to an unapproved address and cannot change the owner's permissions. This is non-custodial by construction. Even if an attacker compromises the agent's environment, the key is scoped. It can spend within limits, but it cannot steal. The owner pre-approves withdrawal addresses, and the agent cannot add new ones. This separation of trading authority from custody authority is what makes the agent a trader rather than a treasurer. This design holds across all five market types. Whether the agent is rebalancing a stock portfolio through a stock broker, adjusting crypto allocations, or shifting exposure in a perps venue, the same wallet model applies. The agent sends orders through one API, but the underlying capital remains in the owner's account. How an AI agent executes orders while you keep full custody explains the mechanics in more detail. Non-custodial design also simplifies recovery. If the owner decides to stop using the agent, revoking the API key is enough. There is no need to transfer funds out of a third party custodian because the funds were never in the agent's custody to begin with. The owner can rotate keys, change scopes, or shut down the agent without waiting for a withdrawal window or paying an exit fee.

How do spend caps and position limits prevent drift?

Rebalancing is a loop. Prices move, weights drift, and the agent calculates the gap between current and target allocation. Without a ceiling, the agent could trade indefinitely. It might chase a target that shifts every second, or it might build a position so large that a single asset dominates the portfolio. From first principles, the owner should define hard budgets before the agent starts. The Felix API lets owners set spend caps, drawdown limits, and per-asset position limits in plain US dollars. Because the API normalizes venue-specific contract math, the agent thinks in dollars and the owner sets dollar limits. There is no ambiguity about contract sizes, lot sizes, or margin multipliers. Suppose an owner sets a ten thousand dollar cap and a twenty percent maximum position size. The agent can buy and sell to rebalance, but once it has deployed ten thousand dollars or once any single asset reaches twenty percent of the portfolio, the infrastructure blocks further orders. These are not soft warnings. They are enforced by the API layer, which means the agent cannot override them, even if its reasoning tells it that the trade is justified. Drawdown limits add another layer. If the portfolio value falls by a pre-defined percentage, the agent halts. This prevents the agent from rebalancing deeper into a falling market under the assumption that it is buying a dip. The owner can also set a maximum number of trades per day or per week, which prevents the agent from churning the account into a fee hole. Trading can lose money, including everything. These limits do not guarantee profit. They guarantee that the agent cannot exceed the boundaries the owner has chosen. How to set spend caps and drawdown limits for trading agents covers the configuration in detail.

What is the role of an exit plan and kill switch?

A rebalancing strategy that never stops is not a strategy. It is an open-ended liability. The owner needs an exit plan, which is a pre-defined rule for when the agent should flatten positions, return to cash or a stable benchmark, or simply pause. The exit plan lives in the agent's configuration. It might state that if the portfolio drawdown exceeds five percent, the agent moves to a defensive allocation. If a specific market halts, the agent stops trading that asset and notifies the owner. These rules are not suggestions. They are part of the guardrails. Then there is the kill switch. This is a manual or automated trigger that revokes the agent's key, cancels all open orders, and flattens positions. The switch is designed to be faster than the agent. When activated, the agent loses access before it can place another order. The owner can trigger it from a dashboard or an emergency endpoint. An automated trigger might fire if a metric breaches an extreme threshold. The kill switch is a one-way action. Only the owner can reauthorize the agent after a switch event. This prevents a compromised agent from immediately reconnecting and resuming. Before going live, the owner should test the switch in paper trading and confirm that it behaves as expected. The owner should also verify that the switch reaches every connected market, not just one. No automation can remove all risk. Trading can lose money, including everything. The kill switch limits the scope of that loss by cutting the agent off before it can compound an error. How to audit your trading agent guardrails before going live offers a practical checklist for this review.

How does rebalancing across market types affect safety?

Rebalancing a portfolio that spans stocks, crypto, perps, options, and a prediction market introduces timing and settlement risks that a single-asset agent does not face. A stock broker may only accept orders during market hours, while a crypto venue runs continuously. A perps venue might apply funding rates that change the effective cost of holding a position. An options venue introduces expiration and strike selection. If the agent treats all of these as identical instruments, it can create unexpected exposures. The safety model addresses this by normalizing orders into plain US dollars. The owner sets a single budget cap in dollars, and the API translates that into the appropriate contract size for each venue. The agent does not need to calculate how many shares, contracts, or tokens equal five hundred dollars. The infrastructure handles that translation. This removes a common source of error where an agent miscalculates position size because it confused a stock lot with a perpetual contract multiplier. However, the owner still needs to set market-specific guardrails. For example, an agent might be allowed to trade options only to hedge existing equity positions, not to speculate. It might be allowed to trade a prediction market only up to a small sub-cap. These rules are enforced by scoped permissions attached to the key. The agent cannot accidentally sell an option against a stock it does not own if the key lacks that permission. Cross-market rebalancing also means that a kill switch must reach every venue simultaneously. The switch does not just cancel orders on one exchange. It flattens and revokes across all connected markets. This prevents a scenario where the agent is stopped in stocks but continues to trade crypto, breaking the intended allocation. The panic function is global to the agent's key, not local to a single venue.

How should an owner test a rebalancing strategy before going live?

Paper trading is the first step. The Felix API includes a paper mode where the agent runs against live market data but no real capital moves. This lets the owner observe how the agent handles rebalancing frequency, how it respects the spend caps, and whether it attempts to trade assets with thin liquidity. During paper testing, the owner should simulate edge cases. Imagine a scenario where one asset drops thirty percent in a single session. Does the agent try to rebalance into it repeatedly, or does it hit the drawdown limit and stop? Imagine a scenario where a market is closed. Does the agent queue orders or skip the asset? These hypothetical tests reveal whether the guardrails are tight enough. Before authorizing live trading, the owner should verify a short checklist:

1. 01Confirm that the spend cap matches the total capital you are willing to deploy.
2. 02Confirm that the kill switch flattens positions and revokes the key in paper mode.
3. 03Confirm that each market type in the portfolio has the correct scoped permissions.
4. 04Confirm that the drawdown limit halts the agent before losses exceed your threshold.

Live trading requires explicit owner authorization. The owner must approve a specific key for live access, which is a deliberate human gate. Until that authorization happens, the agent cannot trade real money, even if the code is deployed. This authorization step is part of the safety model because it forces a pause between testing and live deployment. For developers building the agent, connecting through MCP tools or the REST API follows the same pattern. The exact request schema is in the docs; the shape looks like this:

curl -X POST https://api.felix.trade/v1/orders \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "market": "example-market",
    "side": "buy",
    "usd_size": "500.00",
    "symbol": "EXAMPLE"
  }'

The key used in that request is scoped and capped before it is ever issued. The owner sets the limits first, then generates the key, then authorizes the agent. How to Start Multi-Market Portfolio Management with AI Agents walks through the broader setup.