Loopjacking: you approved A, the runtime ran B

A paper submitted September 18 names a failure class I've been half-aware of and never had a word for, then reproduces it in software you probably have installed.

Loopjacking describes the case where a human approves operation A and the runtime executes a materially different operation B. Two variants. Representation-based: B is already encoded but hidden from the approval prompt. Post-approval state substitution: the workflow state is mutable, and something replaces A after the click but before execution.

The reproductions are what make this real rather than theoretical. Post-approval substitution in seven Agno AgentOS releases through 3.0.9. In twelve versions of a conditional in-memory LangGraph Agent Server composition through 0.14.0. Representation mismatch in OpenClaw 2026.2.23, fixed in 2026.2.24.

The negative control is the useful part. OpenAI Agents SDK 0.22.0 and 0.22.2 are not vulnerable, and the reason is a single design decision: they serialize the approved call. The approval binds to an immutable serialized operation, not to a handle pointing at mutable state.

That's the rule, and it's small enough to apply this afternoon. When you render an approval prompt, serialize the exact operation, hash it, show the human that operation, and at execution time verify the hash still matches. If your approval object is a reference into a state dict that other code can write, you have this bug.

Human-in-the-loop is the safety story most agent products lead with. "We ask before we do anything dangerous." I've written that sentence in a README myself. This paper says the asking is only as good as the binding between the question and the action, and three popular frameworks got that binding wrong in shipped releases.

It pairs with an arXiv paper from the same batch on authorization quiescence, which starts from the fact that cancelling a long-running agent doesn't revoke its authority. The agent outlives the process through credentials, queued tasks, callbacks, reservations and provider-side operations. The paper defines a cut protocol that linearizes a root cut, fences old-root expansion and protected sinks, then tests it: two cancellation-only and one cut-only execution accept an already-scheduled late effect, while two cut-plus-fence executions plus a restart and a stale-process run reject it. Seventeen of seventeen registered outcomes matched.

Both papers are saying the same thing about control. The approval and the cancel are UI gestures. Whether they mean anything depends on a binding you probably didn't implement.