Human-in-the-loop AI approval works only when a person can understand the proposed action and the system executes exactly that action. An “Approve” button proves neither. Give the reviewer concrete consequences and evidence, then bind their decision to an immutable action. If the recipient, amount, account, attachments, or scope changes, ask again.
I think the most useful design question is: what work can the reviewer actually do here? If the interface offers reassurance instead of inspectable facts, the human becomes a decorative checkpoint. If the backend later rebuilds the action from mutable state, even careful review cannot save it.
How can a human approve one action and an agent execute another?
The September 17, 2026 Loopjacking paper names two failures. A representation attack hides or misrepresents part of the action before review. A state-substitution attack shows the correct action, then changes pending state before execution.
The author reproduced failures in specific released products and configurations, including a conditional in-memory LangGraph Agent Server setup. The OpenAI Agents SDK was a negative control: its tested serialized continuation rejected the substituted call. The representation mismatch appeared in the tested OpenClaw shell-wrapper path at version 2026.2.23 and was rejected at 2026.2.24. This is a purposive comparison, not a survey of how often agents fail. Its tested versions are not a statement about current patch status.
The practical lesson is narrower than “human oversight is broken.” The object a person reviews must remain the object their decision releases. An audit log helps reconstruct what happened. It does not, on its own, prevent that mismatch.
Why do people stop inspecting approvals?
There are different cognitive problems behind the same click.
Automation bias means people can lean too heavily on automated advice. A systematic review published in 2011, covering 74 included studies with a healthcare focus, identified workload, task complexity, time pressure, trust, and experience as relevant factors. It also discussed training, accountability, and the way advice is presented. That evidence is useful for design hypotheses, not a measured effect size for today’s agent approval screens.
Habituation means a repeated signal loses its ability to attract attention. A 2019 security-dialog replication, with 1,236 participants, found that monetary loss significantly changed compliance with security dialogs. It also confirmed that habituation and visual attractors influenced decisions. Its monetary incentives and primary-task setting limit transfer to everyday work. The lesson is not to punish users. It is to stop treating every trivial event like the same urgent warning.
Review workload matters too: waiting time is not inspection time. A June 2026 observational study of agent-generated code review followed 400 repeat reviewers across 11,429 reviews. Within each reviewer’s early and late review episodes, the aggregate approval rate rose from 30.1% to 36.8%, while inline comment volume fell. The authors explicitly cannot establish causality: improving agent code could partly explain the change. These are code-review observations, not proof that every approval dialog produces rubber-stamping.
Together, these sources argue for separating two questions: did the action stay bound, and did the person have a realistic chance to judge it? The first needs a backend check. The second needs a test with people.
What should an approval screen show?
My proposed pattern is an action card, not a chat summary. These are design recommendations to test with your users, not results from a usability trial.
| Review task | Show by default | Avoid |
|---|---|---|
| Recognize the consequence | Exact action, destination, sending account, money or access change | “Complete task” as the whole description |
| Check the evidence | Source record, relevant policy, unresolved facts | A confident paragraph with no way to inspect it |
| Compare a revision | Old and new values, changed attachments and audience | Silent replacement of the previous card |
| Decide freely | Reject, edit, defer, and approve as distinct choices | A preselected approval or a single giant proceed button |
| Understand reversibility | What can be undone, cost, and relevant deadline | “You can fix it later” without checking |
For a payment, the first line might be “Pay EUR 420 from the operating account to Vendor A.” The card then shows the verified destination, invoice, duplicate-payment check, and any mismatch. For an email, show the final recipients, sending identity, full body, and inspectable attachments. A summary can orient the reader, but cannot replace the material they are authorizing.
Generate this card from typed action fields. Do not let a retrieved document or the agent’s persuasive explanation supply the authoritative recipient or amount. Keep the explanation separate from the action facts. If an important field cannot be rendered, block release rather than quietly hide it under “details.”
Make the review task specific: “Check the recipient and total against this invoice” is more useful than “Are you sure?” Keep the critical fields visible without forcing the reviewer to reconstruct them from memory across screens. Use text labels as well as visual signals, keyboard-accessible controls, and readable layouts on small screens.
Approval frequency is a product decision. Define which low-risk actions are already authorized and which need a fresh decision. Do not bundle unrelated consequential actions into one vague batch to reduce clicks. The objective is meaningful review, not maximum approval speed.
How do you bind the decision to execution?
Use a server-owned, versioned action record. Include the principal, account, tool operation, destination, exact arguments, attachment content digests, relevant preconditions, and expiry. Render the review from that record. Store the decision against its digest and version. Any material change creates a new record and a new review.
At release, check the approver’s current authority, expiry, revocation, preconditions, and exact payload match. Consume the approval atomically so two workers cannot release it twice. If the target state has changed, stop for reconciliation or a fresh decision. Do not rebuild the action from the newest chat message.
A digest is a comparison mechanism, not authentication. If an attacker can rewrite both the action and its approval record, matching hashes prove nothing. Storage access control, a trusted rendering path, and enforcement at the execution boundary are part of the design.
What does the business gain?
The first payoff is fewer wrong sends, unintended payments, and access changes that nobody meant to approve. Binding will not catch every bad decision, but it can stop a changed action from borrowing a valid decision. That is a narrower, testable promise.
It also makes incidents less expensive to untangle. Keeping the reviewed payload, decision, and attempted execution together gives the response team something concrete to compare. Limit sensitive data in logs and retain it only where the workflow needs it.
For a security review, show the binding tests and the review screen together. That can reduce back-and-forth about what “human oversight” actually means. For audit or liability questions, the same record is better evidence than a bare approval timestamp. It is not a compliance certificate, a liability shield, or proof that a reviewer understood the action.
These are expected benefits, not measured savings from a customer deployment. Track wrong-action incidents, investigation time, and security-review follow-ups before claiming a return.
How do you test the cognitive and UX side?
Recruit people who actually own the workflow. Give them realistic cards with synthetic data: a normal action, an incorrect recipient, an unexpected attachment, a changed account, and an ambiguous source. Test the same critical cases after a stretch of ordinary decisions, not only as isolated warnings.
Measure wrong approvals, correct rejections, comprehension of the consequence, and review effort. Ask participants what they believed would happen after clicking. Compare that answer with the stored action. Separate time in the queue from active review, and do not reward speed at the expense of error detection.
A small pilot reveals usability problems. It does not establish a universal safe approval rate. Set the acceptance bar from the consequence of a miss, inspect individual failures, and test with keyboard and small-screen users too. A design that rejects every action has not succeeded either.
The release gate should require both kinds of evidence: deterministic tests that changed actions cannot inherit approval, and user evidence that the review screen supports a real decision. Neither a reassuring UI nor a perfect payload match can carry the whole job.
Further reading
- AI Agent Audit Log: verify declared authorization phases and detect tampering after the fact.
- What Is an Agent Evaluation Framework?: separate deterministic gates, judgment, and final-state checks.
- AI Workslop Is an Org Design Problem: keep responsibility for verification with the team handing off the work.
Sources and limits
- Loopjacking: Hijacking Human-in-the-Loop Approval, September 17, 2026. Primary research on specific tested approval implementations, not prevalence.
- Automation bias: a systematic review of frequency, effect mediators, and mitigators, published June 16, 2011, journal issue January 2012. Cross-domain evidence with a healthcare focus.
- Replication: Do We Snooze If We Can’t Lose?, 2019. Security-dialog experiment with incentive and task-setting limits.
- Habituation at the Gate: Rising Approval and Declining Scrutiny in Human Review of AI Agent Code, June 2026. Observational evidence, not a causal experiment or an agent-dialog study.
The action card and usability protocol are proposed designs. I have not run a usability study or tested a production approval service for this article.