From Human Checks to Approval Binding: Making the Reviewed Action Identical to the Executed Action

🎥 The YouTube version is also available:

Approval Binding: Turning Human Checks into Accountable AI Agent Execution

Books: Runtime Al Governance Practical Guide: Dynamic Al Governance Design through Knowledge Flow, Trust Engine, and Decision Trace

When AI agents are entrusted with high-impact actions such as payments, deployments, permission changes, external messaging, and customer notifications, many systems place an approval button at the end of the workflow.

The AI makes a proposal, a person reviews it on screen, and clicks Approve. Because a human has participated, the process appears safe.

But the real question is not whether someone approved it.

Is the operation a human reviewed and approved actually the same operation the system is about to execute?

Loopjacking: Hijacking Human-in-the-Loop Approval, published in September 2026, makes this problem explicit. Let operation A be what a human understood and approved. Let operation B be a different operation that is actually executed after approval. If a product’s workflow allows approval for A to be used to execute B, it creates approval substitution.

The existence of an approval button does not itself create a security boundary. It becomes a security boundary only when approval is bound to the target, conditions, execution content, and policy revision, and is checked again immediately before execution.

This design is called Approval Binding.

approved = true binds nothing

The simplest approval implementation stores a state such as approved = true on a record. But that flag alone does not preserve what was actually approved.

After approval, any of the following may change:

• Recipient, destination URL, or target account
• Amount, quantity, or permission scope
• Tool, API, command, or arguments to be executed
• Customer information, documents, inventory, or target state referenced by the action
• Policy or delegated authority applicable at execution time
• Requesting agent, requester, or session

For example, a person may approve “send the approved notice to Customer A.” Immediately before execution, the destination could change to Customer B. Or a permission-change workflow could add further groups or roles during deployment. If the system executes merely because an approved flag is present, it may perform an action the human never approved.

This is not only an attacker problem. It can also arise through asynchronous workflows, retry queues, changes in external API state, handoffs between agents, template replacement, or configuration updates. The world at approval time is not necessarily the same as the world at execution time.

What is Approval Binding?

Approval Binding fixes the description of the operation a human understood and approved, then compares it with the current operation reconstructed at execution time. Execution is permitted only if the two are materially equivalent.

Approval is issued not for a simple state flag, but for an approved descriptor such as the following.

The descriptor is normalized and hashed, then bound to the approver, approval time, and Decision Trace ID. The hash itself is not the essential point. What matters is defining the object to be fixed so that materially important business differences cannot escape the binding.

Hashing is used to fix what the human saw

Approval Binding must treat two things separately:

1. The normalized operation the machine will execute
2. The explanation of the operation the human understood on screen

Hashing only the machine operation is insufficient if information important to the human was omitted from the display. Conversely, saving only the visible screen is insufficient if it is not bound to the internal API arguments and execution target.

At approval time, the following should be recorded in the same trace:

• The planned normalized operation and its hash
• The approval screen content shown to the human and its hash
• The evidence, inputs, and policy evaluation that led to the operation
• The approver, authority, approval time, and expiry time
• A nonce or Permit ID for one-time use

This makes it possible to explain, as one continuous chain, what was displayed, what was approved, and what was executed.

Reconstruct the operation again immediately before execution

The core of Approval Binding is not at approval time. It is immediately before execution.

An execution worker or agent must not trust an old approval flag and call an external API directly. It must first reconstruct the operation to be executed from the current inputs, target state, policy, and delegated authority. It then compares that operation with the approved descriptor.

Evidence / Input
      ↓
Normalized Operation
      ↓
Human-visible Descriptor
      ↓
Human Decision + Approval Binding
      ↓
Pre-execution Reconstruction
      ↓
Equivalence Check
      ↓
Permit → Execution → Outcome Trace

At minimum, the recheck should confirm:

• The Action / Tool is the same
• Material arguments, amount, target, and destination are the same
• The executing principal and delegated scope are the same
• The session, case, and target scope remain within the approved range
• The policy revision and evaluation result are still valid
• The approval is within its validity period and has not been used
• The correspondence between the human-visible explanation and machine operation is preserved

If even one material difference exists, execution should be rejected or re-approval should be required. A system must not automatically treat such differences as minor changes. If a change could alter the decision, it requires a new decision.

Modify is not an update to approval. It is a new Decision.

If an approver changes the amount, changes the destination, or adds a condition, the original Decision must not simply be overwritten.

A modification creates a new Decision. Policy and Boundary must be reevaluated from the new inputs, target, and conditions. A new approved descriptor and a new Approval Binding must then be issued.

This design separates approval outcomes into at least the following states:

• Approve: Issue a Permit within the approved descriptor’s scope
• Reject: Deny execution and record the reason in the Trace
• Modify: Create a child Decision and return to reevaluation and re-approval
• Timeout: Invalidate the request on expiry and escalate if necessary
• Override: Treat it as a separate Decision with explicit authority, reason, scope, and expiry

This distinction turns Human Check from an ambiguous exception process into a state transition for accountable decision-making.

In Runtime OS, Approval Binding connects the Human Gate and the Execution Boundary

The minimum Runtime OS loop can be understood as follows:

Event → Signal → Decision → Boundary → Human Gate → Execution → Trace

An AI output is a Signal. It is not, by itself, a Decision or permission to execute. The Runtime evaluates context, policy, authority, and impact to create a Decision, and escalates it to a Human Gate when required.

Approval Binding is the essential connection between that Human Gate and execution.

The Human Gate is not simply a button on the final screen. It is a semantic decision boundary that connects an AI proposal to human authority, accountability, execution rights, and traceability.

Minimum implementation: short-lived, single-use Command Permits

A practical implementation pattern is to issue a short-lived Command Permit only when Approval Binding has been satisfied.

A Permit should include at least:

• decision_id and trace_id
• Hash of the normalized operation
• Hash of the human-visible descriptor
• Target, destination, scope, and maximum execution count
• Policy revision, delegation ID, and approver
• Issued time, expiry time, and nonce
• Consumption state

Even after receiving a Permit, the Execution Boundary must not trust it blindly. It reconstructs the current operation and compares it against the Permit’s target, conditions, hash, expiry, and consumption state. Only when they match may it pass the action to the corresponding Tool or external API.

On mismatch, expiry, repeated use, or policy change, the system stops before reaching the external system.

This is the opposite of giving an agent with a token broad, general-purpose authority. It narrows what the agent can do to one limited execution for one specific Decision.

Decision Trace is not a log. It preserves the causal chain of approval.

Even with Approval Binding, an incident cannot be understood if approval, execution, and outcome are scattered across separate logs.

A Decision Trace should preserve at least the following chain:

Evidence
 → Signal
 → Policy / Boundary Evaluation
 → Decision
 → Human-visible Descriptor
 → Approval Binding
 → Command Permit
 → Pre-execution Check
 → Execution
 → Outcome

This allows audits and incident investigations to answer more than just who approved an action.

• What did the approver see before making the decision?
• Which policy and evidence were used at that time?
• Had the target or conditions changed immediately before execution?
• How many times, and within what scope, was the Permit consumed?
• Did the system stop when a mismatch occurred?

Trace is not merely an operational log. It is the Runtime OS memory that preserves the causal chain and accountability boundary through which a decision becomes a real-world action.

Failure patterns to address first

When introducing this design, prioritize the following patterns for review:

• An asynchronous worker executes based only on an approved flag
• The approval screen and API request are assembled through separate paths
• Parameter changes after approval do not trigger re-approval
• Old approvals remain usable after policy or authority changes
• Approval tokens have no target, scope, expiry, or execution-count limits
• The same approval can be used multiple times
• It is impossible to reconstruct what was approved from the execution log

There is no need to introduce sophisticated signatures for every action from day one. Start by making four controls mandatory for high-impact actions such as payments, permission grants, external sending, publishing, deletion, and production deployment:

• An approved descriptor
• Pre-execution comparison
• A short-lived Permit
• A Decision Trace

Conclusion: turn Human Check into accountable execution permission

The fact that a person clicked an approval button does not guarantee safe execution. Human Check becomes a true security boundary only when the target, conditions, execution content, and policy revision the person reviewed are bound to the operation that will actually execute.

Approval Binding provides that connection.

• Normalize and fix the approved operation
• Preserve both the human-visible explanation and the machine operation in the Trace
• Limit execution authority through short-lived, single-use Permits
• Reconstruct and compare the current operation immediately before execution
• Fail closed and require re-approval when differences, expiry, or authority changes occur

In the age of AI agents, Human Check is not a UI placed at the end of a workflow. It is Approval Binding: the mechanism that transforms an AI Signal into human-authorized, accountable execution permission and makes the process verifiable afterward.

Within a Runtime OS, it makes the Human Gate a real decision boundary and provides an implementation principle for stopping approval substitution, including attacks such as Loopjacking, before execution occurs.

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance