How scoped API keys become unsafe for MCP trading agents

A scoped API key for an MCP trading agent is meant to restrict what the agent can do, but many owners undermine this protection by setting permissions too broadly, skipping the kill switch, or treating the key as a complete safety system rather than one layer of defense. The most common mistakes include granting universal market access when the strategy only needs one venue, failing to set a hard budget cap that the agent cannot override, and neglecting to test the key in paper trading before authorizing live funds. These errors do not violate the non-custodial design, but they create gaps that let an agent lose more money than the owner intended, sometimes within minutes. Understanding these mistakes is essential because the scope is the primary boundary between an owner's capital and an agent's decisions.

What does a scoped API key actually control?

A scoped API key defines the boundaries of an agent's trading activity. The scope specifies several distinct controls:

• ·which markets the agent can access, such as stocks, crypto, perpetual futures, options, or prediction markets
• ·what actions it can take within those markets, including order placement and cancellation
• ·financial limits, such as a maximum order size in plain US dollars
• ·temporal or aggregate budgets, such as a total spend cap for a day or a week
• ·exposure ceilings, such as the maximum number of concurrent positions or total notional value

These boundaries are enforced by the infrastructure, not by the agent itself, which means the agent can request anything within its scope but cannot request anything outside it. The infrastructure checks every request against the scope before it reaches a venue, so even a compromised or hallucinating model cannot bypass the rules by phrasing a request differently. This is a critical distinction. The key does not judge whether a trade is wise, timely, or profitable. It only blocks trades that exceed the owner's predefined limits or that access forbidden markets. If the owner allows options trading but the agent does not understand delta or expiration, the key will still permit the trade as long as the dollar size is within bounds. The scope is a fence, not a strategy. If you want to understand the setup process itself, our guide on how to build scoped API keys for a trading agent step by step walks through the mechanics. The remainder of this article focuses on what happens when those mechanics are misused by owners who assume the scope will do more than it actually does.

Why do broad scopes defeat the purpose of non-custodial design?

Non-custodial architecture means that funds remain in a wallet the owner controls and that the agent can never withdraw to its own addresses or transfer funds outside owner-approved destinations. However, non-custodial does not mean risk-free. If an owner grants an agent broad access to all five market types when the underlying strategy only understands one, the agent is free to make expensive mistakes in the other four. The scope does not evaluate whether the agent comprehends the instrument it is trading. It only checks whether the instrument is on the allowed list.

Suppose an agent is designed to trade prediction markets based on categorical outcomes. If the scoped key also allows perpetual futures, a misinterpreted prompt or an ambiguous tool call could cause the agent to open a leveraged position on a perps venue. The owner still holds custody, but the account balance can still fall rapidly because the agent is operating outside its intended domain. Broad scopes also complicate debugging. When an agent has access to everything, it becomes harder to determine whether a bad trade came from a logic error, a model hallucination, or an unintended tool invocation. The logs become noisy, and the owner must trace activity across multiple venues instead of one.

Narrow scopes force the agent to fail predictably when it tries to do something outside its mandate. A refusal from the API is a clear signal that the agent is drifting. This makes errors visible before they become costly. Owners who resist narrowing their scopes often say they want flexibility, but flexibility for an LLM agent frequently translates into unexpected behavior. This is closely related to the broader problem of what most people get wrong about LLM trading with real money, where assumptions about model behavior often collide with market reality. The scope should reflect the strategy, not the owner's curiosity.

How can a missing kill switch turn a small bug into a large loss?

A scoped key limits the size of each individual action, but it does not always stop an agent from repeating that action many times. An agent stuck in a loop, a model that misinterprets a feedback signal as a request to continue, or a prompt injection that triggers repeated tool calls can all exhaust a budget cap within minutes if there is no external circuit breaker. The per-order limit might be small, but multiplication is a powerful force. Twenty orders in a minute at the maximum size can produce a loss that rivals a single bad large trade.

The kill switch is designed to solve this. It flattens open positions and revokes the API key, cutting the agent off from the markets entirely. One common mistake is treating the kill switch as an afterthought, something to set up after the strategy is working. Another mistake is building the kill switch so that it depends on the same MCP connection as the agent. If the agent is the one reporting its own status, a malfunctioning agent may not report accurately, or it may simply ignore the shutdown command. The kill switch must be independently reachable, ideally through a separate path that the owner controls directly, so that it works even when the agent is unresponsive or its MCP session is hung.

Owners should test the kill switch during paper trading, not assume it will work in live markets. A scope that allows fifty trades is safe only if there is a way to stop the fifty-first trade from happening. The kill switch is the final layer of defense, and like any safety device, it is worthless if it is not installed, not tested, or not independent.

Why is dollar-based sizing not enough without position limits?

Felix normalizes order sizing in plain US dollars, which removes the need for an agent to understand venue-specific contract math, tick sizes, or notional conversions. This is a useful abstraction, but it can lead to a false sense of security. An owner might set a per-order limit of one hundred dollars and assume the risk is small, while forgetting that the agent can place one hundred such orders across multiple markets or even the same market. Without a concurrent position limit, a maximum daily spend, or a total exposure cap, the agent can accumulate far more risk than the owner intended.

The scope must therefore contain multiple nested limits. The per-order size is the smallest ring. The concurrent position limit is the next ring, preventing the agent from holding more than a defined number of positions or a defined total notional at once. The budget cap is the outer ring, preventing the agent from losing more than a defined amount over a day or a week. Together they form a containment structure. Relying on only one of these rings is like locking a door but leaving the window open. An agent that is allowed to scale into a position without a ceiling can turn a small directional bet into an oversized gamble.

If you are building a strategy that scales in and out of positions, you should also read our post on how to control the risks of dollar-based order sizing through a single API. The key insight is that the API normalizes the unit of risk, but the owner must still define how many units are allowed to exist at once. Dollar sizing simplifies the agent's reasoning, but it does not replace the owner's responsibility to set aggregate limits.

How should you test a scoped key before going live?

Paper trading exists precisely so that owners can validate their safety assumptions without risking capital. The most common testing mistake is using different scopes for paper and live. An owner might test with unrestricted permissions in paper mode, observe that the agent behaves well, and then apply a restricted scope for live trading. This is dangerous because the restriction itself can change behavior. If the agent expects to hedge across markets but the live scope blocks one of them, the agent may enter an unintended position or fail to exit an existing one. The agent might also encounter permission errors at critical moments and respond in ways the owner did not anticipate.

The correct approach is to test with the exact same scope that will be used in live trading. Every market whitelist, every dollar limit, and every position ceiling should be identical. Another testing mistake is failing to validate the kill switch. Owners often verify that trades execute correctly but never trigger the panic switch to confirm that positions flatten and the key revokes. A kill switch that is not tested is a hypothesis, not a safety feature. A third mistake is skipping the explicit authorization step. Felix requires owner authorization before a live key is activated, but some owners rush through this step without reviewing the budget cap, the exit plan, and the market whitelist. Paper trading is the time to discover that a budget cap is set too high or that a position limit is missing. Live trading should only begin after the owner has confirmed that every layer of the scope behaves as expected under realistic conditions, including simulated failures and rejections.

What happens when you forget to revoke old keys?

Scoped API keys should have a lifecycle. An owner might create a key for an experiment, run the experiment for a week, and then move on to a new strategy without revoking the old key. If the old key remains valid, it becomes a dormant liability. An agent instance that is still running in the background, a cached environment variable in a deployment script, or a reused configuration file could accidentally invoke the old key. This is especially risky when iterating quickly with LLM agents. A model might be swapped, a prompt updated, or a new MCP client connected, but the underlying credentials remain the same.

The owner thinks the new agent is constrained by a new, tighter scope, while the old key still permits wider access. The agent might even be using the new key for most actions but fall back to the old key during a specific tool call if the client configuration is ambiguous. The best practice is to revoke keys at the end of every experiment and to create new keys for each distinct deployment. This forces a clean review of the scope and prevents credential drift. It also creates a clear audit trail. If a key was only valid for a single week of testing, it is easy to correlate any activity with that specific experiment. Long-lived keys blur the audit trail and increase the chance that an old scope will conflict with a new strategy. Revocation is as important as creation.