Why Research and Execution Authority Should Be Separate for AI Trading Agents
Explaining the safety, accountability, and risk‑management reasons for keeping AI research and execution permissions distinct in automated trading.
Produced with automation, then checked by deterministic quality rules and an independent source-grounded review before publication.
- 01The same key that can read market data should not be able to place trades.
- 02Granular owner‑signed limits protect against runaway orders even if research logic misbehaves.
- 03Read‑only research environments prevent accidental state changes during backtesting.
- 04Emergency stops can revoke execution rights without affecting existing positions.
- 05Clear separation simplifies reconciliation and error handling when timeouts occur.
Research and execution authority should be separate for AI agents because the tasks have fundamentally different risk profiles. A research key only reads data and runs simulations, while an execution key can move funds and create market exposure. Keeping them distinct limits the chance that a bug or mis‑configuration in research code results in an unintended trade.
What Risks Arise When Authority Is Combined?
When a single key can both query data and submit orders, a coding error, a malformed query, or a stale data feed can directly translate into a live transaction. The system may not have a chance to intervene before capital is at risk. Moreover, combined authority makes it harder to audit who initiated a trade versus who performed the analysis, reducing transparency for owners and regulators.
How Does Separate Authority Improve Safety?
By issuing a read‑only research key, the platform guarantees that backtests and data exploration cannot alter balances or sign transactions. Execution keys are granted only after the research phase has produced a vetted strategy, and they operate under owner‑signed limits such as maximum order size, daily notional, and loss caps. This layered approach creates a safety net: even if the research model suggests an extreme position, the execution key will be blocked by the predefined limits.
What Controls Can Owners Apply to Execution Keys?
- Order‑size caps that prevent any single order from exceeding a set amount.
- Daily notional limits that bound the total exposure over a 24‑hour period.
- Daily loss thresholds that automatically halt further execution if losses exceed a defined level.
- Expiry timestamps that invalidate the key after a certain date or after a specific number of uses.
- Policy fields that can be updated via signed owner transactions to adapt to changing market conditions.
How Do Emergency Stops Work With Separate Authority?
An emergency stop can revoke the execution key without touching the research key. This means the agent can still run analyses, generate signals, and log data, but it cannot place new orders until the owner reviews and re‑authorizes execution. Existing positions remain open; they must be closed manually or through a separate owner‑signed withdrawal intent.
What Are Common Pitfalls When Designing the Separation?
- 01The system may treat a timeout as a failed order, but the order could still be pending. Robust reconciliation is required to verify actual fill status.
- 02Missing market data timestamps can lead the research engine to base decisions on stale information, which the execution layer might still act upon if not checked.
- 03Overly restrictive limits can cause legitimate strategies to be throttled, reducing performance while still protecting capital.
- 04Insufficient logging of key revocation events makes post‑mortem analysis difficult.
Separating research and execution authority is a core design principle for any trustworthy AI trading system.
By keeping research and execution authority separate, owners gain clearer accountability, enforceable risk limits, and a more reliable path to audit and recover from errors. This architectural choice does not eliminate market risk, but it adds a critical layer of protection against software‑induced loss.
Frequently asked questions
A single key removes the barrier that prevents accidental state changes; a bug in research code could directly place a trade, bypassing any risk limits.
Limits are enforced at the execution layer, so even if the AI suggests a larger order, the transaction will be rejected unless it complies with the signed policy.
Treat a timeout as an indeterminate state. Use reconciliation processes to check fills and positions before assuming the order failed. See [How an AI Agent Should Respond When an Order Request Times Out](/blog/ai-agent-response-order-timeout) for guidance.
The blog posts on risk limits, emergency stops, and authority separation provide practical examples. Useful reads include [Owner Authority vs Agent Authority: Understanding the Core Differences](/blog/owner-authority-agent-authority-differences) and [Essential Risk Limits Every AI Trading Agent Should Enforce](/blog/essential-risk-limits-ai-trading-agent).
Sources and verification
Product claims in this article were checked against these first-party references. Runtime status remains authoritative for current availability.
- Felix documentationfirst party
- Felix machine referencefirst party
Build with Felix now.
Felix infrastructure is live through MCP and the API. The full trading app launches September 17.
An AI trading agent must keep its view of orders, fills, and positions aligned with reality. This article explains why reconciliation matters, how to design robust checks, and what controls can reduce risk.
When an order request times out, the outcome is uncertain. This article outlines a disciplined response process for AI agents, covering status checks, data validation, error handling, and safe recovery.