How MCP trading tools enforce hard limits that agents cannot cross

MCP trading tools connect large language models to financial markets through a simple protocol, but the critical architecture is not the connection itself. It is the policy layer that sits between the model and the money, enforcing hard limits on every order before any request reaches a venue. These limits are owner-defined, agent-agnostic, and enforced by infrastructure the agent does not control, so the model cannot talk, prompt, or error its way past them.

What is the MCP layer in agentic trading?

The Model Context Protocol, or MCP, is an open standard that lets an AI client discover tools, read their schemas, and call them. In the context of agentic trading, an MCP server exposes a set of actions such as placing an order, checking a balance, or flattening a position. The agent, whether it runs inside Claude, Cursor, or another MCP client, does not need to know the underlying API of a stock broker, a perps venue, or a prediction market. It only needs to understand the tool definitions that the server provides.

This abstraction is powerful because it collapses five market types into one mental model. The agent can reason in plain USD, ask to spend fifty dollars on a position, and let the server normalize the contract math for the specific venue. However, abstraction also creates a trust problem. The agent is an autonomous process that may misinterpret a prompt, hallucinate a parameter, or simply execute a strategy that drifts from the owner's intent. The MCP layer must therefore be more than a translation bridge. It must be a control surface where the owner defines what is allowed and the system enforces those boundaries before any money moves.

When you run a trading agent from Claude using MCP, the agent holds a conversation context, not a trading key. The key lives in the MCP server, which is where the hard limits are anchored.

Where do hard limits live in the stack?

A common mistake is to imagine the agent as a trusted client that merely asks a server for permission. In the Felix architecture, the agent is explicitly untrusted. It sits on the far side of a boundary, and every request it makes must cross a series of gates before it becomes an executed order.

The stack looks like this. The agent generates an intent based on its strategy or a prompt. The MCP server receives that intent and translates it into a structured request that the policy engine can evaluate. Before the request goes any further, it hits the policy engine. The policy engine evaluates the request against owner-defined rules that were configured before the session began. Only if the request passes every rule does it reach the execution router, which then forwards it to the appropriate venue. The agent never touches the router, the signing key, or the venue API directly.

Hard limits are stored in the policy engine, not in the agent's memory or prompt. This means they persist across sessions, survive prompt injection attempts, and do not depend on the model's willingness to behave. The owner configures them through a separate interface, and they are bound to the scoped key rather than to the conversation.

The core limit types include:

• ·Scoped keys that restrict which tool methods the agent can invoke. For example, a key may allow placing orders and reading balances but deny withdrawals or leverage changes.
• ·Budget caps that limit total spend over a time window. Once the cap is reached, the policy engine rejects further spend requests regardless of the agent's reasoning.
• ·Position limits that cap notional exposure per symbol or market type. This prevents an agent from concentrating the entire budget in a single instrument.
• ·Exit plans that define how and when positions should be closed, such as time-based or drawdown-based triggers.
• ·A panic or kill switch that the owner can trigger at any time. When activated, it flattens positions and revokes the key.

These controls work together. A scoped key might allow the agent to trade, but the budget cap decides how much, and the position limit decides how concentrated the allocation can be. Common mistakes with scoped API keys for trading agents often stem from treating scope as the only line of defense, when in reality it is just the first gate.

How does the policy engine evaluate every request?

The policy engine is a separate service from the MCP server and from the venue-facing execution layer. It maintains its own accounting state so that it can make decisions in real time without relying on the agent's honesty or the venue's latency.

When a request arrives, the engine performs a series of independent checks. It asks whether the action is within the key's scope. It asks whether the order size, denominated in plain USD, fits within the remaining budget for that time window. It asks whether the resulting position would violate a concentration limit. It asks whether the key is still active or if the panic switch has been thrown. Each check is deterministic and stateful. The engine does not parse the agent's natural language reasoning. It only reads the structured fields of the request.

This design is intentional. Natural language is ambiguous, but a structured request contains a specific action, a specific amount, and a specific market. The policy engine evaluates the concrete intent, not the agent's justification for it.

Because the engine maintains its own spend counters and position tables, it can prevent race conditions. If an agent sends two rapid requests, the engine accounts for both before either reaches a venue. This prevents the agent from accidentally or intentionally exceeding a budget by issuing parallel calls.

If any check fails, the engine returns a rejection to the MCP server, which surfaces it to the agent as a tool error. The agent can then log the failure, notify the owner, or adjust its strategy. Crucially, the rejection happens before an order is created, so there is no risk of a partial fill or an accidental position that must be unwound. How audit logs and observability keep MCP trading agents accountable gives a fuller picture of how these decisions are recorded.

Why can the agent never override its own limits?

The architecture is built on a simple security principle: the entity that creates the request must not be the entity that authorizes it. The agent creates the request. The policy engine authorizes it. They run in separate trust domains, and the agent has no administrative path to the engine.

Even if the agent is jailbroken or receives a malicious prompt, it cannot redefine its own scope because the scope is cryptographically bound to the key. The agent does not possess the key; it only possesses a session context that lets it speak to the MCP server. The server, in turn, holds the key but does not hold the policy. The policy engine holds the rules. This three-tier separation means that compromising the conversation does not compromise the controls.

The session context itself is short-lived and narrowly bounded. If the agent's host environment is restarted, the conversation resets, but the policy engine retains its rules and state. The owner does not need to reconfigure limits after every session.

There is no MCP tool that allows the agent to raise its budget cap, add a new withdrawal address, or disable the kill switch. Those operations require owner authentication through a separate channel. The agent cannot prompt the policy engine into an exception because the engine does not engage in dialogue. It evaluates requests against static rules and returns allow or deny.

This design also protects against honest errors. A model may miscount, misread a unit, or generate an order size that is an order of magnitude too large. The policy engine catches the discrepancy because it checks the numeric value against the hard cap, not against the agent's internal reasoning. How non-custodial trading keeps your money safe when an AI agent trades explains how custody and control remain with the owner even as the agent operates.

What happens when a limit is reached?

When a hard limit is reached, the policy engine simply stops allowing requests that would violate it. The experience for the agent is a clean failure, not a silent truncation. If the daily budget cap is one hundred dollars and the agent attempts a trade that would bring the total to one hundred ten, the engine rejects the request and preserves the remaining ten dollars of headroom. The agent cannot chip away at the limit by sending many small requests that individually look reasonable but collectively exceed the cap, because the engine tracks the aggregate.

The panic switch is the ultimate limit. It is a manual control that the owner can trigger at any time, and it operates as a hard revocation. When thrown, it flattens open positions and removes the key's ability to place new orders. The agent cannot intercept this signal because the signal travels through the owner's channel, not through the MCP conversation. Because the switch is bound to the owner's identity and not to the agent's session, it works even if the agent is unresponsive or stuck in a loop. The owner retains final control over the funds at all times.

It is important to state plainly that these limits prevent unbounded activity, not unbounded loss. Trading can lose money, including everything you allocate to the agent. A budget cap of one thousand dollars means the agent cannot spend more than one thousand dollars. It does not mean you are guaranteed to keep one thousand dollars. Markets move, positions can lose value, and an exit plan is the control that defines how long a losing position is allowed to remain open.

How should developers test limits before going live?

Developers should treat hard limits as part of the trading system, not as an afterthought. The Felix infrastructure includes paper trading, which runs the same policy engine against simulated balances. This lets you verify that a budget cap triggers at the right threshold, that a scoped key correctly blocks disallowed actions, and that the agent handles rejection gracefully.

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

{
  "key": "YOUR_KEY",
  "intent": {
    "market_type": "perps",
    "side": "buy",
    "spend": "50.00",
    "currency": "USD"
  }
}

In this illustrative example, the policy engine would evaluate the fifty-dollar spend against the remaining budget and the scoped permissions for perps before allowing the request to proceed to paper or live execution. You should verify the current fields and paths against the docs at /docs, because the schema evolves.

Testing should include deliberate attempts to violate limits. Send a request that exceeds the cap and confirm the rejection. Send a request to a disallowed market type and confirm the scope error. Trigger the kill switch during a session and confirm that the agent receives a revocation notice. Only after the limits behave predictably in paper trading should you authorize a key for live trading. Live authorization is an explicit owner action that swaps the simulated environment for real balances while keeping the same policy rules intact. Because the policy engine is shared between paper and live environments, the only variable that changes is the balance source. This reduces the risk of configuration drift between testing and production.