Human approval is often treated as the default safeguard for autonomous systems. At enterprise scale, that control can become slow, superficial and unreliable. Safer autonomy depends on defined authority, consequence thresholds, runtime enforcement and the ability to intervene when it matters.
A person sees a permission request, scans the proposed action and clicks Approve. The workflow continues. The audit log shows that a human was involved, and the organisation records the action as controlled.
But what has actually been controlled?
If the reviewer has already approved dozens of similar requests, lacks the context to assess the consequences or knows that rejection will hold up the process, the approval may provide little more than an administrative signature. Anthropic reported in 2026 that users approved roughly 93% of Claude Code permission prompts, with attention declining as prompts accumulated. Its separate research found that experienced users tend to move away from approving each action towards monitoring activity and intervening when needed.
This is the flaw in treating human-in-the-loop as a safety strategy. The presence of a person does not, by itself, create effective control. As autonomous systems increase the volume, speed and complexity of action, universal approval can degrade into latency, fatigue and false assurance.
The better model is bounded autonomy: systems are allowed to act within an explicitly defined operating envelope, while people set the boundaries, handle exceptions and retain the authority to stop, reverse or prohibit consequential actions.
Approval does not scale with autonomous action
Human approval works best when decisions are infrequent, material and understandable. It is a credible control for authorising a large payment, accepting a legal commitment or approving an irreversible change. It becomes weaker when applied indiscriminately to every tool call, data update, message, workflow transition or system response generated by an AI agent.
The economics are obvious. An agent can inspect records, query systems and execute multiple steps in seconds. A reviewer cannot evaluate each action at the same speed without either slowing the system to human throughput or reducing the depth of scrutiny. In practice, organisations get one of three outcomes: a growing approval queue, a heavily pre-approved process or reviewers who click through routine requests.
The human factors evidence makes the problem more serious than a simple productivity bottleneck. A meta-analysis of 18 automation studies found that higher levels of automation improved routine performance but weakened performance during failures and reduced situation awareness. A systematic review of automation bias found that decision-support systems can create both commission errors, where people follow incorrect recommendations, and omission errors, where they fail to act because the system did not prompt them.
Recent research on AI-agent oversight points in the same direction. One 2026 study found only moderate agreement among reviewers about which agent actions were risky and modelled safety as declining when escalation volume exhausted human attention. Another longitudinal study of 400 repeat code reviewers found rising approval rates, longer review queues and fewer inline comments as exposure to AI-generated work increased. Both are early studies and should not be treated as universal proof, but they reinforce a mature finding: human attention is a finite control resource.
Universal approval therefore creates a structural contradiction. The more autonomous activity an organisation generates, the more approvals it requests. The more approvals it requests, the less meaningful each approval is likely to become.
Human presence is not the same as human control
The phrase “human-in-the-loop” compresses several very different roles into one reassuring label. A person may define policy, approve an individual action, monitor a live process, investigate an exception, intervene during an incident or audit activity afterwards. These roles are not interchangeable.
The critical distinction is between participation and authority. A reviewer can be present in a workflow without having enough information, time, expertise or organisational permission to change its outcome. Conversely, a human can retain decisive control without reviewing every routine action, provided the system operates within enforceable limits and can be interrupted effectively.
This matters because autonomous systems do not merely produce recommendations. They may act through software tools, access data, modify records, send communications and coordinate other systems. Microsoft describes the architectural challenge directly: agents can plan and chain actions across systems without a person explicitly approving each step, increasing the importance of managed identity and least-privilege access.
A control model designed for recommendations cannot simply be stretched over machine-speed execution. The organisation must decide which authority it is willing to delegate, under which conditions and with what evidence.
Bounded autonomy turns intent into an operating envelope
Bounded autonomy is not full autonomy with a few warnings attached. It is a deliberate design in which the system may act only inside a defined envelope.
That envelope should specify five things.
First, scope: which workflow, systems, tools, records and users the agent may affect. An agent that categorises service tickets may need read access to case history and narrow write access to ticket fields. It does not need unrestricted access to the customer database or the ability to send external messages.
Second, consequence thresholds: which actions are sufficiently material to require escalation or approval. These thresholds may reflect financial value, legal effect, data sensitivity, customer harm, operational criticality, novelty or irreversibility. The safest boundary is rarely a model-confidence score alone. A highly confident system can still take an action with unacceptable consequences.
Third, reversibility: what can be rolled back, corrected or compensated. Updating a draft knowledge record is different from deleting production data. Sending an internal recommendation is different from terminating an employee's access. The less reversible the action, the stronger the case for human decision authority before execution.
Fourth, runtime enforcement: controls must sit outside the model's own reasoning. Permissions, tool allowlists, transaction limits, data rules and segregation of duties should be deterministic and auditable. OWASP recommends minimum tool access, per-tool permission scoping and explicit authorisation for sensitive operations.
Fifth, intervention: the organisation must be able to pause, override, quarantine, roll back or stop the system safely. Intervention is not a secondary feature. It is the mechanism that keeps bounded autonomy bounded.
These controls create a different safety model. Instead of asking a person to assess every action, the organisation predefines what the system may do, detects when it approaches the boundary and directs scarce human attention towards the cases where judgement changes the outcome.
Consequence should determine the human role
The practical question is not whether a workflow is “human-led” or “AI-led”. It is what happens if a particular action is wrong.
Low-consequence, reversible and well-understood actions are strong candidates for autonomous execution with monitoring. Examples include enriching an internal record, routing a request, preparing a draft or applying a reversible configuration within a sandbox.
Actions with uncertain, cumulative or customer-facing consequences may require supervised autonomy. The system can proceed within limits, but unusual behaviour, low-quality evidence, policy conflict or threshold breaches trigger a hold and route the case to an accountable specialist.
High-consequence, irreversible, rights-affecting or legally reserved decisions should remain approval-gated or prohibited. This includes decisions where a person's professional judgement is the safeguard rather than an administrative step.
Regulation already reflects this more nuanced model. Article 14 of the EU AI Act requires oversight for high-risk systems to be commensurate with risk, autonomy and context. It also expects authorised people to understand limitations, recognise automation bias, disregard or reverse outputs and interrupt a system so that it reaches a safe state. This is not a requirement for universal approval. It is a requirement for effective, proportionate control.
UK data protection law also preserves meaningful human involvement for solely automated decisions with legal or similarly significant effects. The key word is meaningful. Adding a nominal reviewer does not resolve the risk if that person cannot assess or change the decision.
Bounded autonomy therefore does not remove human oversight. It concentrates it where the consequences justify it.
Safety moves from approval queues to runtime governance
Once organisations adopt this model, governance can no longer remain primarily a set of policies, committees and pre-deployment reviews. It must become part of the live system.
Every autonomous action should be attributable to a distinct identity, an accountable owner and a versioned policy decision. The organisation should be able to reconstruct what the system attempted, which data and tools it used, what rule permitted the action, whether a threshold was crossed and how any intervention was handled.
That requires a runtime governance stack: workflow orchestration, agent identity, scoped permissions, policy enforcement, telemetry, evaluation, escalation and incident response. These capabilities may come from several platforms rather than one product, but they must work as a coherent control system.
The operating model changes as well. Managers who once approved routine work become policy owners and exception decision-makers. Security teams define safe tool access and monitor abnormal behaviour. Risk and compliance teams translate obligations into decision rules and evidence requirements. Internal audit tests whether the controls operate in practice, not merely whether an approval field exists.
The measures must change too. Approval counts reveal little. More useful indicators include escalation rate, queue age, reviewer disagreement, override frequency, policy-denial rate, rollback success, unauthorised tool attempts, repeat incidents and the proportion of actions that remain reversible.
The objective is not to minimise human involvement. It is to maximise the value of human judgement.
Bounded autonomy can fail without mature controls
There is a legitimate counterargument. Many organisations do not yet have the identity, observability, policy engineering or incident-response capabilities required to govern autonomous systems safely. Replacing approval gates too early could exchange a visible bottleneck for invisible exposure.
Thresholds can be badly designed. Permissions can be too broad. Monitoring can miss novel behaviour. Escalation queues can become overloaded. A stop mechanism may exist on paper but fail to bring a complex workflow to a genuinely safe state.
These are not reasons to retain universal approval indefinitely. They are reasons to treat autonomy as an earned operating capability.
Systems should progress through increasing levels of authority only when the organisation can demonstrate suitable controls. Start in shadow mode. Restrict tools and data. Limit transaction value and action volume. Test failure and recovery paths. Measure false escalations and missed incidents. Expand authority only when evidence supports the change.
Some workflows will remain human decisions. Others may remain assistive because the cost of governing autonomy exceeds its value. Bounded autonomy is not a target level for every process. It is a method for matching control to consequence.
Leaders need an autonomy portfolio, not a blanket policy
The immediate leadership task is to stop asking whether the organisation allows autonomous AI and start deciding where, how and under whose authority it should operate.
A practical agenda begins with four moves.
- Inventory autonomous action: Identify systems that can already use tools, change records, communicate externally or trigger downstream work. Many organisations have more delegated machine authority than their formal AI inventory suggests.
- Classify by consequence: Assess each action class by potential harm, reversibility, data sensitivity, legal effect, operational criticality and volume. Use this classification to select assistive, approval-gated, supervised or bounded execution.
- Build the control envelope: Give each agent a distinct identity and accountable owner. Define permitted tools, scoped data access, rate and spend limits, escalation rules, evidence requirements and safe intervention mechanisms.
- Test the human system: Measure whether reviewers receive enough context, whether queues remain within capacity and whether people can recognise, challenge and stop unsafe behaviour. Human oversight is a capability that must be engineered and rehearsed, not a box added to the workflow.
The strategic choice is not between autonomy and human control. It is between unmanaged autonomy disguised by approvals and deliberately bounded autonomy supported by real control.
Human-in-the-loop will remain essential in specific decisions. But as a universal safety strategy, it asks people to supervise at a scale and speed they cannot sustain. The organisations that govern autonomous systems well will not put humans everywhere. They will put human judgement where it has authority, context and consequence.
