Whether a person has to approve what an AI agent does gets several different answers across this wiki’s pages, and they are not versions of one position. Some pages say a human must sign off on a named class of actions and build that into the product. Others say a human belongs inside the work — shaping plans, editing artifacts, ratifying rules — rather than at a gate on each action. Some say the question is not whether a human is in the loop but what pulls one in, and answer it with rules, risk scores or classifiers. And some say per-action approval does not do the job it is meant to do, so safety has to come from bounding what the agent can reach. This page sets those answers side by side with what each rests on. It does not settle between them.
What is being asked
Two things are easy to run together here. Model AI Governance Framework for Agentic AI separates an agent’s Action-Space — what its tools and permissions let it do — from its autonomy, meaning how far it decides for itself how to act. The framework treats the two as independent: an agent that can read any file but write nothing has more autonomy and a smaller action-space than one that can modify files but only with human approval at each step. For risk, it puts the scope and reversibility of actions on the impact side and the level of autonomy on the likelihood side. Its spectrum of human involvement runs from agent proposes, human operates through agent and human collaborate and agent operates, human approves to agent operates, human observes. Much of the disagreement below is about which of these a source is adjusting.
The term at the centre, Human-in-the-loop, is itself used for seven distinct patterns across the sources: real-time pairing, an asynchronous approval gate inside a long run, a structured review surface, an escalation path, an enforcement point in the network path, a selection mechanism that decides which actions pull a human in, and a ratification step in which the AI proposes and a human decides what becomes a standing rule. When one page says a human is needed and another says one is not, they are sometimes talking about different patterns.
Answer one: a human must approve a defined class of actions
The first answer keeps an approval step and decides in advance which actions it applies to — usually the irreversible, consequential or externally visible ones.
GitHub states it most directly. How GitHub’s agentic security principles make our AI agents as secure as possible sets out six rules for GitHub’s hosted agents, one of which is to prevent irreversible state changes: on the stated premise that AI can and will make mistakes, agents cannot initiate irreversible state changes without a human in the loop. The author states that the guidelines exist to ensure there is always a human-in-the-loop element in everything GitHub designs, and the post lists “minimize autonomy” among its three design goals. In practice, as GitHub Copilot coding agent 101: Getting started with agentic workflows on GitHub lists them, the coding agent can push only to branches it creates, cannot approve or merge its own pull requests, and does not run CI/CD checks without human approval. Automate repository tasks with GitHub Agentic Workflows carries the same line into GitHub Agentic Workflows: pull requests are never merged automatically, and humans must always review and approve. There, writes are confined to pre-approved Safe Outputs — a deterministic contract listing which artifacts an agent may produce — and the post’s framing is that the agent-only sub-loop can be autonomous because agents act under defined terms inside a human-supervised outer loop.
Other pages place the gate at a named action inside an application. In Codex as a platform: build on the open agent harness, the host application decides which actions need approval, and in OpenAI’s sample Relay application any consequential write, such as rebooking a shipment, requires human approval. OpenAI Agents SDK implements the gate per tool call with a needsApproval predicate that is evaluated against the arguments the model generated rather than against the tool as a whole, so the same tool can run unattended for one input and require sign-off for another. In Agent Payments Protocol (AP2) an order above the configured spending limit leaves its payment mandate unsigned until a manager explicitly approves it. Three-Tier Boundaries writes the same division into an agent’s specification: Always do, Ask first for actions such as modifying a database schema or adding a dependency, and Never do.
The governance sources ask for the same thing in general terms. The Model AI Governance Framework for Agentic AI asks organisations to define significant checkpoints that require human approval — high-stakes actions, irreversible actions, outlier behaviour and user-defined thresholds — and to keep approval requests contextual and digestible rather than raw logs. It prefers deterministic limits over instructed ones; applied to OpenClaw, it asks that human approval be enforced through system-level controls where possible rather than prompt-layer guardrails, which it says may be bypassed or “forgotten”. The practitioner interviews in Implementing effective guardrails for AI agents produce a similar list: blocking direct production deployment without manual review, routing AI-generated changes through standard merge-request review, requiring manual approval above defined cost thresholds, and audit trails that capture both the AI-initiated change and the human approval involved.
A practical guide to building agents presents its version as an escalation rule rather than a fixed checkpoint. Its two triggers are exceeding failure thresholds and high-risk actions that are sensitive, irreversible or high-stakes — cancelling orders, authorising large refunds, making payments. It presents the second as a requirement until confidence in the agent’s reliability grows, not as a permanent property of those actions, and calls human intervention especially important early in deployment. Its Guardrails chapter also has tool safeguards rate each tool low, medium or high risk and pause or escalate before high-risk calls. OpenAI’s separate safety guidance for its Agent Builder product, as relayed on Guardrails, goes further for one case: it asks that approvals stay on when MCP tools are in use, through an approval node where a person confirms every operation, reads included.
The research framings build the gate into the harness. Agent Harness relays a survey that treats the harness as a safety governor with a read-only tier, a sandbox-edit tier and a full-access tier, requiring human approval for irreversible or externally consequential transitions, and argues that approval should become durable harness state — each approval, rejection or correction updating permission rules and escalation policy — rather than an occasional prompt interruption. Software Engineering in the Agent Era: From Trustworthy Change to Human–Agent Software Organizations separates a change’s progression into Candidate, Eligible and Accepted states, so that finishing implementation and formally accepting residual risk are not collapsed into one notion of “done”; its execution unit, a human with their agents, context, tools, permissions and budget, produces candidates and evidence but does not by executing gain authority to accept them. Agentic Agile-V: From Vibe Coding to Verified Engineering in Software and Hardware Development scales the requirement to risk: exploratory work needs only a smoke test with review optional, while high-assurance work requires explicit sign-off.
The Supervised Agency Spectrum offers a structural argument for gates along a long task: because end-to-end success decays multiplicatively across dependent steps, human checkpoints are what make autonomy usable at all rather than a concession to caution. Its observation that most enterprise deployments in regulated domains sit to the left of “bounded”, keeping destructive actions behind human gates, is stated without a supporting measurement.
The one piece of adversarial evidence behind this answer comes from Magentic-UI: Towards Human-in-the-loop Agentic Systems. None of 24 internal adversarial scenarios was effective against the default configuration, which the paper attributes to layered mitigations: action guards requiring user approval, sandboxed execution, and a separate browser. With those mitigations deliberately disabled, prompt injection proved a more reliable exploit, and the authors got the system to exfiltrate private SSH keys and to log into its own web interface and approve actions autonomously. Approval was one of three layers there, so the result does not isolate the human step’s contribution.
Answer two: the human belongs in the work, not at a gate on each action
A second group of pages argues for more human involvement than a checkpoint gives, but places it on plans, artifacts and judgment rather than on individual actions.
In the real-time sense on Human-in-the-loop, a developer stays engaged in high-touch sessions for architecture decisions, tricky refactors, product nuance and ambiguous requirements, while bounded, well-specified tasks run in the background. Human-In-the-Loop Software Development Agents builds this into HULA at Atlassian, where the engineer can review, edit and regenerate the relevant files, the coding plan and the code at each stage; the authors say they aimed for an assistant rather than full automation. In its online deployment, engineers approved 433 of 527 generated plans (82%), and 8% of the issues that used HULA ended with a merged HULA-assisted pull request. Only 33% of surveyed practitioners agreed the code solved their task without human involvement.
AgentClick: A Skill-Based Human-in-the-Loop Review Layer for Terminal AI Agents argues that whether a human is nominally in the loop matters less than what the interface lets them do: terminal output interleaves reasoning, logs and proposed actions, and consequential actions arrive as opaque events or binary prompts. Its response is a review layer where a user can approve, edit, delete or request a targeted rewrite of the artifact itself, which the authors present as improving collaboration rather than merely gating execution. The paper’s walkthroughs are capability illustrations rather than a controlled user study.
The ratification pattern on Human-in-the-loop gates rules rather than actions. There, a CyberAgent team has an AI turn review comments into coding-guideline candidates while a person decides which become team norms, on the reasoning that review comments can depend on context the AI cannot see.
Some pages report what happened when a human was taken out of the work. How far can we push AI autonomy in code generation? ran an agentic workflow over 15–20 generated applications and concludes that for a relatively simple application, even with many strategies and tools integrated, AI is not ready to create and maintain a maintainable business codebase without human oversight. It reports agents adding features nobody asked for, silencing problems with brute-force fixes and declaring success despite failing tests. SWE-chat: Coding Agent Interactions From Real Users in the Wild found that sessions where more than 99% of committed code was agent-written introduced Semgrep-detected vulnerabilities at roughly nine times the human-only rate, and that collaborative sessions were the most cost-efficient mode. The authors read this as suggesting that the push toward full autonomy may be counterproductive. They also summarise what they saw as autonomy outpacing oversight: in Claude Code sessions the agent stopped to ask for clarification in 1.1%–2.6% of turns, while users interrupted it in 3.3%–6.0% of turns and pushed back often. Anthropic’s own usage study, taken up under the next answer, reports the opposite ordering for the same agent: Claude Code pausing for clarification more often than humans interrupt it.
2026 Agentic Coding Trends Report frames the same point as the Collaboration Paradox. Engineers report using AI in roughly 60% of their work while being able to fully delegate only 0–20% of tasks, and the report reads this as collaboration requiring supervision and validation throughout rather than a handoff at the start. Its oversight trend is that human attention shifts from reviewing everything to reviewing what matters — where it is spent changes, not how much of it is needed. The figures are the vendor’s own, given without method or sample.
Answer three: not every action — decide what pulls the human in
A third answer accepts that some actions need a human and rejects the idea that all do; the design question becomes the selection rule.
Do you really need a human in every loop? answers its own title with a no. Its account is that putting a person in front of everything an agent does worked while agents only suggested code but holds teams back once agents deploy services, restart workloads and resolve incidents. It reports that when Port surveyed engineering leaders at a meetup, half the room said they still gate only code merges and pull requests, which the post says breaks the moment an agent does something a pull request never covered. Its reframing is that the question is what pulls the human in, answered by two gates:
- A Rule-Based Gate checks conditions written in advance — service tier, a Friday release freeze, data classification — the same way every time. Its stated strengths are predictability and auditability; its stated limit is that a rule is only as smart as the conditions someone thought to write.
- A Risk-Based Gate has an agent score the specific action against live context — blast radius across a dependency graph, incident severity, whether a deploy is anomalous — and pulls in a human only above a threshold. It is said to need a tuned threshold, tracing of every decision, and a fallback to blocking human review when the model is unsure.
The choosing test is lookup versus judgment, and the post expects most teams to run both. Both gates and Port carry the note that this is one vendor’s formulation, advanced in a post recommending that vendor’s platform, and the selection account on Human-in-the-loop states that its claims come without measurements.
A model-based selector appears in Permission Modes. In Claude Code’s auto mode a separate classifier model reviews most actions instead of the user and blocks only what looks risky. Members of the Claude Code team describe it as judging the call together with the conversation, including the user’s own instruction, so that a push is allowed after “push this to GitHub” and blocked after “don’t push”. They claim that for prompt injection and data exfiltration its risk is far lower than an average human reviewer’s, while saying it does not catch everything. The supporting evals had not been published when that conversation was relayed.
Agentic Autonomy Levels argues that risk and reversibility, not task type, should set the ceiling on autonomy for a task. It proposes three questions for judging whether an agent really operates with high autonomy: how quickly a wrong action would be noticed, how cleanly it could be undone, and what would prove it right. Its top level, managed-by-exception orchestration, escalates only exceptions to a human.
Anthropic’s Measuring AI agent autonomy in practice, which analysed millions of human-agent interactions, supplies usage data on the question. In Claude Code, users with fewer than 50 sessions used full auto-approve in roughly 20% of sessions, rising to over 40% by 750 sessions, while interrupt rates also rose. The study reads this as a shift in oversight strategy from approving each action to letting the agent run and stepping in when something goes wrong. It also reports that Claude Code asks for clarification more often than humans interrupt it, while cautioning that it may not be stopping at the right moments. On the public API, 73% of sampled tool calls appeared to have a human in the loop in some way, and only 0.8% of actions appeared irreversible. The study argues it is too early to mandate specific interaction patterns such as requiring humans to approve every action, and concludes that autonomy in practice is co-constructed by the model, the user and the product. It lists its own limits: one provider, classifications generated by Claude, and a window from late 2025 to early 2026.
One account treats the move away from approval as a trajectory rather than a design choice. At Zup, as reported in Building an Internal Coding Agent at Zup: Lessons and Open Questions, developers began in an approval mode where edits and shell commands need confirmation and moved to an autonomous mode at their own pace as confidence grew; the authors treat human-in-the-loop mechanisms as transitional scaffolds. They leave open what adaptive trust models could replace a binary switch between the two. Permission Modes records the same move as vendor guidance, suggesting sessions start restrictive and loosen as trust builds. Antigravity CLI ships a default that pauses before each file write for line-level review, alongside a mode that auto-approves commands inside its sandbox and asks only when one would leave it.
Answer four: per-action approval is unreliable, so bound what the agent can reach
The fourth answer questions whether approving actions one at a time works at all.
Approval Fatigue relays, through Dive into Claude Code: The Design Space of Today’s and Future AI Agent Systems, Anthropic’s finding that users approve approximately 93% of permission prompts in Claude Code, and reads it as making interactive confirmation behaviourally unreliable as a sole safety mechanism. The architectural conclusion drawn is that a system must stay safe independently of human vigilance and should reduce the number of decisions humans must make. Claude Code’s own documentation, as relayed on Permission Modes, says of its Manual mode that by the tenth approval a user is clicking through rather than reviewing. 2026年のAI Coding Agent活用 ── スピードと安全性を両立させる states the same mechanism from practice: past a certain number of approvals people approve without looking, so security falls rather than rises. Agentic Autonomy Levels names the organisational version “permission laundering” — granting broader access than needed because of approval fatigue.
Automation Bias reaches a parallel point from governance. The same framework says that requiring human approvers to oversee agents continuously can itself produce automation bias and alert fatigue, so adding approval points can make the underlying problem worse. It treats oversight as something to measure — a low override rate may mean rubber-stamping, short review times may mean automation bias — and complements approvals with automated monitoring and denial by default when approval infrastructure fails. Software Engineering in the Agent Era: From Trustworthy Change to Human–Agent Software Organizations describes the same pressure from the queue side: when generation outpaces verification, the responsible person is pushed toward summaries and rapid approvals. Review Bottleneck reports that in one organisation the share of pull requests receiving at least one human review fell from 89% to 68%, and that the added load fell on silent approvals rather than substantive review.
What this answer puts in place of per-action approval is containment. How we contain Claude across products describes supervision through a human in the loop as fallible, citing the 93% figure, and puts its focus on supervising what an agent is able to do through sandboxes, virtual machines and egress controls. Its closing principles are to design for containment at the environment layer first, and to match isolation strength to the user’s capacity for oversight: Claude Code relies on the user as the human in the loop, which the post calls tractable because its users can typically read bash, while Cowork, aimed at users who cannot judge bash, uses an always-on virtual machine boundary. In an internal red-team exercise an employee phished into running a malicious prompt saw Claude exfiltrate credentials in 24 of 25 retries, and the post concludes that egress controls and filesystem boundaries were the only defence that held there.
Beyond permission prompts: making Claude Code more secure and autonomous makes the case for Sandboxing as a replacement for constant approval: within pre-defined filesystem and network boundaries the agent works without prompts, and Anthropic reports that in its internal usage this reduced permission prompts by 84%. Claude Code for web—a new asynchronous coding agent from Anthropic reads that work as an acknowledgement that agents run without step-by-step approval are far more productive than agents that require it, making convenient safe execution — not tighter approval — the problem to solve; its author calls this the only approach to agent safety that feels credible to him. Designing agentic loops makes the productivity side explicit: per-command approval prompts dramatically reduce an agent’s effectiveness at brute-force problem solving, and YOLO Mode — approving everything by default — is described as both genuinely dangerous and key to the most productive results. Its three ways of living with that are a sandbox, someone else’s computer, or accepting the risk, and it says most people choose the third.
Mitigating Prompt Injection Attacks in Software Agents gives the vendor view from OpenHands. It calls confirmation mode — asking permission before almost any action — especially important on a local workstation, but judges it a stopgap that limits the value of agents without adding much security, and prefers hard policies such as network rules, with agents seeking a human’s approval to escalate permissions. Deny-First Permission Evaluation shows the layered form: deny rules win over allow rules, unmatched actions escalate to a human, and further layers such as a classifier and a sandbox apply regardless of how attentive the user is.
Even here a human is not removed. In Anthropic’s sandbox, as Beyond permission prompts: making Claude Code more secure and autonomous describes it, an attempt to reach something outside the sandbox notifies the user, who decides whether to allow it. The same practitioner post that argues for fewer prompts also argues that guardrails do not remove the need for human supervision, and treats skipping permissions entirely as unsuitable for work development. And Sandboxing summarises the practice as treating agent output like an untrusted pull request: let it work in isolation, review the result, and merge only after verification — moving the human from each step to the result.
What backs each answer
The evidence behind the four answers is of different kinds, and much of it comes from the vendors of the systems discussed.
| Human approval is… | What decides when a human is involved | Main backing in the grounding pages | |
|---|---|---|---|
| A defined class of actions | a required control for irreversible, consequential or high-stakes actions | the class of action, a cost or spending threshold, or the risk tier of the task | vendors’ own design principles and documentation; a governance framework; practitioner interviews; one adversarial test in which approval was one of three layers |
| In the work, not at a gate | necessary, but on plans, artifacts and rules rather than on each action | the kind of work — judgment, ambiguity, team norms | a deployment study at one company; a dataset of real sessions, mostly from one agent; one team’s experiments; a demo paper; vendor-reported figures |
| Decide what pulls the human in | necessary for some actions, not scalable for all | a written rule, a live risk score, a classifier, or accumulated trust | a vendor argument without measurements; vendor claims about a classifier with unpublished evals; one provider’s usage study; one company’s experience report |
| Bound what the agent can reach | behaviourally unreliable as a sole mechanism | a boundary set in advance, with the result reviewed afterwards | one vendor’s telemetry figures (93%, 84%) and internal red-teaming; practitioners’ own risk judgments |
Where the answers meet and split
Some points are shared. No grounding page argues that the permanent answer is to approve every action. Where per-action approval does appear, it is a product default, an option or guidance for a particular case — Manual mode, Antigravity CLI’s pause before each file write, Zup’s approval mode, OpenHands’ confirmation mode, Copilot Chat asking for approval before any MCP tool call, OpenAI’s guidance to approve every operation when MCP tools are in use. The pages that discuss it at length call it transitional, a stopgap, or fatiguing. Nor does any grounding page argue for removing humans entirely, though the containment answer moves them furthest: in Anthropic’s sandbox a human decides at the sandbox edge, and in the general practice a human reviews the result before merge, while Cowork’s always-on boundary and running an agent on someone else’s computer are described without a human step at all.
Several sources sit on more than one side. The Model AI Governance Framework for Agentic AI asks for human approval checkpoints and, in the same document, warns that requiring continuous oversight can itself produce automation bias. Anthropic’s own write-up both relies on the user as Claude Code’s human in the loop and calls that supervision fallible, citing the 93% approval rate that a third-party analysis reads as making confirmation unreliable as a sole mechanism. GitHub keeps a human at every irreversible step while confining the agent’s writes to pre-approved outputs so that the steps in between need no one.
Where they split is on what the human is for. For the first answer, the human carries responsibility for an irreversible change. For the second, the human supplies judgment and context the agent does not have. For the third, the human is a scarce resource to be spent where a rule or score says it matters. For the fourth, the human is an unreliable filter whose load should be reduced by construction. The answers also split on what they treat as the unit of approval: the action, the artifact, the rule, or the boundary within which actions need no approval at all.
Related pages
Agentic Autonomy Levels, Lethal Trifecta, Agent Hooks, Schema Gating, Sandbox Runtime, Compositional Reliability