What changes after approval? The beneficiary-swap problem in AI agents

Human approval is the most common safeguard placed in front of an AI agent's riskier actions. The agent proposes, a person approves, the agent proceeds. It feels safe because a human looked at it.

But what exactly did the human look at? And is that what actually ran? This article walks through one failure that sits in the gap between those two questions, the beneficiary swap, and what it takes to close it.

The familiar version, without agents

Payment redirection is not new. The FBI's Internet Crime Complaint Center describes business email compromise as compromising legitimate email accounts "to conduct unauthorized transfers of funds" (FBI IC3 public service announcement, September 2024). A common pattern is a convincing message asking for a supplier's bank details to be updated, so that the next real invoice is paid to someone else.

Finance teams defend against this with process: call-backs to known numbers, two people for bank detail changes, and approval of the specific account rather than "the supplier update".

When an agent takes over part of that workflow, the process has to survive the handover. That is where the beneficiary swap appears.

The swap

Consider an agent that prepares supplier payments and bank-detail updates. A sequence like this is easy to build by accident:

1. The agent proposes a change: update supplier 482's account to one ending ····4821.
2. A person reviews it and approves. The approval is recorded against the request.
3. Before execution, something changes the parameters. A follow-up email arrives, the agent re-reads its context, or an attacker who can influence the agent's input supplies a new account ending ····9930.
4. The agent executes with the new account. The approval is still on record, so the system treats the action as approved.

Nobody approved ····9930. Yet the logs show an approval, a valid identity, a valid token and a successful call. Every individual control did its job, and the organisation still paid the wrong party.

The root cause is simple to state. The approval was bound to a request, not to the exact action. Between the moment of approval and the moment of execution, the action changed and the approval did not.

Why agents make this more likely

Three properties of agents widen the window.

First, agents are iterative. They re-plan, re-read context and retry. A parameter that was fixed when the approval was requested may be recomputed before execution.

Second, agents act on text they did not write. Emails, tickets and documents are inputs, and some of those inputs can be crafted. An instruction to "use the updated account" can arrive after approval.

Third, approval interfaces tend to summarise. An approver shown Update supplier bank details: Example Supplies Ltd, without the account number, cannot notice a swap.

Closing the gap: bind, then recheck

Two mechanisms close the gap together. Either one alone leaves it open.

Bind the approval to the exact action. Before anyone approves, the request is normalised into one action envelope and fingerprinted into a deterministic action digest. The approval is recorded against that digest and the requested snapshot of the fields, not against the request type. Change any material field, such as the beneficiary account, and the digest changes, so the earlier approval no longer applies.

Recheck immediately before execution. Binding is not enough if nothing checks it at the last moment. Just before execution, authority is resolved again and the approved snapshot is compared, field by field, with the snapshot about to run. If a material field moved, the recheck fails and no execution authority is issued.

In Delegrity this recheck sits in the Grant stage. In the swap above:

• Bind fixes the action with account ····4821.
• Decide checks the mandate, consults policy and records the approval against that digest.
• Grant compares the approved snapshot with the execution snapshot, sees ····4821 → ····9930, and issues nothing. The decision is BLOCKED and the target system is not reached.
• Prove has no execution receipt to issue, because nothing ran. Had the recheck passed, the receipt would name the agent, the principal it acted for and the mandate, over a SHA-256 hash-chained evidence record with an Ed25519 signature.

When the recheck passes, the execution authority it issues is deliberately narrow: single use, carrying a nonce, bound to the approved digest, the audience and the presenting sender, and short-lived, with a configurable lifetime of at most 300 seconds. A grant cannot be replayed for a second payment or carried over to a different action.

What "approved" should mean

It helps to separate three statements that systems often collapse into one:

• Approved means a person agreed to a specific set of fields.
• Authorised means that, at execution time, the mandate is still current, policy still allows it, and the action still matches what was approved.
• Executed means the target system received the call. It does not yet mean the intended outcome happened; that has to be reconciled with the target's own result.

An agent pipeline that treats "approved" as "authorised" is exposed to the swap. One that treats "dispatched" as "done" cannot tell you what actually happened when something goes wrong.

Questions to ask of your own approvals

If you already have human approval in front of agent actions, these questions will tell you whether it would catch a beneficiary swap:

• Does the approver see every material field, including the account number?
• Is the approval stored against those exact fields, or against the request?
• Is anything checked between approval and execution, and how long can that window be?
• Can an approval or an execution grant be used twice?
• Afterwards, can you show which exact fields were approved and which ran?

If any answer is unclear, the safest assumption is that the approval and the action can drift apart.

Delegrity is at design-partner stage. It has no production customer evidence and no independent certification yet.