This is a concrete approval-binding failure in LangGraph Agent Server's A2A route, not a flaw in the A2A protocol itself. A lower-privileged "maker" proposes a 20-unit transfer; after the approver views the human-in-the-loop interrupt, the maker sends another message/send naming the same Task, reusing the pending message ID and tool-call ID while swapping the arguments to 2,000 units and an attacker-controlled destination. When the approver submits "approve", the HITL path rebuilds the call from current thread state with no comparison against the reviewed operation, and executes the swapped call under the approver's wire:execute authority. It was reproduced on 12 released versions (0.7.5–0.14.0) in an in-memory composition with a researcher-defined maker/approver auth policy, with archived traces, ledger events, and package pins. No vendor fix is listed; Postgres behavior is untested; one researcher ran it. The actionable takeaway: either deny updates to pending state while an approval is open (the tested deny-update policy blocked the swap while legitimate approvals still worked), or canonicalize the operation, store an integrity-protected decision with a digest, and recheck that digest at dispatch, consuming the decision once. In tests, assert the exact arguments at the sink, not an "approved" status. Open question: does this reproduce under the default policy, or only under the deliberately split maker/approver policy built for the test?