How scoped API keys let an agent trade without taking custody of your funds

A scoped API key is a permissioned credential that lets an automated agent place orders, manage positions, and read balances without ever receiving the ability to withdraw funds to itself or change account ownership. Because the key is bound to a wallet you control and restricted to specific actions and budget limits, the agent can trade across stocks, crypto, perps, options, and prediction markets while your capital remains in your account. If you revoke the key or trigger the kill switch, the agent loses access instantly, and your funds stay where they are.

What can a scoped API key actually do?

When you create a scoped API key, you are defining a narrow channel between your agent and the markets. The key allows the agent to request price data, read current balances, and place orders that are normalized into plain US dollars, which removes the need for the agent to understand venue-specific contract sizes or decimal conventions. This single credential works across stocks, crypto, perpetual futures, options, and prediction markets, so the agent can build a multi-market portfolio from one integration point. The scope is set by you during key creation, and it typically includes trading actions within a predefined budget, reading open positions, and updating working orders or exit plans. It does not include administrative privileges such as adding withdrawal addresses, changing account settings, approving new devices, or modifying the key’s own permissions. In practice, this means the agent can act as a trader but not as an account owner. When you first connect an agent, the key operates in a paper trading environment by default. This lets the agent place simulated orders against live market data so you can observe its behavior, verify that it respects the scope, and debug logic errors without risking capital. Moving to live trading requires an explicit owner authorization step that confirms the key, the wallet, and the safety limits are exactly what you intend. This structure is what makes it possible for an AI agent to trade across disparate markets without forcing you to pool funds on a custodial platform or share a master password. If you want to understand how the non-custodial layer works across accounts, you can read more about how AI agents trade across markets without taking custody of your funds.

What is the key physically prevented from doing?

The most important restriction is withdrawal. The system is non-custodial by construction, which means your funds sit in a wallet or brokerage account that you control, and the agent receives no capability to move those funds to an external address that you have not already approved. Even if the agent’s logic is compromised or its instructions are hijacked, the worst outcome is limited to the trades it can place within the budget cap. It cannot drain the account, transfer assets to itself, reassign ownership, or change the list of approved withdrawal addresses. This is a hard boundary encoded in the key’s permissions and enforced by the API on every request, not merely a policy promise that could be bypassed. The distinction matters because many automation tools in the market require you to deposit funds into a shared or managed account, which means you are relying on the operator’s internal controls and solvency. A scoped key avoids that model entirely. The agent operates on your account, not its own. It sees only the balances and positions it needs to trade, and it can only interact with markets through the API’s normalized interface. That separation is what keeps the capital under your control at all times. You retain the ability to log into your wallet or brokerage directly, view the same positions the agent sees, and intervene manually if necessary. The key is simply a guest pass with a very specific list of allowed rooms, and it cannot copy itself or upgrade its own privileges.

How do budget caps and position limits interact with the key?

A scoped key is only half of the safety layer. The other half is the set of limits you attach to it. You can define a maximum daily or total budget, a per-position size ceiling, and a drawdown threshold that triggers an automatic halt. The API evaluates every order against these constraints before it reaches a market venue. If the agent requests a trade that would breach the cap, the API rejects the request and returns an error to the agent. The key does not grant the agent any power to override, raise, or ignore these limits. They are owner-level controls that require separate authentication to change, which means the agent can only lose what you have already decided to risk. This interaction is important because it separates the credential from the policy. The key proves who is asking, and the limits define what is allowed. Together they create a boundary that persists even if the agent behaves unexpectedly. You can also attach an exit plan that defines take profit, stop loss, or time-based close logic, so the agent is not making open-ended decisions once a position is open. The exit plan runs as a separate check, and the agent cannot cancel it unless the scope explicitly allows order management and the action stays within the budget. For a practical guide on configuring these boundaries, read how to set spend caps and drawdown limits for trading agents. You should test the interaction between the key and the caps in paper trading first, because an agent that repeatedly hits limits without handling errors gracefully can waste cycles or leave positions unbalanced.

How does an agent connect using the key?

Agents connect through two main paths. The first is an MCP tool, which lets an AI assistant in Claude, Cursor, or another MCP client call trading functions as if they were native commands. The second is a direct REST API integration, which is useful for custom software or headless bots. In both cases, the key is passed as a credential that identifies the agent and enforces its scope in a single request. The API then handles the normalization of orders into plain US dollars and the translation to venue-specific formats. The exact request schema is in the docs; the shape looks like this.

{
  "mcpServers": {
    "felix": {
      "command": "npx",
      "args": ["-y", "felix-mcp"],
      "env": {
        "FELIX_API_KEY": "YOUR_KEY",
        "FELIX_SPEND_CAP_USD": "1000",
        "FELIX_ALLOWED_MARKETS": "stocks,crypto,perps"
      }
    }
  }
}

The server reads the key and enforces the spend cap and market restrictions on every tool call. If you are building a custom integration, you pass the same key in the Authorization header and receive normalized USD sizing and error responses when limits are hit. The key is the same regardless of whether the agent trades stocks, crypto, or prediction markets, which reduces the integration surface you need to maintain. You do not need to manage separate credentials or different formatting rules for each venue.

What happens when you revoke access or hit the kill switch?

Revocation is instant and irreversible. When you disable the key through the dashboard or trigger the panic switch, the API invalidates the credential immediately. Any open positions can be flattened automatically according to your exit plan, and the agent receives no further market data or trading capability. Because the key was scoped from the start, revocation is surgical. You do not need to rotate master passwords, change wallet seeds, or move funds to a new address. You simply turn off the key, and the agent goes dark while your capital remains untouched in your account. The kill switch is a critical piece of real money safety, and you can learn how to configure it in how to add a kill switch to a trading agent with real money. This design is possible because the key never held custody. If it had, revocation would be a much slower process involving withdrawals and account closures. Instead, the key is just a permission layer sitting on top of your existing account. Removing it restores the status quo before the agent was connected. You should test the revocation flow during paper trading so you know exactly how quickly positions flatten and whether any manual steps remain. In some cases, you may want to keep a position open even after revoking the agent, which is possible if the exit plan allows owner-level holds. The important point is that the choice is yours, not the agent’s.

How do you move from paper testing to live authorization?

Every scoped key begins in a paper trading environment where orders are simulated against real market data. This lets you verify that the agent respects your budget, that the exit logic triggers correctly, and that the MCP tools or REST calls behave as expected. You should treat paper trading as a rehearsal for the scope and the safety stack, not just the strategy. Common mistakes include testing with unlimited paper budgets and then discovering the live cap is too tight, or forgetting to check how the agent handles rejected orders when it hits a limit. The agent might also assume it can read private account details that are outside the key’s scope, which will cause errors in live mode that did not appear in paper. Once you are confident in the behavior, you explicitly authorize the key for live trading. This is a deliberate owner action, not an automatic upgrade. After authorization, the same key and the same safety limits begin executing with real money, and the risk of loss becomes real. You can lose your entire budget, including the amounts allocated to the agent, so you should only authorize after reviewing the spend caps, the exit plan, and the kill switch sequence. For guidance on that transition, see what it takes to move an AI trading agent to live trading in 2026. The authorization step exists to ensure that no agent can ever graduate itself from simulation to real money without your explicit consent.