Skip to content
An approval checkmark connected to branching actions and a lock.
← All posts
AIAI AgentsSecurity

Loopjacking Tests When Agent Approval Releases the Wrong Action

Controlled software tests trace how approval for one action can release another. The results identify where approval must stay attached to execution and how to test that connection.

· ~5 min read

ShareXLinkedIn

An AI agent asks permission before carrying out an action. You inspect the request and approve it. What guarantees that the action eventually executed is the one you reviewed? This paper follows that question through actual software, showing several ways the connection can break and testing controls that preserve it. The author calls reuse of approval for a materially different action loopjacking. 1, Sections 1–2.

What changed

An AI agent is software that uses a model to help carry out tasks through tools. An approval step can interrupt a tool call until a person authorizes it. But the request may pass through a display, a saved record, a resumed workflow, and an execution service. Each stage needs to agree on what was authorized.

The paper distinguishes two failure mechanisms. In a representation mismatch, the complete action already contains consequential information that the approval screen leaves out. In state substitution, the screen shows the correct action, but the pending operation changes before execution. Both lead to the same outcome: a decision about one operation is used to authorize another. 1, Section 2.2.

The definition includes an important boundary: the attacker must lack an equivalent direct way to perform the substituted action. If they could already execute it without approval, the experiment would demonstrate a different permissions problem. Likewise, a person knowingly approving a clearly displayed action is outside the paper's definition. These distinctions give the study a specific failure to test. 1, Sections 2.3–2.4.

How the method works

The researcher selects software paths with different approval mechanisms, rather than taking a random sample of deployments. Released package versions run in isolated environments. Model responses are fixed, and external effects are replaced with harmless records or temporary files. This removes changing model behavior from the experiment, allowing the study to focus on the software that stores, resumes, and executes an approval. 1, Sections 3 and 4.1.

For each case, the evidence follows the operation from the original request to its final effect. The researcher records what the approval role saw, which decision it made, what state changed, and what arguments the execution tool actually received. A successful network response or a model saying “done” would not establish the result. The recorded action at the end is the decisive measurement.

Several controls make that measurement interpretable. An unchanged, approved action must still work. The attacker's direct request for the unauthorized action must fail. Relevant unauthorized actors must remain blocked. Finally, a fixed release or protective configuration must reject the mismatch while preserving legitimate execution. Together, these checks distinguish approval reuse from a broken test environment or a system that simply permits everything. 1, Section 4.1.

The study also includes a negative control: an implementation expected to preserve the connection between approval and action. Such a control tests the competing explanation that merely saving and resuming a workflow is inherently unsafe. If an implementation can resume correctly while rejecting substitutions, the failure depends on how approval is handled, rather than on resumability alone. 1, Section 4.2.

What the experiments show

The clearest paired release comparison concerns OpenClaw. In the tested command-approval path, version 2026.2.23 executed the mismatched action in three of three trials. Version 2026.2.24 rejected it in three of three, while still executing the unchanged approved action. The later release checked consistency across the complete command arguments. This localizes the failure to the incomplete representation and supplies evidence that the product's change blocks that specific route. 1, Table 2.

The state-substitution cases show a different route to the same failure. Selected Agno AgentOS releases accepted changed continuation arguments after approval. A researcher-added comparison against the approved action rejected the substitution; it should not be confused with a verified vendor fix. In the tested LangGraph setup, a permission policy allowed a non-approver to update a pending shared action. Preventing that update preserved the original action and blocked the substitution. That finding applies to the specified in-memory configuration, not every LangGraph deployment. 1, Sections 3.1–3.2 and 4.2.

Ordinary per-call approval in OpenAI's agent development toolkit, versions 0.22.0 and 0.22.2, rejected the tested changes after saved state was restored. Unchanged approved actions still executed. This negative result strengthens the central interpretation: a persistent record of the complete approved operation can survive pause-and-resume behavior without granting permission to a replacement. 1, Table 2.

Trial counts here measure repeatability under controlled conditions. They are not estimates of how often users would be deceived or how many companies are exposed. The approval role was scripted after verifying the displayed request, and one researcher operated the experiments. That design is appropriate for tracing an implementation failure; a human-factors or prevalence question would require a different study. 1, Sections 2.4 and 7.1.

Where the research can go next

The paper's prevention section provides a practical research direction: test approval as a property that must remain true throughout a workflow. Its proposed checks include comparing the complete action at execution time and rejecting or requesting new approval when the meaning changes. The experiments already show two useful intervention points—blocking unauthorized changes and checking what ultimately runs. 1, Section 6.

Building on that framework, a next evaluation could follow approvals through retries, recovery after interruption, and delegation between agents. This is our proposed extension: the same legitimate action should remain executable, while a changed destination, scope, or responsible identity should trigger a new decision. Measuring both rejected substitutions and mistakenly blocked legitimate work would test security and usability together.

A complementary human study could examine whether people understand the complete action shown to them. That would connect accurate presentation with human comprehension, which the current deterministic tests deliberately keep separate. Independent repetitions in production-style storage environments would then test whether the same action-binding rules hold beyond the environments evaluated here.

Why it matters

An approval button is one moment in a longer authorization process. This study makes that process observable and testable: compare what was reviewed with what actually executed, then change the implementation and repeat the check. The most useful outcome is a concrete basis for building approvals that retain their meaning as agent workflows evolve.

Paper details

  • First substantive public release: September 16, 2026, America/Chicago: the author's technical evidence report and result archive became public at 19:53 CDT, before the arXiv submission. 2
  • Repository: arXiv, with an accompanying GitHub research archive.
  • Manuscript analyzed: arXiv:2609.21081v1, submitted September 17, 2026. Its evidence cutoff is September 10; the cutoff is not its publication date. 1
  • Peer review: Preprint, not peer reviewed; no reviewed publication was verified for this version.
  • Study type: Controlled comparative software-security experiments using released products, synthetic identities, and harmless recorded effects.

References

1. Central research paper

Adithyan Arun Kumar. Loopjacking: Hijacking Human-in-the-Loop Approval. arXiv:2609.21081v1, submitted September 17, 2026; analyzed without later revisions. First substantive author research report: September 16, 2026 CDT, documented in source 2. Preprint, not peer reviewed. Version history, full manuscript, PDF. DOI: 10.48550/arXiv.2609.21081. Manuscript licensed CC BY 4.0; this post is an independently written analysis.

2. Earlier author technical report and public-release record

Adithyan Arun Kumar. Loopjacking evidence archive, initial commit d5ae91155c57c8377c45623e4a6335607d5634db. Initial research report, evidence index, GitHub public event history. PublicEvent 15186256098: September 17 at 00:53:20 UTC, equivalent to September 16 at 19:53:20 CDT; public main-branch CreateEvent 21477025708 followed eight seconds later. These document substantive research materials becoming public before the arXiv submission. The repository evidence was consulted as supporting material for the same study.

ShareXLinkedIn

Get the next breakdown

Subscribe for one email per issue — methods, limits, and what it actually means.

Related breakdowns