How to automate trading agents with webhooks without losing custody

Webhooks let a trading agent react to external events in real time by sending an HTTP request that triggers an order without manual confirmation. Because the agent can act instantly, a compromised webhook endpoint, a delayed signal, or a misconfigured filter can cause unintended trades that lose money, including the full allocated budget. Non-custodial infrastructure keeps the owner in control of funds by enforcing budget caps, scoped permissions, and withdrawal limits that the agent cannot override, even when it trades automatically.

What are webhooks and why do trading agents use them?

A webhook is a user-defined HTTP callback. Instead of polling an API repeatedly for new data, a webhook pushes information to a server the moment an event occurs. For a trading agent, that event might be a price crossing a threshold, a news headline published by a feed, a change in implied volatility, a signal from another model, or a predefined rebalance schedule. The agent receives the payload, parses it according to its instructions, and can place an order within milliseconds. This removes the need for a human to monitor screens and click buttons, which is the point of automation. It also removes the human from the decision loop at the exact moment when context and restraint matter most. Once the webhook is connected, the agent becomes a listener that acts on trust, and trust without verification is a vulnerability.

The appeal is speed and continuity. An agent can listen to multiple sources across stocks, crypto, perpetual futures, options, and prediction markets through a single API, normalizing every order into a plain dollar amount so the owner does not need to think about contract sizes or margin formulas. When a signal arrives at three in the morning, the webhook wakes the agent and the agent acts. The owner does not need to be online. That convenience is real, but it trades human judgment for latency. Latency without guardrails can turn a small error into a large loss very quickly.

What can go wrong when an agent acts on external signals?

Automation does not fail only because of bugs. It fails because of timing, trust, and unexpected interactions between systems. A webhook payload that looks legitimate can be replayed, spoofed, or delayed by a network intermediary. A network blip can cause a buy signal to arrive after the price has already moved, turning an expected entry into a bad fill. An agent that listens to multiple webhooks can enter an amplification loop, where one trade triggers another signal, which triggers another trade, until the budget is exhausted. A single missing field in a JSON payload can cause the agent to default to a maximum size because the prompt told it to fall back to a safe value that was not actually safe.

• ·Spoofed or replayed payloads. If a webhook signing secret leaks, an attacker can forge a signal and force the agent to trade on false information.
• ·Delayed or out-of-order delivery. HTTP is not guaranteed to be instant, so a stale signal may arrive after market conditions have changed.
• ·Amplification loops. A webhook handler that both emits and consumes events can create a feedback cycle that piles on risk before a human notices.
• ·Misinterpretation by the LLM. If the payload contains unstructured text, the model might hallucinate intent or extract the wrong parameters.
• ·Dependency failures. If the webhook provider stops sending close signals, the agent may hold a losing position indefinitely.

Each of these risks is manageable, but only if you assume they will happen rather than hoping they do not. The correct posture is to design the system so that a worst-case webhook event cannot steal funds or blow through the entire account.

How does non-custodial design limit the damage?

Non-custodial infrastructure means the agent never holds the owner’s funds. The money sits in a wallet the owner controls, and the agent receives only a scoped API key that can place orders within hard limits. The key cannot withdraw to an external address, cannot change permissions, and cannot approve its own replacement. Even if an attacker gains control of the webhook handler and the agent itself, the capital remains in the owner’s wallet. This is not a guarantee against loss, because bad trades can still lose money, including the entire budget allocated to the agent. It is a guarantee against theft. The agent can only spend what the owner has explicitly made available, and no more.

Felix implements this through layered controls that are independent of the agent’s logic. Budget caps prevent the agent from spending more than a fixed dollar amount over a defined period. Position limits restrict how large any single trade can be, regardless of what the webhook claims the opportunity size is. Exit plans define conditions under which the agent must close a position, such as a time decay or a drawdown threshold. A panic switch lets the owner flatten everything and revoke the key instantly. These controls are enforced by the infrastructure, not by the agent, so a compromised agent cannot disable them. If you want a deeper breakdown of how to configure these protections, read How to build guardrails for a trading agent.

The owner also controls withdrawal addresses. The agent can trade, but it can never send funds to itself or to an address the owner has not pre-approved. This removes the largest incentive for remote attackers. They might force the agent to make bad trades, but they cannot steal the remaining balance. The owner can revoke access at any time, and the key becomes useless the moment it is revoked.

How should you authenticate and scope webhook requests?

Every webhook should be treated as untrusted until proven otherwise. Start with a signature. The sender should sign the payload with a shared secret using HMAC, and the receiver should verify that signature before passing the data to the agent. Include a timestamp and reject any payload older than a few seconds to prevent replay attacks. Use an IP allowlist if the sender publishes a static range, and terminate TLS at a trusted boundary so the payload cannot be read or modified in transit. Rotate the signing secret regularly and store it in a secure vault, never in the agent’s prompt or in a public repository.

Scope the API key so that the webhook handler has the minimum authority needed. If the webhook is only meant to enter positions, do not give it permission to exit, and vice versa. If it is only meant to trade one market type, restrict it to that market. Limit the notional dollar amount per order and enforce a daily cap. The goal is to ensure that a single forged webhook can only do a small, bounded amount of harm. If the webhook handler only needs to read market data, do not give it order placement rights at all.

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

{
  "method": "POST",
  "headers": {
    "X-Webhook-Signature": "sha256=...",
    "X-Request-Timestamp": "..."
  },
  "body": {
    "agent_key": "YOUR_KEY",
    "action": "place_order",
    "market_type": "perps",
    "symbol": "BTCUSD",
    "notional_usd": 100,
    "side": "buy"
  }
}

Do not let the LLM parse raw webhook text directly. Build a dedicated parser that validates the schema, checks the signature, and extracts only the fields the agent is allowed to use. Pass those fields to the agent as structured data. This reduces the attack surface for prompt injection and prevents the model from hallucinating trades based on ambiguous language.

What runbooks and kill switches should you prepare before going live?

Before you enable a live webhook, write a runbook that defines exactly what should happen when the webhook fires under normal conditions and under stress. Specify how many times the agent may act on the same signal within a one-minute window. Define what constitutes a duplicate and how the system should deduplicate based on a unique identifier or timestamp. State the maximum number of open positions the agent may hold simultaneously. Write these rules as infrastructure constraints, not as prompts, because prompts can be bypassed or misinterpreted by a clever attacker or a confused model.

Install a circuit breaker. If the agent loses more than a predefined percentage of its daily budget within a short window, the system should stop accepting new webhook events and flatten existing positions. The circuit breaker should be enforced by the trading infrastructure, not by the agent, so a compromised or confused agent cannot override it. The threshold should be tight enough to matter but loose enough to avoid tripping on normal volatility. Finding that balance requires testing.

The panic switch is the final layer. It should revoke the API key, cancel open orders, and flatten all positions across every market type. Test it in paper mode until you are certain it works in under a few seconds. Store the revocation command in a place the owner can reach without relying on the agent or the webhook provider. If the agent is connected through an MCP client, the owner should know how to sever that connection independently. The panic switch is only useful if you can find it when you are panicking.

How do you test automation without risking real capital?

Every webhook flow should be exercised in paper trading before it touches a live market. Paper mode lets you observe how the agent behaves when it receives a malformed payload, a replayed timestamp, or a burst of fifty signals in ten seconds. You can verify that the signature check rejects bad requests, that the circuit breaker trips at the right loss threshold, and that the panic switch flattens positions correctly. You can also observe how the agent behaves when the webhook provider is down and the agent is left holding positions without fresh signals.

Mirror the production environment as closely as possible. Use the same webhook URLs, the same parsing logic, and the same key scoping rules. The only difference should be the paper flag. Once the agent behaves predictably through multiple simulated market conditions, the owner can explicitly authorize a live key. Until that authorization happens, the infrastructure treats the agent as a spectator. For a step-by-step guide on this workflow, see How to run a non-custodial trading agent through MCP: a practical checklist.

Many people assume that an LLM will naturally be cautious with real money. That assumption is wrong. Models do not feel risk. They execute the patterns they have learned, and if the prompt or the webhook payload nudges them toward action, they will act. You should read What most people get wrong about LLM trading with real money before you connect any external signal to a live account. Understanding the psychology of the machine, or the lack thereof, is part of the safety design.