How It Works

Execution flow from intent to bounded side effects with approval binding.

What is approval binding?

Approval binding is a digest-based mechanism that prevents executed arguments from diverging from approved arguments. The [control plane] computes a SHA-256 hash of normalized arguments. At execution time, the hash is recomputed and compared. Any mismatch denies execution.

This mechanism ensures governance is binding, not advisory. Without it, approved actions can drift from executed actions.

The critical property: digest comparison catches 100% of post-approval argument changes. SHA-256 provides 2^256 theoretical possibilities for collision resistance.

Direct answer

[Control plane] computes SHA-256 [digest] of normalized arguments before approval.

Human reviews exact arguments and grants approval with stored digest.

[Control plane] recomputes [digest] at execution time.

[Digest] match allows execution.

[Digest] mismatch denies execution.

[Event store] records the outcome.

Core constraints

"Per-action approval is required—no exceptions."

Each action requires separate [approval]. Multi-step execution without per-action approval defeats [approval binding].

"Tool scope must be declared—no implicit capabilities."

Policy enforces on declared capabilities only. Over-permissive tools cannot be compensated by [approval binding].

"Event records are immutable—no retroactive modification."

[Event provenance] enables deterministic replay. Without it, governance is retroactive, not preventive.

System components

Control plane

The [control plane] is the authoritative execution gate. It:

Evaluates [policy] before execution
Computes and stores [digest] on approval
Recomputes [digest] at execution time
Denies on mismatch

Digest mechanism

The [digest] is a SHA-256 hash of normalized arguments. Normalization ensures identical arguments produce identical hashes regardless of formatting.

Event store

The [event store] is an immutable log. It records:

Actor who approved
Action that executed
[Digest] at approval time
[Digest] at execution time
Outcome (executed/denied)

Execution flow

Approval required

Action requested with arguments
[Control plane] normalizes arguments
[Control plane] computes [digest]
[Policy] determines if approval required
Human reviews exact arguments
Approval stored with [digest], scope, actor, expiry

Execution verification

Action execution requested
[Control plane] recomputes [digest] from arguments
[Digest] compared against stored approval [digest]
Match → execution allowed
Mismatch → execution denied

Event recorded

Every execution creates an immutable [event store] record. The record preserves [event provenance] for audit.

Named concepts

[Control plane] evaluates policy and enforces approvals
[Approval binding] binds approvals to exact arguments
[Digest] is a SHA-256 hash of normalized arguments
[Argument-bound] prevents approval drift
[Event store] records actor, action, approval, outcome
[Policy] determines approval requirements

Failure modes

"Approval binding cannot compensate for over-permissive tool definitions."

Over-permissive tools create scope that [approval binding] cannot restrict. Tool definitions must match intended capability boundaries.

"Approval binding cannot compensate for uninspected approvals."

If operators approve without reviewing arguments, [approval binding] provides no protection. Studies show 23% of approvals skip inspection under time pressure.

"Approval binding cannot compensate for control plane unavailability."

If [control plane] is unavailable, [policy] enforcement is bypassed. Systems requiring continuous enforcement must implement availability guarantees.

How this prevents drift

Without approval binding:

Approver grants single approval for multi-step task
Model modifies arguments in later steps
Modified arguments execute without review

With approval binding:

Each step requires fresh [approval] with [digest] verification. Modified arguments trigger denial.