How a news-driven LLM agent trades real money without taking custody

A news-driven LLM trading agent reads external headlines, evaluates their potential market impact, and emits buy or sell signals. Those signals do not touch your funds directly. Instead, they pass through a non-custodial execution layer that translates intent into orders, enforces dollar denominated budgets, and blocks any withdrawal. The architecture separates perception, reasoning, and execution so that the LLM can act quickly but cannot act outside its scoped authority.

How does news enter the system without compromising safety?

The agent does not browse the open web. A dedicated ingestion layer receives structured headlines from trusted feeds, strips unnecessary markup, and converts each item into a sanitized text block before it reaches the LLM context window. This prevents prompt injection through malicious headlines or hidden HTML. The ingestion layer also timestamps each item and logs the raw source, so the reasoning layer can later explain why a particular signal was generated. Separating ingestion from reasoning means that even if a feed is compromised, the LLM only receives plain text rather than executable instructions or hidden tokens. The agent never holds credentials for news APIs in the same memory space as trading keys, reducing the blast radius of a compromise. Developers should treat the ingestion layer as a security boundary. If the feed includes social media posts, those should be filtered for length and stripped of links before the LLM sees them. The goal is to give the model enough context to reason, but not enough rope to hang itself.

Why does the LLM reason in plain dollars instead of contracts?

Different venues use different contract sizes, tick values, margin formulas, and decimal conventions. Asking an LLM to compute the exact number of perpetual contracts or option legs for a specific venue is a reliable source of error. Instead, the agent reasons in notional US dollars: it decides to allocate a certain dollar amount to a given direction. The API then normalizes that dollar value into the correct quantity native to the venue. This abstraction applies across stocks, crypto, perps, options, and prediction markets. The agent does not need to know whether an asset trades in shares, contracts, or event units. It simply states intent, and the execution layer handles the arithmetic. Many developers overlook this point, which is one reason what most people get wrong about LLM trading with real money involves letting the model do its own sizing math. When an LLM attempts to calculate leverage, notional value, or contract multipliers, it can hallucinate numbers or confuse decimal places. Dollar denominated reasoning removes an entire class of arithmetic errors and makes the agent's logic portable across market types. This is especially important for options and prediction markets, where contract structures vary widely. An LLM that reasons in dollars can express a desire to allocate two hundred dollars to an outcome without understanding tick size or expiration mechanics. The execution layer handles those details and rejects the order if the venue cannot fulfill the intent within the stated budget.

What hard limits sit between the LLM and the market?

Every trading key is scoped. The agent can place orders within a pre-approved budget, but it cannot withdraw funds, change withdrawal addresses, or increase its own limits. Budget caps are set in plain dollars, so a developer can say that the agent may lose at most one thousand dollars before trading stops. Position limits prevent oversized concentration, and exit plans define how the agent must reduce exposure when drawdown thresholds are hit. A panic switch flattens all positions and revokes the key immediately. These controls are not suggestions inside the prompt. They are enforced by the infrastructure itself, which is why MCP trading tools enforce hard limits that agents cannot cross. You can also read about how spend caps and drawdown limits protect your funds while an agent trades. The limits are checked on every order request, not just at setup, so an agent that suddenly tries to double its position after a volatile headline will be blocked in real time. Even if the LLM is jailbroken or the prompt is bypassed, the underlying key permissions and API level budget enforcement remain intact. Drawdown limits are particularly important for news-driven strategies because headlines can cluster. A single event may generate twenty related headlines in an hour, and without a drawdown cap, the agent might trade each one until the budget is exhausted. Hard limits enforce a cooling-off period or a total loss ceiling that no sequence of headlines can breach.

How does the execution layer translate intent into orders?

The exact request schema is in the docs. The shape looks like this. The agent sends an intent object that contains the symbol, the desired notional dollar amount, the side, and a nonce. The API validates that the request stays within the scoped key's budget, converts the dollar value into the quantity native to the venue, and routes the order. The response returns the filled notional, the average price, and the remaining budget for that key. Paper trading uses the same path, so behavior can be validated before live funds are at risk. Live trading requires explicit owner authorization of the key, which prevents accidental deployment. The nonce prevents replay attacks, and the direct mapping between intent and order means the agent cannot hide complex multi-leg trades inside a single request. Every action is logged, and the owner can audit the chain from headline to fill. The execution layer also handles partial fills and rejected orders transparently. If the venue rejects an order because of insufficient margin or liquidity, the API reports the reason back to the agent in a standardized format. The agent can then decide whether to retry, resize, or wait, but it cannot bypass the budget cap by splitting a rejected order into smaller pieces. The system aggregates exposure across all venues under the same key, so an agent trading both a stock broker and a perps venue cannot exceed its total allocated budget by splitting activity across market types.

curl -X POST "https://api.felix.trade/..." \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "symbol": "EXAMPLE_ASSET",
    "notional_usd": 500,
    "side": "buy",
    "nonce": "unique-nonce-123"
  }'

How does the human retain control after the agent starts?

Automation does not mean abdication. The owner holds the wallet and can revoke the agent's key at any time through the dashboard or an API call. The panic switch flattens all positions and disables the key in a single action, which is useful when news is ambiguous or the agent behaves unexpectedly. Withdrawal addresses are owner approved only, so even a compromised agent cannot send funds to an external wallet. It is also wise to set a regular schedule for reviewing logs, because an LLM can misinterpret a headline in subtle ways. How to set guardrails for a trading agent covers the practical steps for configuring these controls before the first live order. Some owners choose to require a human confirmation step for trades above a certain size, effectively turning the agent into a high speed research assistant rather than a fully autonomous trader. The architecture supports both modes, but the safety layer is always active regardless of how much autonomy is granted. Logs should be stored outside the agent's own memory, ideally in an immutable store or a separate logging account, so that a compromised agent cannot erase its tracks. Reviewing these logs periodically helps the owner spot drift in the agent's reasoning, such as an increasing tendency to trade on rumor rather than confirmed events. The human remains the final arbiter of strategy validity.

Why is the architecture non-custodial by construction?

In a custodial setup, the agent or the platform holds the funds. In this architecture, the funds sit in a wallet the owner controls. The agent receives a scoped key that can place orders and query balances, but it cannot initiate withdrawals. The API enforces that all outbound transfers go to addresses that the owner has explicitly whitelisted. If the agent is turned off, the funds remain in the owner's wallet. If the agent is compromised, the attacker can only trade within the pre-set budget, not steal the underlying capital. The worst-case loss is bounded by the spend cap, not by the total wallet balance. This distinction matters because trading can lose money, including the entire amount allocated to the agent, but the remainder of the owner's funds stay untouched. Non-custodial design also means the owner can move funds to a new wallet or change the agent's permissions without waiting for a third party. The agent is a delegate, not a trustee.

What should a developer validate before going live?

Paper trading exists for testing, and it should be used extensively. A developer should verify that the agent parses headlines correctly, that dollar sizing maps to expected position values, and that the kill switch triggers properly. Backtesting news-driven strategies is difficult because historical sentiment is hard to reconstruct, but forward testing in paper mode over several days can reveal latency issues or logic errors. Before live trading, the owner must explicitly authorize the key. This authorization step is deliberate, not automatic, so that no one accidentally deploys an agent with real money during a routine code change. Start with a small budget, observe the agent through a full news cycle, and only then consider increasing limits. Check that the ingestion layer handles edge cases, such as duplicate headlines, empty feeds, or malformed timestamps. A robust agent degrades gracefully when the news feed is slow, rather than repeating its last signal indefinitely. Developers should also test the agent's behavior when a headline contradicts an existing position. A well-designed agent will have an exit plan that triggers before the new signal is evaluated, preventing the accumulation of conflicting trades. Testing this interaction in paper mode is essential, because the cost of a logical error in live trading is real money, and trading can lose everything allocated to the strategy.