A human genuinely approves the $20 refund.
The click or approval-role decision is real. It is not forged or skipped.
AI AGENT SECURITY
Loopjacking
You approve a $20 refund. The system later treats that approval as permission to release a $20,000 transfer. Your approval was real. It was attached to the wrong action.
YOU APPROVED$20
→
Refund to the customer
THE PRODUCT RELEASED$20,000
Transfer to the attacker
Illustrative payment scenario. These amounts are not a claim of actual losses.
The attacker cannot authorize the transfer. The product lets it inherit your approval.
01 Meet A, approval, and B
Name the four moving parts.
Keep the $20 refund in mind. The technical model is just a precise way to describe that story.
Athe $20 refund the human sees and approves+
A is the complete approved operation: refund $20, to the intended customer, for the intended order.
DAthe human's recorded “yes” to that refund+
The product may store this decision as a token, state change, signature, or approval-role action. Its authority should belong to A only.
Bthe $20,000 transfer that inherits the approval+
B changes something authorization-relevant: the amount, action, recipient, resource, or scope. A cosmetic difference is not enough.
bindingthe link between approval and the action it authorizes+
A safe product checks that the complete action it releases matches what the human reviewed and approved. A material mismatch breaks that link, whether hidden before approval or introduced afterward.
02 Where trust breaks
The human checks one thing. The product uses another.
The approval screen answers “May we refund $20?” The execution path later acts as if the human answered “May we transfer $20,000?”
THE STORY
You click Approve $20 refund.
The product records a real approval. Before that approval is consumed, the operative request either already hides or later becomes Transfer $20,000 to an attacker-controlled account. If the product reuses the old “yes,” the approval has been loopjacked.
ONE ROUTE: THE REQUEST CHANGES AFTER APPROVAL
CHECKhuman reviews $20 refundapproval DA ✓
HIJACKrequest means $20,000 transferthe old “yes” remains
USEproduct releases the transferno exact re-check ✕
The approval button is only the check. Security depends on whether the product proves, at the moment of use, that the action is still the one the human approved.
03 Two ways in
The request can lie before or change after approval.
Both routes end at the same failure: the human's decision for the $20 refund authorizes the $20,000 transfer.
COMPLETE REQUEST
→
approval describesrefund $20
execution performstransfer $20,000
APPROVAL VIEW$20
→
Refund to customer
APPROVEDEXECUTION USES$20K
Transfer to attacker
REPRESENTATION-BASED
The dangerous action is already there.
The complete request encodes the $20,000 transfer before approval, but the product shows the human only the $20 refund. Execution later consumes the parts the approval view left out.
REVIEWED STATE$20
→
Refund to customer
APPROVED
ATTACKER-REACHABLE UPDATE
→
same workflowdecision DA remains
amount$20 → $20,000
recipientcustomer → attacker
EXECUTION USES$20K
Transfer to attacker
POST-APPROVAL STATE SUBSTITUTION
The safe action changes after the click.
The human approves the exact $20 refund. Before that decision is consumed, attacker-reachable workflow state changes the amount, recipient, or operation. Product logic releases the $20,000 transfer under the approval for the refund.
04 When it counts
Six facts turn a bad workflow into Loopjacking.
A confusing screen or mutable task is not enough. You need the complete path from the human's real approval to the attacker's different effect.
The released action is materially different.
Changing $20 into $20,000, the recipient, or the operation itself changes what was authorized.
An attacker can reach the mismatch.
The hidden field, update, replay, or scope drift must be reachable through a real product path.
The product consumes the wrong approval.
Product-owned logic treats the human's “yes” to A as authority for B.
B reaches a consequential effect.
The $20,000 action reaches execution. A harmless test may record it instead of sending money.
The attacker could not simply do B.
The stolen approval crosses an authority boundary the attacker could not cross directly.
Together, these six facts establish an approval-hijacking path.
05 Run the attack
Watch a $20 approval become $20,000.
Follow a post-approval substitution. The attacker can change a pending request but cannot approve or directly execute the larger transfer.
STEP 00 / 04
Ready.
Follow the approval from a small refund to a different payment. Nothing here sends money or contacts a product.
HUMAN APPROVED NOT YET
- Action
- —
- Amount
- —
- Recipient
- —
CURRENT REQUEST NOT YET
- Action
- —
- Amount
- —
- Recipient
- —
RECORDED DECISIONNo approval yet.
No action is authorized yet.
Would an exact check stop it?
Keep the same approval. Change one condition and compare the outcome.
This comparison assumes the approval view described the complete action. A misleading view must be fixed too.
One approval, two different actions.
- The requester is the attacker in this fictional example. They can propose and update a payment, but cannot approve or directly execute it. They propose a $20 refund to a customer.
- A human reviews that exact refund and approves it.
- The attacker changes the pending request to a $20,000 transfer to their own account. The original approval remains.
- The product checks only that an approval exists and lets the different transfer proceed.
The defense: compare the complete current action with the approved action at use time. Reject the changed transfer or seek a new approval. The unchanged $20 refund can still proceed with a matching, still-valid approval.
The amounts are fictional. The demo assumes a still-valid, unused approval in the correct workflow. The research uses safe, harmless sinks.
06 What does not count
Not every bad approval flow is Loopjacking.
The defining question is simple: did a genuine approval for the $20 refund authorize the different $20,000 action?
Prompt injection by itself
The agent behaves badly, but no human approval for one action authorizes another.
A skipped or fake approval
The product executes without a genuine human “yes” to the $20 refund.
A task that merely changes
Mutable state matters only when the old approval crosses into the changed effect.
The human knowingly approves $20,000
A bad decision is not Loopjacking when the person clearly sees and approves B.
A2A is a possible carrier, not the definition. Its continuation mechanics do not establish an authorization vulnerability on their own.
07 Grounded in evidence
The simple story maps to tested product behavior.
The amounts are illustrative. The mechanism is not. The research follows released product paths, records what the human approval covered, and checks what the product finally released.
Post-approval substitution
Released products reproduced the same shape: exact A was approved, then attacker-reachable state supplied B.
Representation mismatch
A released product showed the approver A while its complete pre-existing request produced B.
Action-bound continuation
A comparison system kept approval bound to A and rejected changed B after the workflow resumed. Continuation alone was not enough.
Safe paths
Exact comparison or denying attacker-reachable mutation blocked B while still allowing unchanged A. These controls include a released fix, a supported safe configuration, and a researcher-added check—not released fixes for every case.
Loopjacking: Hijacking Human-in-the-Loop ApprovalAdithyan Arun Kumar · · arXiv:2609.21081
READ THE FULL PAPER08 What remains unknown
The attack class is real. These broader claims are not established.
Ecosystem prevalence
The study does not measure how common Loopjacking is across agent products.
One shared framework defect
Different cases have different mechanisms, boundaries, and fixes.
A universal affected range
Product findings apply only to the tested versions and configurations.
A universal severity score
Impact and exploitability are product-specific.
09 Stop the attack
A “yes” is not enough. Ask what it was a yes to.
Record the complete $20 refund the human approved. When the decision is used, rebuild the current action and compare every authorization-relevant field.
✕ BROKEN BINDING
- Show “Refund $20” but omit important fields.
- Store only a broad
approved = true. - Read the current action later.
- Let the old approval release $20,000.
✓ EXACT BINDING
- Show the complete, canonical $20 refund.
- Bind the decision to action, amount, recipient, resource, principal, scope, freshness, and consumption.
- Rebuild the action at use time.
- Release A only with a matching, still-valid approval. Reject or re-authorize B.
THE PORTABLE RULE
The complete action shown to the human, approved, and released must agree.
10 Check your mental model
Can you spot the stolen authority?
To recognize Loopjacking, identify what the human approved, what the product released, and how an attacker made that approval authorize the different action.
If there was no genuine human approval, or the person knowingly approved the released action, this is a different failure. A changing task alone is not enough.