Approval Model
Exact-action binding, expiry rules, and attribution.
What is approval binding?
Approval binding 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. Any mismatch denies execution.
"Digest comparison catches 100% of post-approval argument changes."
Approval binding is the mechanism that makes governance enforceable. Without it, policy is advisory.
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 every outcome.
Core constraints
"Per-action approval is required—no exceptions."
An action cannot execute without an approved state tied to exact arguments.
An approval becomes invalid if arguments change after approval is granted.
An approval becomes invalid if session context changes after approval is granted.
An approval becomes invalid if it expires.
Approval lifecycle
Each approval transitions through discrete states with explicit transition rules.
Proposed state
An action enters the proposed state when the agent defines a tool invocation.
Pending state
An action enters the pending state when [control plane] computes the [digest] and awaits human review.
Approved state
An action enters the approved state when human reviews exact arguments and grants approval.
An approved action stores the [digest], scope, actor, and expiry.
Executed state
An action enters the executed state when [control plane] verifies [digest] match and allows execution.
An executed action creates an immutable [event store] record.
Denied state
An action enters the denied state when [digest] mismatch is detected at execution time.
A denied action creates an immutable [event store] record with denial reason.
Invalidation conditions
"Invalidation is automatic—mismatches trigger denial without human intervention."
| Condition | Result |
|---|---|
| [Digest] mismatch | Denied (100%) |
| Scope mismatch | Denied (100%) |
| Expiry reached | Denied (100%) |
| Revoked | Blocked (100%) |
Digest mechanism
"SHA-256 provides 2^256 theoretical collision possibilities."
The [digest] is computed from normalized arguments—identical arguments produce identical hashes regardless of formatting differences.
Normalization ensures "file: /path" and "file:/path" produce the same [digest].
Failure modes
"Approval binding cannot compensate for over-permissive tool definitions."
If a tool exposes broader capabilities than intended, [approval binding] cannot restrict its scope. Tool definitions must match intended 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.
Guarantees
"These guarantees hold only when constraints are enforced."
[Digest] mismatch causes denial.
Expired approval causes denial.
Revoked approval causes denial.
[Event provenance] is preserved for every action.
Named concepts
- [Approval binding] binds approvals to exact normalized arguments
- [Digest] is a SHA-256 hash of normalized arguments
- [Argument-bound] prevents approval drift
- [Control plane] evaluates policy and enforces approvals
- [Event store] records actor, action, approval, outcome
- [Policy] determines approval requirements
See also
- How It Works — execution flow and [control plane]
- Architecture — [control plane] authority model
- Product Claims — [bounded claim] structure
- Constraints — [bounded claim] design rationale
- Security — threat model and controls