Loopjacking: The Human Approved A, and the System Ran B

Adithyan Arun Kumar published Loopjacking, Hijacking Human-in-the-Loop Approval, on arXiv on 17 September 2026, with a reproduction archive on GitHub and an evidence cutoff of 10 September. The premise is stated in the first two sentences of the abstract and is worth quoting closely, because the whole argument follows from it. Human approval is often treated as the last security boundary before an agent executes a consequential operation, and that boundary is only meaningful if the operation presented for review is the operation later authorised or released. Loopjacking is the name given to failures of that binding. A human approves what they understand as operation A, and the implementation uses that decision for a materially different operation B. Nothing about the model is broken in this story. The approval happened, the human was paying attention, and the wrong thing ran anyway.

There are two variants and they fail in different places. In a representation-based attack, B is already encoded at the moment of approval, but it is omitted or misrepresented in what the reviewer is shown. The human genuinely consented to the thing on the screen, and the thing on the screen was an incomplete rendering of the thing in the payload. In a post-approval state-substitution attack, the rendering is honest and the human sees the correct A, and then mutable workflow state is changed before execution so that the approved decision is spent on B. The second is the more unsettling of the two, because no amount of careful reading at approval time helps. The reviewer did everything right. The approval was simply a token that the system later redeemed against different goods.

The testing is unusually specific, and the specificity is the reason to trust it. Post-approval substitution reproduced in seven tested Agno AgentOS releases ending at 3.0.9, with the archive placing the affected range from 2.5.6 and naming 2.5.5 as the control boundary. It reproduced in 12 tested versions of a conditional in-memory LangGraph Agent Server composition ending at 0.14.0, from 0.7.5, with the archive noting that the result depends on the tested in-memory configuration and the authorisation policy in use. Representation mismatch reproduced in OpenClaw 2026.2.23 and was rejected in 2026.2.24, so that one has a fixed release. The OpenAI Agents SDK at 0.22.0 and 0.22.2 is the negative control, where serialised continuation preserves exact per-call binding and rejects a mutated B. The author is careful to say this is a purposive comparative study rather than a prevalence survey, and the archive records plainly that Agno and LangGraph have no vendor-fixed release in it. There are no CVE identifiers and no CVSS scores attached to any of this at the time of writing.

That negative control is the most useful finding in the paper and it is the one most likely to be skipped over. If every framework tested had failed, the reasonable conclusion would be that approval binding is hard and everyone is doing their best. One framework holds. Serialised continuation, where the approved call is carried forward as a fixed object rather than reconstructed from live state, rejects the substitution while still running the legitimate work. So this is a design choice, not a law of physics, and the two mitigations the paper proposes are correspondingly boring. Render the complete canonical action at approval time and compare it exactly at use time, or prevent unauthorised mutation of pending state. Either one blocks the tested attacks. Neither requires a smarter model, a better prompt, or a new product.

Regular readers will recognise the shape, because this is the third time this month we have written about a control that documented intent rather than verified outcome. Plugin4Shell was a commit pin that the agent never checked it had landed on, so a reviewed hash sat in the configuration while different code ran. The OWASP agentic skills work found declared behaviour and actual behaviour coming apart, where the manifest said one thing and the skill did another. Loopjacking is the same failure applied to the single control that sits above all the others. An approval record is evidence. It is the thing you hand an auditor when they ask how a consequential action gets authorised, and it is the artefact that most AI governance policies name explicitly. What this paper establishes is that an approval record can be entirely truthful about what a human consented to and entirely silent about what was executed, and that nothing in the record itself will ever tell you which case you are in.

The regulatory exposure here is sharper than for a typical framework bug, because human oversight is not merely a good practice in the current rulebooks, it is a legal requirement with its own article. EU AI Act Article 14 requires that high risk systems be designed so that natural persons can effectively oversee them, which includes understanding the output and deciding not to use it or to intervene. An oversight mechanism that renders A and executes B does not meet that bar, and the fact that a human clicked approve makes the paperwork look better rather than worse. Article 12 compounds it, because automatically generated logs that record the approval but not the divergence will not reconstruct the incident. The same logic reaches the state level work we covered earlier this month. California SB 947 turns on meaningful human review of consequential decisions, and the Colorado ADMT rules run on the same concept. A review is not meaningful if the reviewed object and the executed object can differ, and no regulator has yet had to decide whether a loopjacked approval counts as oversight at all.

The cold water is important and the coverage will probably get it wrong. This is not a flaw that lets a stranger reach into your agent from the open internet. Both variants require an attacker who can already influence what gets encoded into the pending action or mutate the state behind it, which in practice means an injected instruction that reached the planning step, a compromised or hostile tool or MCP server, or a co-tenant with more write access to shared workflow state than anyone intended. That is a real precondition, and it is also precisely the threat model everybody has spent the year documenting, so it should not be read as reassurance. The LangGraph result is conditional on a specific in-memory composition and authorisation policy rather than being a blanket statement about the framework, and reporting it as LangGraph is broken would be wrong. OpenClaw has a fixed release at 2026.2.24. Agno and LangGraph do not have one in the archive, so anyone relying on approval gates in either should be checking the current upstream position themselves rather than taking a blog post, including this one, as the state of play.

The framework mapping lands on control families that have existed for decades, which is the usual pattern and the usual trap. ISO 27001 covers this across change management, segregation of duties, secure development and the logging and monitoring family, and the honest question for most statements of applicability is not whether an approval control is documented but whether anything verifies that the approved item and the executed item were the same item. ISO 42001 is where human oversight belongs as a designed property of the system rather than a line in a policy, and it is the right place to record which agent actions require approval, what the reviewer is shown, and how the binding is enforced. SOC 2 asks the period question, which is the difficult one here, because an approval workflow that was correct at the walkthrough tells you nothing about whether the binding held for every approval across twelve months. PCI DSS reaches it wherever an agent can touch cardholder scope, since change approval is an explicit requirement and an approval that does not bind is a control failure rather than a documentation gap. Vanta, Drata, Secureframe, Sprinto, Thoropass and Hyperproof will all hold the policy and collect evidence that an approval process exists, and not one of them will compare the payload your reviewer saw against the payload that ran, so this is a control you build and then evidence rather than one you buy.

The work is small and most of it is a single comparison nobody is currently making. Render the complete action at approval time rather than a summary, because a truncated or prettified rendering is the representation attack with extra steps. Hash the approved object and compare that hash at execution, refusing to proceed on a mismatch, which is the exact-use-time-comparison mitigation the paper proposes and is a few lines rather than a project. Treat pending approvals as immutable, so that any change forces a fresh approval instead of silently inheriting the old one. Log both the approved payload and the executed payload so that a divergence is discoverable afterwards by a query rather than by an outage, since today most systems log only that approval occurred. Then test it, by approving A, mutating the state, and confirming the run is rejected, on the understanding that an untested binding is an assumption. And put the question to your vendors in the form the paper makes available, which is whether the approved call is carried forward as a fixed serialised object or rebuilt from live state at execution, and write down the answer when there is not one. The ISO 27001 and ISO 42001 guides on this site cover the change management, human oversight and logging control families this belongs in, the compliance readiness assessment will show you which of them you can currently evidence, and the policy templates library has the AI governance, acceptable use and change control clauses to hang it on.