AI Governance

Human in the Loop for AI Agents: Which Actions Need Approval

By Clateway Technology Council · 18 October 2026 · 6 min read

Bottom line: "Human in the loop" is not a control until you can say which actions stop for a decision, who decides, and what evidence they see. Let AI agents read, analyse and prepare freely; put an independent approval in front of the five action types that move money, destroy data, change privileges, expose sensitive information or delegate authority. Then design the approval itself so a busy person can actually say no.

This piece follows our AI agent governance framework, which sets controls by autonomy level. Here we zoom in on the one control every level relies on: the approval step.

Why "human in the loop" is no longer specific enough

A chatbot that gives a bad answer creates a problem you may still catch. An agent with credentials turns the same bad decision into an API call, a deleted resource or a payment before anyone notices. As a CIO.com contributor put it on 29 September 2026, the question is not whether there is a human in the loop but exactly where that human sits (CIO.com, 2026-09-29).

The risk lists agree. The OWASP Top 10 for Agentic Applications (December 2025) names tool misuse (ASI02), identity and privilege abuse (ASI03) and human-agent trust exploitation (ASI09): people over-trusting what an agent tells them. That last one matters for approvals. An approval screen that repeats the agent's own summary is exactly where over-trust happens.

Regulation points the same way, with a delay. Article 14 of the EU AI Act requires high-risk systems to let overseers understand the system, stay aware of automation bias, override its output and stop it safely (AI Act, Art. 14). The Digital Omnibus (Regulation 2026/1744, in force since 27 July 2026) moved those high-risk duties to 2 December 2027 for Annex III uses and 2 August 2028 for Annex I products (ActuIA, 2026-10-06). Brookings notes that for about the next 16 months, the controls on agents in high-stakes areas will be organisational rather than statutory (Brookings, 2026-10-12). So the approval design is up to you, for now.

The five actions that always need a second decision

Let agents search, summarise, correlate, recommend and prepare. Stop them, every time, before these five:

| Action | Example | What the approver must see | |---|---|---| | Move money | Pay a supplier invoice | Amount → recipient → source account → the instruction that triggered it | | Delete or overwrite production data | "Clean up stale resources" | The exact items, their dependencies, the blast radius, whether it can be undone | | Change privileges | Add a role, rotate a credential, edit a policy | Who gets what access, for how long, and who asked | | Expose sensitive information | Email an attachment, fill a vendor ticket | What data, its classification, the recipient, the destination system | | Create or delegate authority | Hand a task to another agent with broader credentials | The authority passed on, to whom, for how long, and whether it can be passed again |

These categories come from the CIO.com analysis above and map directly onto OWASP ASI02, ASI03 and ASI07. The rule behind them is old: the party that prepares a consequential action must not be the party that releases it. Finance calls it segregation of duties. For agents it means one agent must never propose an action, get the access to perform it, approve that access and then carry it out. That isn't autonomy. It's self-authorisation.

Design the approval, not just the checkpoint

Most failed human-in-the-loop controls don't fail because the checkpoint is missing. They fail because the approver can't make a real decision. Four design rules fix that.

1. Build the approval screen from the action, not from the agent's explanation

If the agent writes the text the approver reads, "Send requested information to vendor" can hide something very different. Build the approval card from the actual tool call: destination, data classification, parameters, scope. Show the agent's reasoning next to that, never instead of it.

2. Approve the specific action, never the workflow

"Approve the payment workflow" can't be reviewed. "Pay €4,200 to supplier X from account Y because of invoice Z" can. Each approval should cover one concrete, bounded action with a short expiry. If the parameters change while the approval waits, cancel it and ask again.

3. Put the limit outside the agent

Agents "can misinterpret or work around embedded rules", according to the AWS Reimagine 2026 study of 154 executives at 128 organisations (Help Net Security, 2026-09-28). The approval gate belongs in the tool layer, an authorisation service or a policy engine the agent can't change. Don't put it in the prompt.

4. Budget for attention

Every approval costs a person's attention. Ask too often and people click "approve" without reading. That is automation bias, the same risk Article 14(4)(b) warns about. Keep the stops for the five categories above, batch low-risk items into a daily review, and track approval metrics like any other control.

A second approval doesn't always mean a second person

Putting a person in front of every agent action would kill the value of automation. The second decision can also come from:

• A deterministic policy engine, e.g. "payments over €1,000 to new beneficiaries are blocked", which the agent can't change.
• A transaction-control system that already exists in finance or IAM.
• A person, kept for actions that are irreversible, unusual or above a threshold.

The AWS study recommends treating new agents "like probation for a new hire": start with human approval, widen autonomy only after the agent proves reliable, and keep the option to narrow it again (Help Net Security, 2026-09-28). Brookings makes the same case for setting scope limits and the actions that need human intervention in advance, backed by traceable evidence (Brookings, 2026-10-12).

How to measure whether your approvals work

An approval control that nobody measures turns into a rubber stamp. Track four numbers per agent, every month:

1. Approval rate: share of requests approved. Close to 100% for months suggests rubber-stamping or a gate that can be relaxed.
2. Median time to decision: rising times mean too many requests or poor context on the approval card.
3. Rejection reasons: classified, so the agent's scope or prompts can be fixed.
4. Bypass attempts: actions blocked because they skipped the gate. Even one is worth investigating.

Use these numbers to decide when an agent moves up or down an autonomy level in your governance framework.

A 30-day starting plan

• Week 1: List every agent and every tool it can call. Mark each tool against the five categories.
• Week 2: Move approval gates for those tools out of prompts and into the tool or authorisation layer.
• Week 3: Redesign the approval cards so they show the actual action: who, what, where, how much, whether it can be undone.
• Week 4: Start the four metrics and set a quarterly review that can widen or narrow each agent's autonomy.

Frequently asked questions

What does human in the loop mean for AI agents?

It means a named person or an independent control must approve certain agent actions before they run. For agents, it should be defined per action type (payments, deletions, privilege changes, data sharing, delegation), not as a general promise of oversight.

Which AI agent actions should require human approval?

At minimum: moving money, deleting or overwriting production data, changing access rights, sharing sensitive data outside a trust boundary, and creating or delegating privileged authority. Low-risk actions that are bounded, logged and reversible can usually run on their own.

Does the EU AI Act require human oversight of AI agents?

Article 14 requires effective human oversight of high-risk AI systems, including the ability to override and stop them. After the Digital Omnibus, those duties apply from 2 December 2027 (Annex III) and 2 August 2028 (Annex I). Agents outside high-risk uses are not directly covered, but Article 14 is a sound design reference.

How do you avoid approval fatigue?

Gate only consequential actions, use policy engines for rule-based decisions, batch low-risk reviews, and watch approval rates and decision times. A gate that is approved 100% of the time is either redundant or ignored.

Can another AI agent act as the approver?

Only if it is truly independent: separate credentials, separate instructions, and no way for the requesting agent to influence it. For irreversible or high-value actions, keep a person as the final approver.

---

Suggested images (alt text):

1. Hero: "Flow diagram showing an AI agent's proposed action stopping at an approval gate before reaching production systems"
2. Table graphic: "Five AI agent actions that need human approval: money, data deletion, privileges, sensitive data, delegation"
3. Metrics graphic: "Dashboard tiles showing approval rate, time to decision, rejection reasons and bypass attempts for an AI agent"

Topics: human in the loop AI agents, agentic AI, AI governance, AI agent security, EU AI Act, OWASP

Related articles

• AI Agent Security: The New Identity Management Frontier Demanding C-Suite Attention – As AI agents proliferate across enterprise systems with unprecedented autonomy and access privileges, organizations face a fundamental shift in identity and access management. The emergence of…
• Enterprise AI Agents Enter Production: Advanced Models Drive Autonomous – Major cloud providers are launching production-ready AI agent platforms powered by sophisticated models like GPT-6 variants and Claude Opus 5.5, marking a fundamental shift from experimental AI to…

How Clateway can help

• Technology and cyber board advisory – Independent technology and cyber expertise for boards and supervisory boards: advice on management's plans, NIS2 accountability, AI governance and director…
• AI agents for IT, security and compliance – An AI workforce for technology leaders: agents such as an Information Security Officer, SOC analyst or architecture reviewer that read your data and propose…
• AI governance for the enterprise – Use AI safely across your organisation: guardrails per company, private AI routing, zero data retention, AI activity logs, rate limits and an AI kill switch.