Consider a fictional order workflow.
A user reviews a draft order for 120 units from a specified supplier, billed to a particular buyer account and delivered to a named location. The user approves it. A few moments later, the agent reports a target-system order ID.
That result may be enough for a person—or a downstream process—to continue on the assumption that the approved and executed actions were equivalent. Inventory may be reserved. A payment check may begin. Another agent may notify the supplier.
But suppose the available records show only two things: the approval screen and a later order-system response. They do not link the approved supplier, quantity, account and destination to the material properties of the action actually invoked.
This does not prove that anything went wrong. It leaves a more precise question unanswered:
What evidence links the approved action to the action that actually executed?
The question is not simply whether to add a human approval step. It is what evidence allows the next decision to rely on that approval.
Approval is a decision record, not the whole execution chain
Human approval can be a meaningful control. It can stop a consequential action, introduce accountability and bring contextual judgment into an automated workflow.
However, an approval record establishes that a person made a decision about something presented for review. By itself, it does not establish that the later execution remained within those approved bounds.
That distinction matters because an agent action may pass through several architectural components between a human-readable preview and a business system. An orchestration layer, connector or delegated agent may sit between them. The process may also transform parameters, retry an operation or resolve a target dynamically. Each mechanism may be legitimate. Each may also create a point where the reviewed action and the invoked action cease to be identical in a material way.
I refer to the evidentiary relationship between the approved scope and the action actually executed as approval-to-action integrity. The practical question is not simply whether an approval exists, but whether approval evidence and execution evidence can be connected strongly enough to support the next decision.
From approval to verified outcome
A useful way to inspect that relationship is through a five-stage evidence-linkage model:
Approval → Scope / Parameters → Invocation → Target-System Response → Verified Outcome
The stages are not a universal agent architecture, and they may not always appear as separate chronological events. They are points at which a decision owner can ask what the available evidence establishes.
- Approval records the decision made about the action presented for review.
- Scope / Parameters capture the material properties of that decision: for example, supplier, quantity, account, destination, spending limit or environment.
- Invocation is the concrete tool call or execution event submitted toward the target system.
- Target-System Response shows what the receiving system returned, interpreted according to its actual semantics.
- Verified Outcome establishes the relevant resulting state to the depth required by the action and its consequences.
For a simple synchronous operation, a target-system response may be strong enough evidence. An asynchronous or consequential workflow may require a later state check. The model does not prescribe one evidence mechanism; it exposes where unsupported assumptions can enter.
- Approval recordHuman decision
- Approved scopeSupplier, quantity and destination
- InvocationTool call and action ID
- Target-system responseOrder ID and response semantics
- Verified outcomeConfirmed order state
Where divergence can enter
Divergence does not require a malicious agent. It can arise through ordinary system behavior.
A connector may normalize units, apply defaults or translate one schema into another. A target may be resolved from an alias, tenant or environment variable. An orchestrator may select a different tool or delegate the task to another service. A retry may reconstruct an invocation after the original approval. Identity or authorization context may change across a handoff.
None of these mechanisms is inherently defective. The risk appears when a material change is possible but the evidence cannot show whether the final action remained within the approved bounds.
Current human-in-the-loop frameworks make this distinction visible. The OpenAI Agents SDK can scope an approval decision to a particular tool call, including its call identity, tool name and arguments. LangChain/LangGraph distinguishes approving a proposed action as-is from editing its tool or arguments before execution.
An intentional edit is not an integrity failure. For the approval to support reliance after an edit, the edited action needs to become the authoritative object to which the approval and subsequent execution are linked. “A human reviewed the workflow” is less useful than knowing exactly what the person reviewed, what changed and what eventually executed.
Approval evidence and execution evidence must be linkable
Imagine that an audit trail contains a valid approval at 10:02 and a successful order event at 10:03. Time proximity may be helpful, but it does not necessarily establish equivalence. There could have been several orders, a retry or a change in resolved target. In the opening scenario, the decisive evidence would connect the approved supplier, quantity, account and destination to the invocation that produced the specific order record.
The necessary linkage depends on the workflow, but useful properties may include:
- the approval or decision identifier;
- the tool-call or action identifier;
- material parameters or a stable representation of them;
- the target object, tenant or environment;
- the identity of the actor or service;
- the authorization and execution context;
- the target-system receipt and resulting object identifier.
Not every architecture must expose every field, and not every action needs cryptographic binding. The evidentiary requirement is narrower: before approval can support reliance on the claim that the executed action remained within the approved bounds, the approval and execution records need a traceable relationship across the properties that matter.
Recent research examines related boundaries from several directions. Weng’s 2026 preprint on Consent Integrity asks whether the action shown for approval is securely bound to the exact action that executes. Koch and Wellbrock identify a broader governance-to-action closure gap: governance defines obligations, but systems may still fail to show where those obligations bind to concrete actions or how that relationship can later be demonstrated.
The model here helps a decision owner examine the whole operational sequence—from approved scope to invocation, response and verified outcome. Its purpose is to determine what the available evidence supports before relying on an agent-performed action.
When the binding is incomplete: a controllability question
If approval-to-action binding cannot be established, the conclusion should remain bounded. Suitable reader-facing descriptions might be pending, not verified or requires verification. These are not formal universal states. They are ways to avoid letting incomplete evidence support a stronger conclusion.
Equally, missing linkage does not prove divergence, unauthorized execution or failure. It means the available evidence does not establish equivalence.
The consequence determines how important that uncertainty is. A weak linkage may be tolerable for a reversible, low-impact lookup. It may be unacceptable for a payment, customer-state change, production deployment, access modification or external communication.
This is where the issue becomes one of controllability. If the action diverges, can the system detect the difference, stop downstream reliance, reconstruct what happened and recover safely? In the order scenario, that may mean preventing payment or supplier notification until the relevant order state is verified. The authority question is also more specific than whether an approval occurred: did the authority represented by that approval remain traceably attached to the material action that executed?
The required strength of evidence should therefore reflect both the action being authorized and the consequence of material divergence.
What a decision owner should ask for
Before deployment or an increase in autonomy, a decision owner should be able to ask:
- What exactly was presented for approval?
- Which scope and properties were material to that decision?
- Can the approval be linked to the exact invocation or execution event?
- Were material parameters, target and identity preserved—or intentionally changed and re-approved?
- What did the target-system response actually establish?
- Can the resulting outcome or business state be verified?
- If the chain is incomplete, what conclusion does the evidence actually support?
The objective is not more telemetry for its own sake. It is reconstructable evidence at the points where a human or automated decision depends on the claim that the approved action and executed action were materially the same.
A diagnostic review before deployment or increased autonomy
If you are deciding whether to deploy an agent workflow or increase its autonomy, an Operational AI Risk Review can examine whether the approval, execution and outcome evidence support the decision you need to make.