A human approved the deployment at 2:00. The agent executed it at 4:17.
In the two hours and seventeen minutes between those events, the artifact was rebuilt. One target dropped out of the set and two new ones were added. A configuration value changed. None of that stopped anything, because none of it had to. Every credential was still valid. The approval was still on file. The action went through.
So the human approved something at 2:00. The question the system never asked is whether it was this.
The answer everyone reaches for
When people worry about autonomous systems acting without supervision, the reflexive answer is human-in-the-loop. Put a person in the loop, require a human to sign off on the consequential steps, and the system is under control.
Almost all of the debate that follows is about the human. Whether there is one. How many approvals are required. How fast a reviewer can move without becoming the bottleneck. What almost nobody asks is the more basic question: what, exactly, is the approval attached to?
Human approval begins with a description of an intended action. Execution happens against a specific action in a specific state of the world. Unless something binds those two together, the approval can quietly outlive the action it was meant to justify. The problem is the gap between the action the human understood and the action the machine eventually performed.
Why this is real and not pedantic
The first reaction from anyone who runs these systems is that the 2:00-to-4:17 drift is an edge case. It is not. Retries, failovers, environment changes, target-set changes, parameter updates, shifts in upstream data: all of these happen routinely between approval and execution, and they happen by design. The entire point of an autonomous system is that it keeps working without stopping to re-ask. So it keeps moving across exactly the interval where the action can change.
The approval was a statement about the action as it was described at 2:00. The execution was an event in the world at 4:17. Descriptions and reality drift apart, and agentic systems are built to keep operating straight through that drift. Human-in-the-loop stops meaning anything in precisely that gap, and most systems have no idea the gap is there.
A different action wearing the same name
Our operational language hides the problem. "The deployment" sounds like a single persistent object that exists on Tuesday and is still the same thing on Wednesday. But consider what actually sits under that phrase:
- deployment of artifact A to hosts 1 through 10
- deployment of artifact B to hosts 1 through 12
- deployment after a policy change
- deployment with one configuration value altered
These are not necessarily successive moments of the same approved thing. They may be separate actions that happened to inherit the same workflow ID, the same ticket, the same approval record, the same friendly name. The name is continuous. The action underneath it is not.
Here is the whole problem in miniature. At 2:00 the approval record says APPROVED. At 4:17 the approval record still says APPROVED. Nothing in that field tells you whether the object underneath it is still the thing that was reviewed. The record persisted. Whether the action did is a different question, and the record cannot answer it.
So the real question was never "was the agent authorized?" It is "was this specific action, as it actually executed, the one the human approved?" In most systems nothing asks that. The credential is valid, the approval is on file, the check is green, and none of those establish that the executed action is the approved action.
What binding would actually take
If the approval is going to mean something, it has to attach to the action itself, not to the action's name. That means the specific artifact, the targets, the parameters, and the material conditions under which the action was approved. If any of those materially change, it is a different action, and the earlier approval does not automatically cover it.
That last item matters more than it looks. A human often approves an action on the strength of things that are not parameters passed to a tool at all: current inventory, current account state, a classification, a vulnerability finding, an upstream system reporting that a host is safe to modify. The action can be identical down to the byte while the basis on which it was approved has moved. So binding the command is not the same as binding the approval. When something material changes, the system has to determine whether the old approval still covers the action. It should not simply inherit the answer because the workflow still has an approval attached to it.
There is a second half, and it is the harder one. Something has to check that binding at the moment of execution, and it cannot be the agent. If the agent can both redefine the action and decide whether its redefinition still fits the approval, the binding constrains nothing. The party capable of changing the thing being governed cannot also hold unilateral authority to decide what the approval still covers. The check has to sit somewhere the agent cannot rewrite it.
"So just ask the human again"
The obvious fix is to re-prompt the human on every retry. It does not work, for two reasons.
The first is that it rebuilds the bottleneck human-in-the-loop was supposed to remove. If a person has to re-approve every retry and failover, you have not automated anything, you have added latency to it.
The second is worse. A human re-prompted constantly stops reading. Approval degrades into reflex, and now there is a signature on an action nobody actually evaluated, which is more dangerous than no approval at all, because it looks like oversight and is not.
The goal is not more human intervention. It is a system that knows when the thing a human already judged has ceased to be that thing, so that fresh human judgment is triggered exactly when the action has materially changed and not otherwise. That is a more demanding thing to build than "add an approval step," and it is a considerably more useful one than generic advocacy for keeping a human in the loop.
What we were actually proving
Step back and the pattern is familiar. A review happened. An approval was recorded. A workflow contains evidence that a human participated. Those are all facts about the process. They are true, and they are auditable, and they are not the thing we needed.
The property we needed was that the action which executed was the action the human judged acceptable. The process running is not evidence that the property holds. We keep the first and assume it gives us the second, and in the gap between them the action changes and the approval does not.
A human approved something. Whether it was the thing that executed is a separate question, and in most systems, nobody is asking it.
The meaningful control, then, is not merely the approval record. It is the binding that makes that approval apply to this action and no materially different one.
I’ve written up how approval, authority, and evidence bind to a specific action — and how a system can establish that the executed action is the approved one — in a formal reference model. If you want the machinery underneath this essay: MICRM.