How to secure an AI trading agent without giving up custody

You can let an AI agent trade real money without giving up custody by using scoped keys, budget caps, and owner-set withdrawal rules the agent cannot override. The agent receives permission to enter and exit positions, but it cannot move funds to a new address, increase its own limits, or ignore a kill command. This model treats the agent as a delegated trader, not a trusted custodian, which means your capital stays in a wallet you control while the algorithm operates within boundaries you set.

What does non-custodial mean for an AI agent?

In most discussions about automated trading, the software is given an API key and left to run. If that key has full account access, the bot or agent is effectively a custodian because it can move funds, change settings, or withdraw to any address it chooses. Non-custodial agentic trading removes that possibility by design. The funds remain in a wallet that only the owner controls, and the agent receives a carefully limited set of permissions that allow it to trade but not to take possession.

This separation matters because AI agents are not perfect. They can misinterpret signals, loop on bad logic, or be exposed through a compromised prompt. If the agent holds custody, a single failure mode can empty an account. When the agent is non-custodial, the worst-case scenario is bounded by the trading limits you set in advance. The agent might lose the budget you allocated, but it cannot drain the rest of your wallet or send money to an external address.

The architecture that enforces this is built into the infrastructure layer, not into the agent's own code. The owner defines the rules when the key is created, and the API enforces those rules on every request. The agent does not get to choose whether to follow them. That is the difference between a policy and a preference. A policy is enforced by the platform; a preference can be overwritten by a clever prompt or a bug.

Funds sit in a wallet the owner controls at all times. The agent can spend within the limits of its scoped key, but it can never withdraw to itself or steal capital. Withdrawal addresses are owner-approved only, which means even if the agent requests a payout, the infrastructure will block the transaction unless the destination was whitelisted by the owner beforehand. This structural rule is what makes the model non-custodial by construction, rather than non-custodial by promise.

It is also important to remember that trading carries real risk. Even with strong custody controls, an agent can lose money quickly, including the entire amount you allocate to it. Non-custodial security protects your wallet from theft and unauthorized withdrawals, but it does not protect allocated capital from market losses. You should only fund an agent with money you can afford to lose.

How do scoped keys keep the agent in its lane?

A scoped key is an API credential that carries a fixed set of permissions which cannot be expanded by the bearer. In the context of an AI trading agent, this means the key is valid for placing and canceling orders, reading balances, and querying positions, but it is invalid for withdrawals, changing account settings, or approving new destination addresses. The scope is set when the key is minted, and the owner must explicitly authorize any change.

This approach is central to how a single API keeps AI trading agents safe by design. The API acts as a gatekeeper that normalizes requests across stocks, crypto, perpetual futures, options, and prediction markets. Whether the agent is sending an order to a stock broker or a perps venue, the same scoped key format applies. The agent cannot exploit venue-specific features to escape its limits because the API translates and filters the request before it reaches the market.

The exact request schema is in the docs; the shape looks like this:

{
  "key": "YOUR_KEY",
  "market": "crypto",
  "order_size_usd": 500,
  "mode": "paper"
}

Because the key is scoped, even a compromised agent cannot repurpose it. The infrastructure rejects any request that falls outside the pre-approved set. The owner can also rotate or revoke the key without moving funds or closing accounts at individual venues. The key is tied to the agent's session, not to the owner's wallet, so revocation is instant and complete.

Scoped keys also simplify auditing. Because all orders flow through one API, the owner can review a unified log of what the agent did across every market type. There is no need to reconcile separate exchange histories or wonder whether an agent hid a trade on a secondary venue. The single API record makes it easier to spot anomalies and to confirm that the agent stayed within its lane.

What safety controls stop runaway losses?

Custody is only one part of security. The other part is limiting what the agent can do with the money it is allowed to trade. Felix provides several controls that act as hard guardrails: budget caps, position limits, exit plans, and a panic kill switch. Each control is enforced by the API, not by the agent, so the agent cannot talk its way around them.

A budget cap sets the maximum amount of US dollars the agent can deploy over a given period. Once the cap is reached, the API rejects new orders until the owner resets or increases the limit. Position limits prevent the agent from taking oversized bets in a single market. This is especially important when an agent uses dollar-based order sizing, because a misinterpreted signal could otherwise lead to a position that is far too large for the account. The API normalizes venue-specific contract math so that the agent thinks in plain dollars, but the limit is still enforced at the infrastructure level.

Exit plans let the owner define take-profit and stop-loss logic before the trade is placed. The agent can enter the position, but the exit is handled by the infrastructure according to the owner's plan. This removes the risk that the agent will ignore a losing trade or delay an exit because of a reasoning loop. You can read more about this in automate exit plans and take profits while keeping custody.

Finally, the panic kill switch is the last line of defense. If the owner decides the agent must stop immediately, the switch flattens all open positions and revokes the key. The agent does not need to agree. The switch is designed to work even if the agent is stuck in an error state or is generating orders faster than a human can review. These controls are part of the practical checklist for non-custodial trading beginners, and they should be configured before any live capital is allocated.

It is worth repeating that these controls limit damage, they do not prevent it. A budget cap means the agent can lose up to the full amount you allocate. The cap is a ceiling, not a floor. Markets can move against a position instantly, and the agent may not be able to exit before the cap is exhausted. You should size the cap with the understanding that the full amount can be lost.

How does the kill switch work?

The kill switch is a manual circuit breaker controlled by the owner. When activated, it triggers a sequence that first sends exit orders to close all open positions across every market type the agent is authorized to trade, and then invalidates the scoped key. The agent is disconnected immediately and cannot issue new orders.

This process is designed to be faster than manual intervention. In a situation where an agent is behaving erratically, asking the agent to stop may not work. The kill switch bypasses the agent entirely and talks directly to the execution layer. Because the API normalizes order sizing in plain US dollars, the exit orders are calculated the same way regardless of whether the position is in a stock, a crypto token, or a perps contract. The owner does not need to know the venue-specific contract multiplier or margin rules to flatten the position.

After the switch is thrown, the owner can review the logs, adjust the strategy, and issue a new scoped key if desired. The funds remain in the owner's wallet throughout. There is no need to withdraw from a third-party account or wait for settlement from a venue. The owner simply revokes access and the agent is locked out. The flattened positions may still result in a loss, but the agent cannot continue trading while the owner investigates.

You should test the kill switch in paper mode before going live. Confirm that it closes all positions and that the agent cannot reconnect with the old key. Testing the switch gives you confidence that the circuit breaker actually works when emotions and market volatility are high.

How do you test before going live?

Every agent should prove itself in paper trading before it touches real capital. Paper trading uses the same API, the same scoped keys, and the same market data, but orders are routed to simulated fills rather than live venues. The agent experiences realistic slippage and rejection logic without risking money.

The transition from paper to live is gated by an explicit owner authorization step. A key that works in paper mode cannot automatically trade live. The owner must review the agent's behavior, confirm the safety controls, and then authorize a live key. This friction is intentional. It prevents an agent from graduating to real money because of a configuration typo or a misunderstood prompt.

During testing, you should verify that the budget cap behaves as expected, that position limits are enforced, and that the kill switch flattens simulated positions correctly. You should also confirm that the agent cannot perform any withdrawal action even in paper mode. If you see unexpected behavior, you can revoke the key, debug the logic, and restart without financial damage. The docs live at /docs for detailed setup instructions.

Paper trading is also a good time to observe how the agent handles uncertainty. If the agent frequently misinterprets signals or generates ambiguous orders, it is better to discover that in simulation. The goal of paper trading is not to prove the strategy will be profitable, but to prove the agent behaves within the boundaries you set. Profitability is never guaranteed, and past simulation results do not predict live outcomes.

What should you verify before authorizing live trading?

Before you approve a live key, walk through a short checklist to confirm that the guardrails are in place. The following items are a starting point, and you can expand them based on your strategy and risk tolerance.

• ·Confirm the wallet contains only capital you can afford to lose.
• ·Set a budget cap that is strictly lower than your total wallet balance.
• ·Define position limits for each market type the agent will access.
• ·Configure an exit plan or confirm the kill switch is reachable.
• ·Review the scoped key permissions to ensure withdrawals are disabled.
• ·Run the agent through at least one full cycle in paper trading mode.
• ·Document the rationale for the strategy so you know when the agent is deviating.

These steps are covered in more detail in how a single API keeps AI trading agents safe across every market. The goal is to make sure that the agent is a tool you control, not a black box that controls your funds.

You should also revisit this checklist whenever you change the agent's strategy or expand it to a new market type. A key that is safe for small crypto positions may not be safe for leveraged perps or options. Each market has its own volatility profile, and your controls should reflect that. The act of authorizing a live key is a decision to accept the risk of loss up to the cap you set. Make that decision deliberately.