Human approval for agent trading actions

Key takeaways

• Default posture for agent trading: every state-changing action stops, is approved, is bound to the exact order, is logged, then executes.
• Gate before the side effect - before the broker or trading MCP call, not after the model has decided.
• Bind the approval to a hash of the exact order; an approval is permission for that order, not a licence to trade the symbol.
• Only machine-observed facts (order, buying power, exposure) drive routing; the agent's thesis is display-only.
• Trading needs reconstructable, long-retention audit evidence - a short-lived app log is not enough.

What this pattern is for

Agentic trading lets an AI agent research, build a portfolio view, and place orders. Some platforms let an agent act without confirming every action. That is exactly why, for enterprise desks or any high-risk account, the connector default should be approval-required: the user remains responsible for the trades, so a state-changing action should stop for a human before it executes.

This page describes the pattern, not any specific broker. It makes no claim about any trading platform's API. Treat every state-changing trade action as something that pauses, is approved, is bound, is logged, and only then runs.

When to use it

Use this pattern whenever the agent can change a position or a risk boundary.

• Opening a position or increasing an existing one.
• Selling, fully or partially.
• Cancelling or replacing an open order.
• Changing risk settings or trading session.
• Trading a security, option, or asset outside an allowlist.

The seven integration steps

• Wrap the trade action where the real side effect happens - right before the broker API or trading MCP call, not after the model output. This mirrors LangGraph's interrupt and the OpenAI Agents SDK needs_approval pattern.
• Build a factual decision payload: symbol, side, quantity, limit or stop parameters, account, buying power, exposure after the trade, the policy that triggered the stop, and a stable hash of the order parameters.
• Create a Contro1 request with external_request_id, correlation_id, trace_id, tool_calls, and retrieved_context.
• Route by role and risk: dashboard, Teams, Slack, or operator workflow. For high notional, a quota breach, or a new symbol, require a quorum of two approvers.
• Verify the signed callback before continuing. A reject or expiry returns a deterministic denial to the agent; an approval proceeds only if the order still matches exactly.
• Execute the order exactly once. Idempotency on external_request_id or client_order_id is mandatory, not optional.
• Write an audit record after execution or denial, linked to the request by in_reply_to and correlation_id, and pull a signed evidence packet when compliance or a post-incident review needs it.

The reviewer sees the order, not the pitch

The approval card should show machine-observed facts the reviewer can trust: the account, symbol, side, quantity, limit price, notional estimate, position after the trade, and the policy that triggered the stop. The agent's thesis can appear as context, but it never sets the risk level or the routing.

{
  "title": "Approve trade: BUY 25 NVDA",
  "risk_level": "high",
  "decision_owner": "trading-supervisor",
  "machine_observed": {
    "account": "agentic-account-01",
    "symbol": "NVDA",
    "side": "BUY",
    "qty": "25",
    "limit_price": "138.50",
    "notional_estimate_usd": "3462.50",
    "position_after_trade_pct": "7.8",
    "market_session": "regular"
  },
  "policy_trigger": {
    "reason": "position_after_trade_pct > 5% OR symbol not on allowlist"
  },
  "buttons": ["Approve", "Reject", "Escalate"],
  "required_comment_on_reject": true
}

Bind the approval to the exact order

An approval is permission for one specific order, not a standing licence to trade the symbol. Hash the order parameters when you create the request, and before you execute, confirm the approved order still hashes to the same value. If the agent changed the quantity, the price, or the side after approval, refuse and re-request.

• Fail closed on an unsigned or expired callback, a mismatched order hash, or an unknown request id.
• Machine-observed facts drive routing; the model's free text does not.
• Hold broker credentials only on the bridge server, never in the agent.

Audit evidence for trading is not optional

Trading raises the audit bar because of compliance. An application log that rotates in a week does not meet reconstruction and retention duties. The connector should export to a dedicated records system or evidence archive.

Each record should carry the request id, agent id, order id, a hash of the order payload, the approver's decision, timestamps, and the execution outcome, so the original action can be reconstructed even if a downstream record is later changed.

{
  "action": "trade.order.executed",
  "summary": "Executed approved BUY 25 NVDA @ 138.50",
  "source": {
    "integration": "agent-trading-connector",
    "workflow_id": "broker-order-placement",
    "run_id": "run_9e6f"
  },
  "outcome": "success",
  "severity": "info",
  "correlation_id": "run_9e6f",
  "in_reply_to": { "type": "request", "id": "req_contro1_123" }
}

Decide these explicitly

A few things are deployment decisions, not defaults. Whether trade approvals also go to email. Whether mobile push is an approval surface. How long trading evidence is retained and where it is archived. Write these down in your own runbook rather than assuming them.

Frequently asked questions

Should every trade require approval?

For enterprise desks and high-risk accounts, make approval the default for every state-changing action, then relax it for narrow, allowlisted, low-notional cases you have deliberately reviewed. Reads and research never need approval.

Where does the approval gate go?

Immediately before the broker API or trading MCP call, after research and policy checks but before the side effect. Gating after the order has already been placed defeats the purpose.

What stops an approval being replayed onto a different order?

The approval is bound to a hash of the exact order parameters. Before executing, the connector re-checks that hash; any change to quantity, price, side, or symbol fails closed and re-requests.

Is this tied to a specific broker?

No. The pattern is broker-agnostic and makes no claim about any platform's API. Plug in whichever broker adapter or trading MCP you use behind the same fail-closed execution boundary.

Related resources