O
OffSec
Guest
Imagine an AI agent asks you to approve a small payment to a familiar vendor. You check the amount, verify the recipient, and approve it.
The workflow continues. A much larger payment goes to a different destination.
You return to the approval record. It still contains the original request.
This scenario illustrates Loopjacking: a failure in which software uses a human’s approval for one operation to authorize or release something materially different. The experiments discussed here used harmless mock transfers and local recording tools; no money moved.
The uncomfortable part is that the human can make the correct decision. The software fails to preserve what that decision authorized.
Researcher Adithyan Arun Kumar examines this gap in Loopjacking: Hijacking Human-in-the-Loop Approval. The study distinguishes two ways it can happen: an operation changes after approval, or the approval view leaves out consequential details that were present all along. Both break the same expectation: what you approve should be what executes.
When someone approves a payment, they approve an amount and a recipient. For a file upload, the destination and files matter. For a command, its arguments and execution context can change its consequences.
An agent workflow has to carry that meaning through several components. One proposes an action. Another prepares the approval view. The workflow may pause, save its state, and resume later. Eventually, a tool performs the operation.
The security requirement extends across that entire path. A record saying “this task was approved” cannot establish that every later action within the task was approved. Even the same tool-call identifier can refer to changed arguments if the implementation permits replacement.
For an attacker, that distinction can create an opportunity: influence the operation while retaining someone else’s authorization.
A qualifying Loopjacking case therefore requires a genuine approval, a materially different effect outside its scope, and a reachable way for an attacker to make the product consume that approval. The attacker must also lack an equivalent direct route to the effect.
State substitution starts with an accurate request. The reviewer sees operation A and approves it. Before execution, attacker-influenced workflow state substitutes operation B, and the system continues using the earlier decision.
The study’s Agno AgentOS experiment makes this concrete. Its tested regular-Agent configuration separated two roles: a lower-privileged user could initiate and continue a run, while a distinct administrator could approve the proposed operation.
The approved operation was a mock transfer of 20 units to an approved vendor. The operation ultimately dispatched was a mock transfer of 2,000 units to a different destination.
The lower-privileged user could neither approve the request nor directly execute the substituted operation. Yet after the administrator approved the original request, the product accepted changed continuation data and dispatched the different transfer. The approval record still described the original operation.
In the recorded Agno 3.0.9 bundle, this mismatch occurred in five of five trials. Unchanged approved operations executed in five of five controls, while all three direct attempts at the substituted operation were denied. These results apply to the exact tested configuration; they do not measure how frequently deployed systems are affected. The public evidence index documents the boundaries and controls.
An additional researcher-built control compared the approved operation with the operation about to execute. It rejected the substitution while allowing the original transfer. That demonstrates a working defense for the tested path, rather than a released Agno fix.
Representation mismatch starts with an incomplete view. No change after approval is necessary. The consequential behavior is already encoded in the request, but the approval view does not faithfully represent it.
A previously disclosed OpenClaw issue demonstrates this distinction. In the affected command-execution path, approval text could represent only part of a shell command’s execution context. Additional arguments consumed at runtime were absent from that representation.
The vendor’s security advisory, which credits the original reporter, describes the mismatch and identifies 2026.2.24 as the patched release.
Kumar’s study reproduced the mismatch on 2026.2.23 using a harmless temporary marker. The same mismatch was rejected on 2026.2.24, while unchanged approved commands continued to work. The approval role was scripted after recording and checking the exact product event: the experiment measured system behavior, not whether people would be deceived by a particular interface. The OpenClaw evidence record preserves that distinction.
This explains why freezing a request after approval is an incomplete defense. An immutable request can still be inadequately represented to its reviewer.
The study also included an implementation that preserved the approval boundary. In OpenAI Agents SDK 0.22.0 and 0.22.2, ordinary per-call approval remained bound to the invocation across saving and restoring workflow state. Unchanged approved operations executed; changed invocation arguments retaining the call identifier were rejected.
For each release, all three unchanged-operation controls passed, and all three mutation trials were rejected without a recorded effect. The negative-control evidence applies to the tested ordinary per-call approval path, not every approval mode or application built around the SDK.
That result matters because agent workflows need to pause and resume. Persistence and continuation can coexist with meaningful approval. The implementation has to preserve the operation-specific authorization through those transitions.
Prompt injection can influence what an agent proposes or place attacker-controlled content into a workflow. Loopjacking concerns the subsequent authorization failure: an implementation consumes a human decision for an operation outside its scope. The two can occur together, but Loopjacking does not require prompt injection.
The underlying principles have established precedents. OWASP’s transaction-authorization guidance calls for users to verify significant transaction details and for authorization to be checked at execution. Its Lies-in-the-Loop description addresses manipulation of approval dialogs.
Loopjacking groups concrete approval-to-effect failures in agent workflows and distinguishes how they arise. It does not imply that approval integrity is a newly discovered security principle, or that all agent frameworks share one vulnerability.
For developers, the practical requirement is to make the approval interface and execution system agree on the operation being authorized. Four design choices help make that agreement enforceable:
A cryptographic digest can help bind these records, but only if it covers the relevant operation and is protected from tampering. Hashing an incomplete description preserves the same omission.
For teams evaluating their own workflows, a useful acceptance test is whether unchanged approved operations succeed while materially different operations require a new decision. The evidence should include the actual effect at the tool boundary; a successful response or an approval entry alone cannot establish that the correct action executed.
The study used isolated environments, synthetic identities, and harmless recording tools, with an evidence cutoff of September 10, 2026. It establishes specific implementation failures and working controls. It does not establish ecosystem prevalence, and independent reproduction is not claimed.
For a person reviewing an action, approval carries a concrete meaning. The software’s job is to preserve it through execution. An audit trail should show who authorized which operation, and that the operation released stayed within that authorization.
The workflow continues. A much larger payment goes to a different destination.
You return to the approval record. It still contains the original request.
This scenario illustrates Loopjacking: a failure in which software uses a human’s approval for one operation to authorize or release something materially different. The experiments discussed here used harmless mock transfers and local recording tools; no money moved.
The uncomfortable part is that the human can make the correct decision. The software fails to preserve what that decision authorized.
Researcher Adithyan Arun Kumar examines this gap in Loopjacking: Hijacking Human-in-the-Loop Approval. The study distinguishes two ways it can happen: an operation changes after approval, or the approval view leaves out consequential details that were present all along. Both break the same expectation: what you approve should be what executes.
What a click on “Approve” actually authorizes
When someone approves a payment, they approve an amount and a recipient. For a file upload, the destination and files matter. For a command, its arguments and execution context can change its consequences.
An agent workflow has to carry that meaning through several components. One proposes an action. Another prepares the approval view. The workflow may pause, save its state, and resume later. Eventually, a tool performs the operation.
The security requirement extends across that entire path. A record saying “this task was approved” cannot establish that every later action within the task was approved. Even the same tool-call identifier can refer to changed arguments if the implementation permits replacement.
For an attacker, that distinction can create an opportunity: influence the operation while retaining someone else’s authorization.
A qualifying Loopjacking case therefore requires a genuine approval, a materially different effect outside its scope, and a reachable way for an attacker to make the product consume that approval. The attacker must also lack an equivalent direct route to the effect.
When the action changes after approval
State substitution starts with an accurate request. The reviewer sees operation A and approves it. Before execution, attacker-influenced workflow state substitutes operation B, and the system continues using the earlier decision.
The study’s Agno AgentOS experiment makes this concrete. Its tested regular-Agent configuration separated two roles: a lower-privileged user could initiate and continue a run, while a distinct administrator could approve the proposed operation.
The approved operation was a mock transfer of 20 units to an approved vendor. The operation ultimately dispatched was a mock transfer of 2,000 units to a different destination.
The lower-privileged user could neither approve the request nor directly execute the substituted operation. Yet after the administrator approved the original request, the product accepted changed continuation data and dispatched the different transfer. The approval record still described the original operation.
In the recorded Agno 3.0.9 bundle, this mismatch occurred in five of five trials. Unchanged approved operations executed in five of five controls, while all three direct attempts at the substituted operation were denied. These results apply to the exact tested configuration; they do not measure how frequently deployed systems are affected. The public evidence index documents the boundaries and controls.
An additional researcher-built control compared the approved operation with the operation about to execute. It rejected the substitution while allowing the original transfer. That demonstrates a working defense for the tested path, rather than a released Agno fix.
When the approval view leaves something out
Representation mismatch starts with an incomplete view. No change after approval is necessary. The consequential behavior is already encoded in the request, but the approval view does not faithfully represent it.
A previously disclosed OpenClaw issue demonstrates this distinction. In the affected command-execution path, approval text could represent only part of a shell command’s execution context. Additional arguments consumed at runtime were absent from that representation.
The vendor’s security advisory, which credits the original reporter, describes the mismatch and identifies 2026.2.24 as the patched release.
Kumar’s study reproduced the mismatch on 2026.2.23 using a harmless temporary marker. The same mismatch was rejected on 2026.2.24, while unchanged approved commands continued to work. The approval role was scripted after recording and checking the exact product event: the experiment measured system behavior, not whether people would be deceived by a particular interface. The OpenClaw evidence record preserves that distinction.
This explains why freezing a request after approval is an incomplete defense. An immutable request can still be inadequately represented to its reviewer.
A control that kept approval intact
The study also included an implementation that preserved the approval boundary. In OpenAI Agents SDK 0.22.0 and 0.22.2, ordinary per-call approval remained bound to the invocation across saving and restoring workflow state. Unchanged approved operations executed; changed invocation arguments retaining the call identifier were rejected.
For each release, all three unchanged-operation controls passed, and all three mutation trials were rejected without a recorded effect. The negative-control evidence applies to the tested ordinary per-call approval path, not every approval mode or application built around the SDK.
That result matters because agent workflows need to pause and resume. Persistence and continuation can coexist with meaningful approval. The implementation has to preserve the operation-specific authorization through those transitions.
Where prompt injection fits
Prompt injection can influence what an agent proposes or place attacker-controlled content into a workflow. Loopjacking concerns the subsequent authorization failure: an implementation consumes a human decision for an operation outside its scope. The two can occur together, but Loopjacking does not require prompt injection.
The underlying principles have established precedents. OWASP’s transaction-authorization guidance calls for users to verify significant transaction details and for authorization to be checked at execution. Its Lies-in-the-Loop description addresses manipulation of approval dialogs.
Loopjacking groups concrete approval-to-effect failures in agent workflows and distinguishes how they arise. It does not imply that approval integrity is a newly discovered security principle, or that all agent frameworks share one vulnerability.
What developers should preserve through execution
For developers, the practical requirement is to make the approval interface and execution system agree on the operation being authorized. Four design choices help make that agreement enforceable:
- Build the approval view from the operation that will execute. Include the arguments, destination, resources, and context that materially affect the outcome. A readable summary can help, but it cannot replace consequential details.
- Bind the decision to a protected operation record. Preserve what was approved, who approved it, and the scope and validity of that decision. A task identifier or an “approved” flag is insufficient when the operation underneath it can change.
- Compare again immediately before execution. Resolve the current operation and check it against the approved record. A material change should stop execution or require fresh approval. Protect the checked operation against further substitution before dispatch.
- Make approval consumption and audit records precise. Enforce expiry and reuse limits, and record both the approved operation and the operation actually released. Retries should not silently expand what a one-time decision permits.
A cryptographic digest can help bind these records, but only if it covers the relevant operation and is protected from tampering. Hashing an incomplete description preserves the same omission.
For teams evaluating their own workflows, a useful acceptance test is whether unchanged approved operations succeed while materially different operations require a new decision. The evidence should include the actual effect at the tool boundary; a successful response or an approval entry alone cannot establish that the correct action executed.
The study used isolated environments, synthetic identities, and harmless recording tools, with an evidence cutoff of September 10, 2026. It establishes specific implementation failures and working controls. It does not establish ecosystem prevalence, and independent reproduction is not claimed.
For a person reviewing an action, approval carries a concrete meaning. The software’s job is to preserve it through execution. An audit trail should show who authorized which operation, and that the operation released stayed within that authorization.