Your agent ran smoothly for 3 consecutive weeks. By the fourth week, it started calling tools confidently. delete_customer_records with a wrong filter — and deleting 4,000 records instead of 40. No one reviews it, because the workflow is "stable." Rollback takes an entire afternoon, explaining to the boss takes a week.
This is not a rare occurrence. 51% of organizations have run agents in production, but only 37–40% have actual containment control — kill switch, purpose binding, network isolation. A Kiteworks survey also indicates a 15–20 percentage point gap between the control organizations have invested in and the control they actually need. This means most are more confident than the system allows.
And the deadline is approaching: Article 14 of the EU AI Act — mandatory human oversight for high-risk AI systems — takes effect on August 2, 2026.. That is, two weeks from when this post goes live.
Think of HITL like sudo, not like an approval form.
Linux does not ask you for a password when ls. It asks when you rm -rf /varSudo operates based on three properties:
- The Gate is located at the action boundary, not at the start of the session.
- Default is deny — without approval, the command does not run, period.
- Every escalation is logged (
/var/log/auth.log), auditable.
Most current HITL systems for agents do the opposite: ask once at the beginning of the workflow ("are you sure you want to run this process?"), then let the agent run wild for the next 20 steps. That is like "logging in as root and leaving the terminal open all day."
Why a gate at the tool level is better than a gate at the workflow level
n8n 1.28 (early 2026) moves human-in-the-loop down to the tool level: a gated tool will not execute without human approval — the agent still plans, still calls other safe tools, and only stops exactly at the dangerous point. The difference from a workflow-level gate is fundamental:
| Workflow-level gate | Tool-level gate | |
|---|---|---|
| Stop point | Beginning/end of the process | Exactly at the boundary of risky actions |
| Context for the approver | "Approve the whole process?" — ambiguous | "Delete 40 records with filter X?" — specific |
| Agent self-corrects the plan after being rejected | No — must restart from the beginning | Yes — agent treats rejection as a tool output and adjusts |
| Number of approvals is meaningless | Many (approving even harmless steps) | Few (only approving steps with "teeth") |
The third point is the most valuable: when the human reviewer clicks reject with a reason, the agent treats it as feedback and creates a different plan — instead of getting stuck. HITL becomes a part of the ReAct loop, not a handbrake pulled in the middle of a highway.
Agent plan → gọi tool "an toàn" (đọc, tra cứu) → chạy ngay
→ gọi tool "gated" (xoá, ghi, gửi) → PAUSE
→ người duyệt: approve → tool chạy, ghi audit log
→ người duyệt: reject + lý do → agent nhận feedback, re-plan
Classification: which actions require sudo?
Don't gate everything — gating everything means gating nothing, because reviewers will approve by inertia. Principle: gate actions that are irreversible or outside the system.
- Delete records (DELETE, DROP, truncate): irreversible without a hot backup.
- Write to production (deploy, migration, price update): reversible but expensive.
- Send external emails/messages: once it leaves the SMTP server, it cannot be recalled — and it carries your company's reputation.
- Transfer money, create invoices, sign contracts: obvious.
Conversely: read data, calculate, write to staging, send internal notifications — let these run directly. In practice, a good ratio is under 10% of tool calls requiring a gate. Higher means you are designing boundaries incorrectly, or your agent should not be running autonomously yet.
Automation complacency: the real enemy is not the agent
The most annoying HITL paradox: the more reliable the system, the more inattentive the reviewer becomes. If the last 200 review requests were all correct, the 201st request will be approved in 1.5 seconds without anyone reading it. This is an old phenomenon in aviation (autopilot causing pilot complacency), now recurring with agent reviewers.
A few design ways to combat it:
- Display diffs, not descriptions. "Agent wants to update price list" is useless. "SKU-1042 price: 129,000đ → 12,900đ" makes the reviewer alert exactly when they need to be.
- Force reason input when approving highest-tier actions (money transfer, bulk delete). Typing a sentence forces the brain to engage.
- Mix in "canary requests": occasionally insert an intentionally incorrect request to measure if the reviewer is still reading. The canary pass rate is your vigilance metric.
- Limit the number of reviews per person per day. The 80th request reviewer of the day is no longer a human in the loop — just latency in the loop.
Checklist before August 2, 2026
Article 14 does not require "an approve button". It requires the supervisor to understand, intervene, and stop the system. Translated into technical tasks:
- List tools by risk tier — tier 0 runs directly, tier 1 gate + approval, tier 2 gate + approval + reason. One workshop with the business owner is enough.
- Move the gate from workflow-level down to tool-level — if using n8n, version 1.28 or higher has it built-in; if writing a custom scaffold, block at the tool executor level, do not block at the prompt (agents can "forget" a prompt, but cannot bypass code).
- Kill switch independent of the agent — an endpoint that can shut down all tier 1–2 tools without requiring agent cooperation. This is exactly what 60% of organizations are missing.
- Immutable audit log: who approves, what is approved, when, and what context the agent provides. Temporal's event history model is a good reference — every step is recorded and replayable.
- Measure baseline vigilance. Before the auditor asks: reject rate, average reading time per request, canary leakage rate.
Each item can be implemented in 1–2 weeks for a medium-sized system. This coincides unpleasantly with the remaining time.
Sudo has existed for 40 years not because Linux doesn't trust sysadmins, but because it forces sysadmins to pause for half a second before an irreversible action. HITL for agents is the same: the value lies not in the approve button, but in the system architecture acknowledging that there are boundaries machines must not cross — even if it is correct 200 times in a row. Because the 201st time is the most expensive.