Agent approvals need independent policy checks

On June 26, 2026, Revolut connected Revolut X, its crypto exchange, to third-party AI assistants — four named ones (Claude, Gemini, OpenClaw, Cursor) plus a universal skill and an open-source CLI. Per the launch post, an assistant can backtest a BTC grid strategy over 30 days and prepare market or limit orders in chat. The user remains responsible for approving every order.

The terms are blunter than the marketing. Instructions submitted with your API credentials are treated as authorized, and Revolut's own documents warn about hallucinations, prompt misinterpretation, looping behaviour, and key security. The consensus read is that this is fine because a human approves each trade — human-in-the-loop, box ticked.

That read misses where the risk actually sits. By the time you see the confirmation, the same model has produced the market analysis, the strategy, the backtest interpretation, the order parameters, and the persuasive paragraph explaining why this order is a good idea. Your approval is downstream of the agent's framing of its own work. The failure mode is not a rogue agent bypassing the click — it is a human confidently confirming a coherent, well-narrated, wrong plan. The vulnerability is cognitive before it is technical.

Approval is not review

I have watched this happen outside finance. At work, we ran an agent pipeline for a client where the agent drafted operational changes and a human approved each one from the agent's own summary. Approval rates sat near 100% for weeks — which sounds like quality until we changed one thing: the confirmation screen stopped showing the agent's summary and instead rendered the raw parameters of the action next to the applicable policy limits. Rejections appeared almost immediately. The humans had not been reviewing actions; they had been reviewing the agent's prose about its actions. Same people, same actions, different framing — different decisions.

So here is my claim, stated plainly: an approval only counts as a control if the thing being approved was evaluated by something that did not produce it. For agent-prepared financial actions, that means a control plane that sits between proposal and confirmation and is deterministic where the agent is probabilistic — hard position and notional limits, an asset allowlist, per-day order-count caps to catch looping, anomaly checks against the account's own history, and a confirmation screen rendered from the raw order payload, never from the assistant's narrative. The agent proposes; a separate, boring, rule-based layer disposes; only then does the human click.

Two hedges, because the seed evidence deserves them. I have not independently tested Revolut's connectors, and its safety model is documented by Revolut itself — no external regulator or auditor has evaluated it publicly that I can find. It is possible some of these controls exist server-side. But the launch materials assign the review burden to the user, and the terms make user-credentialed instructions authorized by definition, which tells you where the accountability lands when the coherent-but-wrong plan clears.

Steal this if you expose any regulated or irreversible action through an agent — trading, payments, infrastructure, HR. Write the policy checks as code that runs on the proposed action's raw parameters, with no access to the agent's explanation. Render the confirmation from those raw parameters plus the policy verdict. Then run one adversarial test before Friday: have the agent produce a plausible-sounding proposal that violates a limit, and see whether your reviewer catches it from the narrative alone. If they approve it, your human-in-the-loop is a signature, not a safeguard — and you found that out in a test instead of an incident.

A confirmation click is not a control when the proposer also wrote the pitch — approve orders against independent policy checks, not against the agent's own story.