Risk controls for trading agents: enforce authority outside the model

The reader question is which controls should remain outside an agent's judgement. Our proposed answer is to put account permissions, enforceable limits, submission policy and emergency intervention in components that can refuse an action regardless of the model's explanation. Let the agent contribute analysis; require a separately inspectable decision at the execution boundary.

This is an engineering framework for evaluation, not a certification of VC Trader AI or a legal applicability assessment. The FCA's August 2025 review examined principal trading firms' algorithmic controls under existing RTS 6 requirements. It offers relevant operational evidence, but its reviewed population and obligations should not be assumed to describe every software provider or retail user. [1]

The Financial Stability Board's final report of 15 October 2026 similarly encourages financial institutions to consider organisation-wide governance and lifecycle risk management, including clear accountability and data fit for the use case. It is current guidance at our cutoff, not a finding that any individual platform complies. [2]

Authority is more informative than an “autonomous” label. Reading positions, proposing a transaction, submitting it and changing a deployed strategy are different permissions with different consequences.

VC Trader AI's current public scope distinguishes individual confirmation for agent-proposed orders from automatic execution by customer-approved deployed strategies. Approving a strategy is a continuing delegation within its configured operation; confirming one proposal is a bounded decision. The interface and audit trail should preserve that distinction. [3]

For any product, map each actor to the accounts, instruments, tools and actions it can reach. Include maintenance tools: permission to change strategy code or disable a risk gate can confer more authority than permission to submit one order. A read-only research agent should not acquire trading credentials merely because another specialist needs them.

An operator should be able to identify the active delegation without reading a conversation history. Record its owner, version, start time, expiry or review condition and intervention route. These are proposed acceptance criteria; describing them does not establish that a particular platform implements every item.

The FCA found adequate pre-trade controls across the firms it reviewed, while identifying weaknesses in control ownership and documentation. It also described internal-server gateways that prevented breached orders leaving the firm. This supports examining both the control's location and its operational ownership, rather than accepting a checkbox list. [1]

Our proposed gateway checks account identity, instrument permission, quote age, request units, order size, aggregate exposure and configured loss or activity limits. Define how pending orders and concurrent strategies consume headroom. A check against a stale balance can pass while the actual book has already changed.

Avoid separating “check” and “reserve” so widely that two requests both consume the same remaining allowance. The exact concurrency design depends on the broker and architecture. The testable requirement is that simultaneous actions cannot bypass the configured aggregate boundary. A model's claim that it has checked exposure is not that evidence.

A useful confirmation includes the account, instrument, side, quantity, price assumptions, stop interpretation, estimated exposure and conditions that invalidate the proposal. The human needs to know which of those values are fixed and which may change before submission.

If the quote, exposure or strategy version changes materially after review, ask whether the original permission remains valid. Revalidate at submission and define when renewed confirmation is required. A timestamped approval attached to a materially different order is weak oversight.

MetaQuotes explicitly separates preliminary request checking from successful execution. Its trade-server codes also distinguish placed orders, completed requests, partial completion and several rejection conditions. A user confirmation does not erase those distinctions. [4] [5]

Suppose an illustrative agent submits an authorised instruction and the connection drops before the application receives the result. The application's local state is uncertain. Immediately repeating the economic action can create unintended exposure if the first submission was already processed.

The proposed response is to stop new conflicting actions, recover current orders, deals and positions, match them to retained intentions and resolve the uncertainty. Persist the exact request, response when available and reconciliation evidence. Neither a network exception nor a fluent model explanation proves what the broker did.

The MT5 deployment guide develops this lifecycle in more detail. The risk implication is broader: define the safe response to unknown state in advance. A process may need to refuse further activity even when the strategy still wants to trade.

An agent may consume market news, documents, tool results and retrieved research. Those inputs should inform analysis without acquiring permission to change its operating policy. Anthropic's containment account distinguishes model, environment and external-content defences and states that model-layer protection cannot stand alone. This is a provider's architectural account, not an independent estimate of trading-agent security. [7]

NIST's voluntary generative-AI risk profile also treats risks such as confabulation within a wider lifecycle-management framework. It is useful guidance, not a trading licence or a guarantee of reliability. [6]

For evaluation, place a harmless adversarial instruction in a controlled test document and verify that it cannot raise limits, switch accounts or invoke an unauthorised tool. Keep credentials and policy changes outside retrieved text. Passing a few examples does not establish immunity; retain the threat model, tested versions and observed failures.

A kill switch can mean several operations: stop new submissions, pause strategy workers, cancel pending orders or close positions. These operations have different market consequences and failure modes. State which action each control performs and which process acknowledges it.

Cancelling orders does not close existing positions. Closing positions creates new execution requests and may fail or incur substantial costs. A stop control should therefore report the residual state and unresolved actions, not merely change its colour. Restoration also needs an explicit decision; a recovered worker should not silently resume authority that an operator intentionally suspended.

Monitoring needs a path independent enough to reveal a stalled decision process. Define stale-state alarms, missing-heartbeat handling, alert delivery and escalation ownership. An alert nobody receives is a recorded event, not an effective intervention.

This ledger is a proposed test plan, not completed test evidence. Run controlled simulation and demo-account checks before considering broader authority. Passing them still cannot prove profitability, reproduce all live conditions or eliminate model and infrastructure risk.

The most useful acceptance question is concrete: can an operator reconstruct what authority existed, what the system observed, why the boundary allowed or refused the action, and what exposure remained afterwards? If those answers depend on trusting the model's retrospective story, the control evidence is incomplete.