How kill switches enforce hard limits that trading agents cannot cross

A kill switch for a trading agent is not a polite request to stop. It is a boundary enforced by cryptographic keys and policy infrastructure that sits between the agent and every order endpoint. When a hard limit is breached, the switch severs the authorization path before the next order reaches any venue. The agent may continue to reason, but it loses the ability to move funds or open positions.

What makes a limit hard rather than soft?

Soft limits are instructions written into a system prompt or a strategy script. An agent can drift away from them if its reasoning changes, if the prompt is engineered around, or if a bug introduces unexpected behavior. Hard limits live in the authorization layer, entirely outside the agent's process. They are encoded in the key material that signs orders and in the wallet policy that controls the funds. Because the agent never holds the root key, it cannot rewrite its own constraints or generate a credential that lacks them.

Felix implements this through scoped API keys tied to a wallet the owner controls. Each key carries spend caps, allowed instruments, maximum position sizes, and approved venues. The agent receives a session credential that is valid only within those bounds. If the agent tries to size an order in a way that would breach the cap, the normalization layer rejects the request before it is signed. The agent receives a standard error response, not a success. It cannot override the decision because the decision is made by infrastructure it does not own.

This design is necessary because an AI agent is not a deterministic script. It reasons over market data, news, and historical patterns, and it can generate outputs that the owner did not explicitly anticipate. A hard limit treats the agent as an untrusted component inside a trusted perimeter. The owner defines the perimeter, and the infrastructure enforces it without requiring the agent to cooperate or even understand the boundary. How guardrails keep AI trading agents from losing everything

Where does the kill switch sit in the execution path?

The kill switch is not a single button pressed by a human at the last second. It is a distributed check that runs at multiple points between the agent's intent and the venue's matching engine. First, the policy engine evaluates every order request against the scoped key and the current budget state. Second, the signing layer applies the wallet rules that prevent withdrawals to unapproved addresses. Third, a monitoring process watches for anomaly patterns, such as rapid order submission, repeated failed requests, or drift toward an instrument not on the allow list.

Because Felix is non-custodial, the owner funds a wallet that requires owner approval for any withdrawal. The agent can spend within its budget to trade across stocks, crypto, perps, options, and prediction markets, but it cannot move funds to an external address. The kill switch leverages this same boundary. When triggered, it revokes the scoped key and flattens open positions through pre-approved exit plans. The agent loses its ability to sign, not merely its permission to ask. The infrastructure stops listening to that credential.

Orders are sized in plain US dollars, and the API normalizes venue-specific contract math. This means the budget cap is denominated in a unit the owner intuitively understands. Suppose an owner sets a two hundred dollar daily cap. That budget is two hundred dollars regardless of whether the agent is trading a perp contract or a stock. The normalization layer converts the intent and checks the cap before the signing layer ever sees a venue-specific payload. This prevents the agent from hiding size inside complex contract notation.

How do scoped keys prevent the agent from overriding itself?

Scoped keys are credentials with baked-in constraints. They are derived from the owner's master key through a process that does not reveal the master secret. The agent receives only this derived credential. It can request an order for a specific dollar amount of a stock or a perp contract, but it cannot request a withdrawal, cannot increase its own budget, and cannot generate a sibling key with looser rules.

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

curl -X POST https://api.felix.trade/v1/orders \
  -H "Authorization: Bearer YOUR_KEY" \
  -d '{
    "market": "stock",
    "side": "buy",
    "usd_size": 100,
    "symbol": "EXAMPLE"
  }'

In this illustrative example, suppose the key is scoped to a one hundred dollar cap. If the agent has already spent ninety dollars in the current period, the request for one hundred dollars is rejected because the remaining budget is insufficient. The agent does not get to negotiate. The limit is not a suggestion in the prompt; it is a property of the key. Even if the agent tries to replay an old request, modify the payload, or split the order into two smaller requests that sum over the cap, the policy engine tracks cumulative spend and rejects the violation.

The agent can never extract the secret material from the key. It is a bearer token, not a private key. The signing happens in a separate process that the agent cannot access. This means the agent cannot produce a signature that bypasses the policy engine. The most it can do is ask, and the infrastructure can refuse.

Why does non-custodial design change the trust model?

In a custodial setup, the agent or the platform holds funds. A kill switch is a database flag that the platform promises to respect. The owner must trust the platform to honor the flag quickly, to not suffer downtime during the critical moment, and to not have internal controls that override the owner's intent. In a non-custodial system, the owner retains the root key. The agent operates with a restricted credential that is cryptographically incapable of stealing funds.

This means the kill switch can be enforced by the wallet and the signing infrastructure itself, not by a server promise. When the switch is activated, the scoped key is revoked. The agent cannot generate a valid signature for a new order because the infrastructure no longer recognizes the credential. This is a mathematical halt, not a policy halt. The owner does not need to trust Felix to do the right thing; they need to trust the cryptography and the wallet logic that they can audit. The architecture that keeps AI trading agents secure in 2026

Trading can lose money, including everything. A kill switch does not guarantee that a losing position recovers. It only guarantees that the agent cannot make the position larger or open new ones after the boundary is crossed. The owner still bears market risk on existing trades until they are closed. The switch is a containment tool, not a profit protection tool.

What happens after the switch is flipped?

Activation triggers a deterministic sequence. The scoped key is revoked immediately. Any open orders that have not yet reached a venue are cancelled. Positions are flattened according to the exit plan defined by the owner, which may include market orders or scheduled unwinds. The agent receives a revocation event and can log the reason for later analysis, but it cannot appeal the decision or request reinstatement.

The owner is notified through their configured channel. They can inspect the audit trail to see which limit was hit, what the agent attempted, and how the infrastructure responded. If the owner chooses to reauthorize trading, they must generate a new scoped key with a new budget and new constraints. The old key is never reinstated. This prevents a compromised or exhausted key from being reused accidentally.

This immutability is important for security hygiene. Reusing a key that has already reached its limit would create a gap in the audit log and could allow an attacker to replay old requests if the key were ever leaked. Each key is single purpose and time bounded. The owner treats key rotation as a normal operational step, not an emergency exception.

How should owners test kill switches before live trading?

Paper trading exists for testing; live trading requires explicit owner authorization of a key. Owners should test the kill switch in paper mode by setting artificially low limits and observing the halt. They should verify that the agent cannot continue to submit orders after revocation, that the audit log records the exact trigger, and that the exit plan flattens positions as expected.

Owners should also test edge cases. The agent might try to send multiple orders in rapid succession to race the budget check. The policy engine should handle the concurrency and enforce the cap exactly once. Owners should verify that partial fills are accounted for correctly, so that a half-filled order consumes only the filled portion of the budget.

Beginners often misunderstand that autonomy means the agent is in charge. In reality, the owner is always in charge through the hard limits encoded in the keys. What beginners misunderstand about autonomous trading systems Testing the switch is part of defining that authority. An untested switch is a hypothesis, not a control.