Why Can Human Approval Be Hijacked? Designing the “Decision Boundary” for the AI Agent Era Through Loopjacking

🎥 The YouTube version is also available:

Can Human Approval Be Replaced? Loopjacking and the Human Gate for AI Agents

Books: Runtime Al Governance Practical Guide: Dynamic Al Governance Design through Knowledge Flow, Trust Engine, and Decision Trace

When we entrust AI agents with important operations, many systems place a human approval step at the end of the workflow.

Wire transfers, deployments, permission changes, external messages, customer notifications. It may appear that the workflow becomes safe once an AI proposes an action, a human reviews it, and then clicks “Approve.”

But if the operation a human reviewed on the approval screen is not the same operation that is actually executed, that button is not a security boundary.

The paper Loopjacking: Hijacking Human-in-the-Loop Approval, published in September 2026, makes this problem explicit. The author defines the operation a human understands and approves as A, and a different operation that is actually executed using that approval as B. When a product’s own workflow incorrectly reuses approval for A to execute B, the paper calls this failure Loopjacking.

This is not merely a case in which a human is deceived into approving a dangerous action. The human may have reviewed and approved the correct action, A. Even so, if the state or arguments change after approval, the system may still execute B. The problem is not human attentiveness. It lies in the semantic binding between approval, state, and execution outcome.

The Paper’s Core Argument

The paper distinguishes two points in time in any approval-based operation:

1. At approval time: A human sees a representation of the operation and approves it.
2. At execution time: The system refers to that approval and sends the actual operation to an external system.

For the workflow to be safe, the operation used at execution time must be substantively identical to the operation the human reviewed at approval time. The paper calls this the approval-binding invariant.

There are two representative forms of Loopjacking.

1. Substitution Through Incomplete Representation

The dangerous operation, B, is already present in the request data before approval. However, only part of it is displayed to the human as A. The human approves A, while the system executes B, including arguments that were never shown.

The paper reproduces this pattern in OpenClaw’s shell-execution path. It identifies a case in which the inline command fragment displayed to the user does not match the complete argument vector passed to the node. In the affected version, undisclosed arguments could alter the effect of execution. The patched version verifies the integrity of the complete argument vector and rejects a mismatch.

2. State Substitution After Approval

In this case, the human initially reviews and approves the correct operation, A. Between approval and the point at which that approval is consumed, however, the task, thread, or continuation-call state is rewritten to B. If the system checks only whether the operation has been approved, without comparing the current arguments again, approval for A can be used to execute B.

The paper reproduces this pattern in a test configuration of Agno AgentOS and in a LangGraph Agent Server with a particular permission configuration. In the former, a different set of arguments could be supplied to an approved run while preserving the same call ID. In the latter, a party other than the approver could replace the tool call with the same ID in a thread awaiting approval.

Importantly, the paper does not claim that every agent framework is vulnerable. The targets were intentionally selected products and configurations; this is not an estimate of ecosystem-wide prevalence. OpenAI Agents SDK 0.22.0 and 0.22.2 are presented as contrast cases: when an approved call is modified after serialization, the SDK rejects it on resumption.

The Solution Is Not an “Approved” Flag, but Revalidation of the Complete Operation

The paper’s practical conclusion is straightforward:

Store the complete operation that the human approved, reconstruct the operation immediately before execution, and compare the two. If any material difference exists, reject the operation or require re-approval.

What must be stored is not merely a tool name or call ID. The complete set of arguments, target resource, destination, type of impact, requester, task or session scope, approver, expiration, and consumption state must be treated as a single normalized description.

The approval screen should also be generated from this normalized description. If a short display string and a richer execution object are maintained separately, the gap between them becomes an opportunity for substitution.

Controlling who can update a pending-approval state is also useful. But preventing state updates alone is not sufficient. Legitimate retries, argument completion, template expansion, and workflow migration can all change the effect of execution. Therefore, the final general-purpose line of defense is a complete comparison immediately before execution.

The chinoba Perspective: Approval Is Not a UI Event, but a Meaningful Decision Record

This paper provides a security-oriented confirmation of the importance of the Decision Trace, Boundary, and Human Gate concepts that chinoba has explored.

A design that stores human approval merely as a flag such as approved = true loses essential information: what was approved, on what grounds, by whom, and under what conditions. Approval should instead be recorded as a semantic unit containing the following elements.

This is close to the idea of a Semantic Chunk. A Semantic Chunk treats a document or conversation not as fragmented strings, but as a unit of meaning that retains references to its source evidence.

The same applies to defending against Loopjacking. Approval must not be represented only by text that appeared on screen or by an ID. It must be treated as an evidence-grounded semantic unit that remains bound to the execution effect.

In other words, approval should be stored and validated as the following chain:

Evidence behind the proposal → Normalized operation → Display seen by the human → Human decision → Operation immediately before execution → Execution outcome

If any part of this chain changes, the change itself must become a new object of judgment. This is what chinoba calls a Meaning Trace: the minimum unit needed to keep a decision executable and explainable.

From Human Gate as a Place to Stop to Human Gate as a Boundary That Verifies Meaning

Human-in-the-Loop is often implemented as a mechanism in which a person presses a button at the end of a workflow. In that design, however, the human may bear responsibility without possessing real control.

From the chinoba perspective, a Human Gate is not simply a place where AI processing pauses. It is a boundary that connects a proposal generated by AI to organizational meaning structures, authority, evidence, and stop conditions—and turns it into an executable decision.

At a minimum, this requires three things:

1. Generate the display and the executable operation from the same semantic structure.
2. Mechanically detect differences between approval time and execution time.
3. Invalidate the original approval and require a new decision whenever a difference arises.

With this structure, humans do not need to read every detail of the underlying implementation. Instead, they can review, at the appropriate level of granularity, what will be executed, what evidence supports it, and what has changed since the previous decision.

This is a design for increasing AI autonomy without reducing human judgment to a mere formality.

Implications for Implementation

For enterprise AI agents and approval workflows, the following questions should become design-review checklist items:

• Is the approval screen generated from the complete operation that will actually execute?
• Does the approval record retain a normalized description that includes all arguments, targets, destinations, and authority scope?
• After approval, who is allowed to modify the task, thread, continuation call, configuration, or template?
• Immediately before execution, does the system compare the current execution effect with the approved operation?
• Are differences, re-approvals, rejections, and execution outcomes retained as a trace that can be audited later?

In systems that pass LLM output directly into external operations, protection against prompt injection alone is not enough. Even when the AI makes the correct proposal and the human gives the correct approval, ambiguity in the state, representation, or continuation process can allow that judgment to be reused for a different operation.

Conclusion

The central lesson of Loopjacking is simple: placing a human in the approval path does not, by itself, make a system safe.

What matters is not only who clicked the button. It is whether we can preserve and verify, as a consistent semantic structure, what that person saw, what they approved, what evidence they relied on, the scope of their approval, and which execution outcome ultimately used that approval.

As AI agents become more deeply embedded in organizational work, the Human Gate should not simply become more frequent. It must evolve into a clearer decision boundary.

The knowledge infrastructure that connects Semantic Chunks, Ontology, and Decision Trace is not only for helping AI generate answers. It is also the foundation for transforming AI proposals into actions that humans can responsibly approve—and for ensuring that those decisions remain verifiable afterward.

References

• Adithyan Arun Kumar, Loopjacking: Hijacking Human-in-the-Loop Approval, arXiv:2609.21081 (2026)
  https://arxiv.org/abs/2609.21081
• chinoba: Knowledge Flow
  https://chinoba.org/research/knowledge-flow/
• chinoba: Trust Infrastructure
  https://chinoba.org/research/trust-infrastructure/

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance