Imagine your AI agent handling supplier requests; it gathers information, prepares a response, and routes exceptions to the manager. But during a test, it changes a delivery commitment it was only authorized to recommend. The team notices, and someone says, “Stop the agent!” That’s when the questions start. Does stopping it cancel actions already queued? Who can suspend its access? Can the manager see which suppliers received messages? Who keeps urgent orders moving while the team investigates?
This is a hypothetical scenario, but it exposes a practical weakness leaders can test before it becomes a real operating problem. A named owner and a written escalation policy don’t demonstrate that the organization can take back control when it needs to.
My recommendation? Before giving an agent more authority, rehearse how your people would take it back. Make the ability to interrupt the agent and recover part of the decision about how much authority to delegate.
(In an earlier piece, What to Ask Before AI Acts, I argued that leaders should decide in advance what would make an agent hit pause. This article takes up the next question: whether your people can actually pause it.)
What new research adds
AuthorizationBench, a preprint posted October 20, 2026, tested four AI models in three agent frameworks on 286 tasks. Across 6,864 runs, agents acted outside their assigned authorization 19.2% of the time. The tasks ran on simulated services, and the researchers deliberately left unauthorized paths open so they could see whether agents would take them. The result measures agent behavior under those test conditions; it doesn’t estimate how often agents overstep in deployed business systems (arXiv: AuthorizationBench).
On October 22, 2026, METR published the results of a three-week red-teaming exercise (a deliberate attempt to find weaknesses) on OpenAI’s internal systems for monitoring its AI agents, carried out by a METR employee and a Redwood Research employee. The investigators found vulnerabilities in the system as it stood on and before July 21, including ways agent actions could avoid being monitored. OpenAI says the vulnerabilities affecting its production safeguards have been patched. METR says it hasn’t evaluated that claim, and the report describes the system at the time of the assessment (METR: Red-Teaming OpenAI’s Internal Agent Monitoring Systems).
Together, these findings give leaders a reason to test two assumptions separately: that an agent will respect its assignment, and that oversight will reveal a problem when it doesn’t. The management recommendation here is my interpretation; neither study tests whether an executive rehearsal improves business outcomes. What they do is make it harder to justify confidence based only on a clear instruction or the existence of a monitoring system.
Give accountability something to work with
At Whole Enterprise™, I use Intelligence Stewardship™ to describe responsibility for how intelligence informs high-stakes choices. Delegation is part of that responsibility, and so is the ability to change course afterward. Consider the manager held accountable for our hypothetical supplier workflow. If she can’t inspect the action history, restrict further commitments, or get help from the team that controls access, she carries the responsibility without the means to act on it when an exception arrives. That’s an organizational design problem, and resolving it requires agreement among the business owner, the people doing the work, and the technical team. A policy can name those relationships; a rehearsal can reveal whether they function.
The exercise should also expose dependence on particular people. If only the original developer knows how to suspend the workflow, the organization needs to decide whether that is acceptable, given when the workflow runs and what it can affect. If the manager is unavailable, the team needs a usable fallback. These questions deserve attention while the workflow is still bounded and the cost of learning is manageable.
Rehearse one boundary crossing
Choose an agent-enabled workflow whose next step is a meaningful increase in scope. Select one plausible action outside its assignment. Use a test environment and fictional records so the exercise cannot affect customers, employees, or live commitments. For the supplier example, the boundary might be simple: the agent may recommend a delivery change, but only a designated manager may approve it.
Now ask the team to demonstrate what would happen if that boundary were approached or crossed. Have someone other than the person who built the workflow follow the response process. Begin with detection. What evidence reaches the manager? Does it identify the action, the affected record, and the authority required? A vague alert that something unusual occurred may give the responder too little to make a decision.
Then examine interruption. Demonstrate the actual mechanism that prevents further action, and establish whether it applies to the running task, queued work, connected tools, and any other agents acting on its behalf. Everyone involved should agree on what a button labeled “pause” actually does.
Finally, continue the business process. Who handles the supplier request while the agent is unavailable? Which records establish what already happened? Who decides whether correction, notification, or additional review is necessary? This is where the exercise becomes useful to executives, because it shows the work that intervention creates and whether the organization has assigned time, expertise, and authority to perform it.
The clock matters more than the label
Calling a process “human supervised” tells you little about whether intervention can arrive in time.
Suppose, in our hypothetical test, a supervisor receives an alert only after a batch of supplier messages has been sent. The alert may help with investigation and correction but it can’t prevent those messages from reaching their recipients.
The leadership decision is whether that timing fits the stakes. For some reversible internal actions, later review may be sufficient. For an external commitment that is difficult to undo, the workflow may need approval before execution or a technical restriction that prevents the action. There’s no universal response-time target. Ask the team to compare the time available to prevent the harm in question with the time it actually takes to detect, decide, and intervene.
Don’t assume that shutting down a process reverses its effects. Sending a message, changing a shared record, and initiating a payment create different recovery problems, and the proposed autonomy should reflect those differences.
Keep the rehearsal proportionate
A fair objection is that elaborate oversight can consume the value an agent is supposed to create and a process that requires an executive to approve every minor step is unlikely to scale. I would use the rehearsal to find where human intervention is necessary, then make that intervention workable. Give low-risk, reversible work appropriate freedom, and put stronger limits around actions whose effects cannot readily be contained. A successful rehearsal shows what happened in one scenario, with one configuration and one team, so treat it as a snapshot. Record the conditions, and revisit the exercise when permissions, connected systems, or the workflow’s scope change materially.
Measure practical things: whether the right person received useful evidence, whether the interruption worked, and whether essential work continued. Treat unresolved gaps as inputs to the delegation decision. A narrower permission or smaller rollout may be the sensible next step.
Make the next approval more concrete
At your next review, ask the delivery lead to show one intervention rehearsal alongside the demonstration of what the agent can accomplish. Keep the discussion focused. What authority is being delegated? What would require intervention? Who can act, and what did the rehearsal establish about their ability to do so? Then resource the answer. If the response depends on a person, ensure that person has access, coverage, and time. If it depends on a control, have the appropriate specialists test it. If recovery depends on another function, include that function in the operating agreement.
The goal is to create room for useful autonomy with a credible way to respond when circumstances change. Leaders can grant more freedom deliberately when they understand both what the system can do and how the organization will take back control.
Accountability becomes meaningful only when the person carrying it can act.
