Why AI agents need scoped API keys when trading real money

AI agents that trade with real money require API keys that restrict scope by design, because an unrestricted key would let a compromised or malfunctioning agent drain an account. Scoped keys limit each agent to specific markets, position sizes, and spend ceilings, while blocking withdrawals to any address the owner has not pre-approved. This turns a single API connection into a bounded environment where the agent can execute strategy but cannot steal capital or exceed loss limits.

Traditional API keys were built for human traders who read screens, click buttons, and pause to reconsider. They assume the user will exercise discretion and catch mistakes before they reach the market. An agent does not read confirmations. It parses context, generates actions, and loops continuously. A scoped key is therefore not merely a credential, but a policy object that encodes the owner's risk tolerance directly into the infrastructure. The agent may reason probabilistically, but the key enforces deterministic boundaries that do not depend on the model's mood or the quality of the prompt.

What makes an agent key different from a standard API key?

A standard API key typically authenticates an account and grants broad read and write access. It assumes the holder will exercise judgment and stop when something looks wrong. An agent key, by contrast, is created with an explicit mandate that defines which markets it may touch, how much capital it may deploy, what types of actions it may take, and where funds may be sent. The Felix model uses one API and one key across stocks, crypto, perpetual futures, options, and prediction markets, but the key itself carries scoped permissions that are unique to each agent and each strategy.

Orders are sized in plain US dollars. The API normalizes venue-specific contract math, so the agent does not need to understand how a perps venue calculates margin, how an options venue handles contract multipliers, or how a stock broker handles fractional share logic. The agent sends a dollar amount and a direction. The key checks whether that amount is within the remaining budget, whether the resulting position would exceed concentration limits, and whether the market is in the approved set. If the agent sends a request for a market that is not in the scope, or a size that breaches the cap, the request is rejected without reaching the venue. Only if every condition passes does the request proceed toward execution.

This means an owner can run multiple agents from the same wallet, each with a different scoped key. One agent might be authorized for small options positions, another for crypto spot, and a third for prediction markets. Each key carries its own budget and its own kill switch. If one key is compromised or its agent malfunctions, the others are unaffected. The scope isolates failure and prevents a single bad actor or bug from touching capital assigned to other strategies.

How do scoped permissions limit what an agent can lose?

The primary risk in agentic trading is not malice but speed and autonomy. An agent can generate and execute requests far faster than a human can review them, and it can operate while the owner is asleep or offline. Scoped keys create circuit breakers that are enforced by infrastructure, not by the model's reasoning or the developer's hope that the prompt is well written. The controls are hard limits coded into the key, and they act before any order reaches a venue.

The safety controls are not suggestions. They are enforced at the API layer before an order reaches any venue. The key checks every request against the following dimensions.

• ·Budget caps prevent the agent from deploying more capital than the owner allocated, even if the strategy repeatedly signals for larger size or the LLM interprets a news event as a reason to double down.
• ·Position limits stop the agent from concentrating too heavily in a single market, which matters when an LLM might fixate on a narrative and want to keep adding exposure beyond what a prudent portfolio would allow.
• ·Drawdown limits can trigger a forced halt when unrealized losses cross a threshold chosen by the owner, preventing the agent from riding a losing position to zero while waiting for a reversal that may never come.
• ·A panic or kill switch flattens positions and revokes the key, acting independently of the agent's code, the model's current context window, or any external data feed the agent is consuming.

These controls do not eliminate the risk of losing money. Markets can move against any position, and trading can lose everything. What the controls do is limit the maximum speed and depth of loss by capping exposure and stopping the agent when the boundary is breached. You can read more about configuring these in spend caps and drawdown limits.

Why does non-custodial design require scoped keys?

Non-custodial by construction means funds sit in a wallet the owner controls. The agent can spend within limits but can never withdraw to itself or steal. Withdrawal addresses are owner-approved only. This architecture is only possible if the key itself is scoped. An unscoped key would be functionally equivalent to giving the agent the wallet's private key, because the agent could simply trade all funds into worthless positions or interact with malicious contracts until the wallet is empty.

The scoped key is the bridge between the owner's capital and the agent's logic. It lets the agent participate across multiple market types without ever taking custody. Because the key cannot withdraw to an unapproved address, a compromise of the agent's environment, such as a leaked prompt or a hijacked MCP session, does not automatically become a compromise of the owner's treasury. The owner can revoke the key at any time and the funds remain accessible in the original wallet.

This design matters because agents are not deterministic scripts. They are probabilistic systems that can be influenced by the phrasing of their instructions, the data they ingest, and the tools they are given. A non-custodial wallet without a scoped key would be like a vault with a door that opens to anyone who asks politely. The scoped key is the lock that remains under the owner's control. It is the practical implementation of non-custodial agent trading.

What happens when an agent requests a disallowed action?

When an agent connected through MCP tools or the REST API sends a request that exceeds its scope, the platform rejects the request before it reaches a venue. The agent receives an error and must handle it. This is a critical safety feature. A standard API key might accept a malformed or oversized order and pass it to the venue, where it could be filled instantly or rejected after incurring fees and latency. In either case, the capital is exposed to a decision made outside the owner's intent. A scoped agent key rejects the order at the gate, so the mistake never leaves the system.

Suppose an agent hallucinates a trade size of one million dollars for an account capped at one thousand dollars. The scoped key rejects the request. The agent's loop may log the error, wait, and retry, or it may halt depending on how the developer structured the logic. The owner does not need to be watching the screen at that exact moment, because the key enforces the limit regardless of human attention or reaction time.

This behavior is one reason the safety model for trading agents differs from traditional trading bots. Bots often rely on internal logic to limit themselves. Agents rely on external policy enforced by the key, because the agent's reasoning is probabilistic and its context window can be manipulated through prompt injection, bad data, or creative interpretation of instructions. The key does not trust the agent. It checks every request against the policy.

How should you rotate or revoke agent access?

Paper trading exists for testing. Any agent should operate in paper mode until its behavior is predictable under realistic market conditions, including how it handles errors and rejected orders. Live trading requires explicit owner authorization of a key. Authorization should be a deliberate step where the owner reviews the scope, sets the budget, approves withdrawal addresses, and acknowledges that trading can lose money, including everything. The authorization step is a human checkpoint that prevents an untested agent from accessing real capital.

Rotation should be routine. If the agent's environment is updated, if the strategy changes, or if there is any suspicion of prompt injection or model drift, the owner should generate a new scoped key and revoke the old one. The kill switch flattens positions and revokes access immediately. It does not require the agent to cooperate or even to be aware that it has been shut down. Because the funds are non-custodial, the owner retains full access even after revocation.

Developers should treat keys as ephemeral credentials tied to a specific strategy version and risk profile. Reusing a single scoped key across multiple agents or strategies increases the blast radius of a failure. Isolating keys per agent is safer because it contains the damage to the scoped budget of the malfunctioning agent. For a practical guide to deployment and monitoring, see run an AI trading agent safely.

Scoped API keys are not an authentication convenience. They are the primary safety mechanism that makes agentic trading with real money viable. They turn an autonomous, probabilistic system into a bounded operator that can act but cannot escape its cage. Trading can lose money, including everything, and scoped keys do not change the underlying risk of the markets. What they change is the relationship between the agent and the capital. The owner defines the boundary, the infrastructure enforces it, and the agent operates within it.

Frequently asked questions