The Human Approved the Action. The Agent Ran a Different One.

Your review queue is healthy. A human reads every risky action before it runs. They check the diff, they check the recipient, they click approve.

Then the system executes something else.

That is not a hypothetical. It now has a name — loopjacking — and a paper demonstrating it against the agent frameworks your team is probably running.

The research

In September 2026, security researcher Adithyan Arun Kumar published Loopjacking: Hijacking Human-in-the-Loop Approval, documenting a class of vulnerability where a human approves one agent operation and the system executes a materially different one. Two variants:

Representation mismatch. The substitute operation is already encoded in the request, but the approval prompt omits or misdescribes it. The reviewer approves what they're shown, which was never the full story.

Post-approval state substitution. The reviewer sees the correct operation. Then mutable workflow state is changed after the approval lands and before execution. The approval is applied to an action nobody saw.

The reproduction list is not fringe software. Post-approval substitution reproduced across seven releases of Agno AgentOS (through 3.0.9) and twelve versions of LangGraph Agent Server (through 0.14.0). The representation variant landed against OpenClaw 2026.2.23, patched one build later. The negative control is instructive: the OpenAI Agents SDK resisted, because its serialized continuation keeps an exact per-call binding between what was approved and what runs — the mutated operation simply doesn't match, and gets rejected.

This is a 40-year-old bug wearing a new framework

Systems security has a name for the gap between the thing you checked and the thing you used: TOCTOU — time-of-check to time-of-use. It's why filesystems, kernels, and payment systems stopped trusting a validation performed even milliseconds before the operation. The check must be atomic with the use, or an attacker lives in the gap.

Agent frameworks rebuilt that gap and put a human in front of it. The approval dialog became the check. The tool call became the use. And in between sits mutable state that the framework — or anything that can influence the framework, including the agent itself — can rewrite.

Here's the uncomfortable part: every human-in-the-loop control you've deployed rests on one silent assumption — the thing the human saw is the thing that executes. Loopjacking is what happens when that assumption is just an assumption. When it fails, your approval workflow isn't a security control. It's a UI event that generates a false audit trail: a log that says a human authorized the very action they never saw.

The standards are arriving — with the hard part left open

The industry knows enforcement has to move to the moment of execution. The OWASP Agent Control Standard, released as a v0.1 public preview in September 2026, defines exactly this shape: a Guardian component that evaluates pending actions at runtime hooks like toolCallRequest, returning allow, deny, modify, or ask verdicts before the tool fires.

That's the right architecture. But v0.1 is a preview, and the preview leaves the loopjacking-shaped questions open: it doesn't yet specify how an approval is bound to the exact arguments that execute, who the approver was, or when an approval expires. It even defaults to proceed if the Guardian fails to answer, unless the deployment opts into deny. The standard tells you where to stand. It doesn't yet hand you the binding.

Meanwhile, the research keeps confirming that binding is the control that works. In September's agent security roundup, a "Verifiable Action Card" approach — cryptographically tying the displayed action to the executed one — cut browser-agent attack success rates from 68–100% down to zero.

What binding actually requires

Strip the terminology and four requirements fall out:

1. Canonical rendering. The reviewer approves the exact serialized action — target, arguments, recipient — not a summary that something else generated.
2. Immutable pending state. Between check and use, nothing can rewrite the operation. Not the orchestrator, not a retry handler, not the agent.
3. Comparison at the moment of use. The executed action is matched against the approved form when it fires, not when it was queued.
4. Independent evidence. Both the approved action and the executed action are recorded somewhere the agent infrastructure can't quietly edit.

If any one of the four is missing, the other three are decoration.

Where VeriSwarm sits in that gap

This is the architecture VeriSwarm's trust layer was built around, so the mapping is direct.

Gate issues its decision — allow, review, or deny — against the event at execution time. A trust decision in Gate isn't a pre-authorization token that floats around waiting to be spent on something else; it's evaluated against the action that's actually firing, scored against the agent's live behavioral record. An agent whose trust score degraded in the last five minutes gets the current answer, not the one from before lunch.

Guard enforces where substitution can't hide: the Guard Proxy sits on the tool call itself. What Guard inspects — and scans, and tokenizes, and can kill — is the request going out the wire, not a description of it. There is no gap between the checked representation and the executed one, because they're the same bytes.

Vault closes the evidence requirement. Every decision and every action lands in an immutable, hash-chained audit ledger. If what was approved and what executed ever diverge, the divergence is in the chain — tamper-evident, exportable, and not editable by the agent, the framework, or anyone having a bad quarter. When the question is "did a human actually authorize this?", you want cryptography answering, not a workflow tool's activity log.

The takeaway

Loopjacking isn't an argument against human-in-the-loop. It's proof that approval is a decision, and decisions don't protect anything until they're bound to execution. Audit your stack with one question: between the moment a human clicks approve and the moment the tool call fires, what guarantees those two things describe the same action?

If the answer is "the framework, probably" — that's the gap. Gate's trust decisions are free to start, and the binding is the product.