What Exactly Did the Human Approve?

An approval button is easy to build. Useful evidence of authority is much harder.

When an agent asks, “May I continue?”, the prompt can hide the very terms that make the decision consequential: which action will happen, which party will receive it, what limit applies, how long the decision remains valid, and whether the executable request still matches what the person saw. A positive click proves little if the proposal can change afterward.

Evidence boundary: This article is part of Independent Product R&D and documents a Target Reference Architecture. It describes intended controls, not measured performance or operational assurance.

The design objective is precise: turn a human decision into bounded authority that deterministic code can evaluate. The agent may assemble and explain a proposal, but it does not decide whether the proposal is authorized.

Approval is a chain of questions

Treating “the user authenticated” and “the transaction is authorized” as equivalent collapses several different questions:

1. Identity: Which human or organizational principal is acting?
2. Presentation: Which terms were shown in an understandable form?
3. Authorization: Which action and constraints did the person accept?
4. Binding: Does the executable request still match those accepted terms?
5. Freshness: Is the decision still valid for this request and this time window?

An authentication ceremony can help answer the first and fifth questions. It does not automatically answer the middle three. The Web Authentication specification describes challenge, origin, relying-party scope, user presence, and user verification properties. The application still owns the transaction presentation and the meaning attached to the resulting assertion.

That separation changes the implementation. An approval service should not receive a sentence such as “buy the items we discussed.” It should receive a canonical, typed proposal whose decision-relevant fields have already been identified.

Define the authority before asking for it

A transaction authorization needs enough structure to distinguish one permitted action from a nearby but different action. The exact fields vary by domain, but the control plane should be able to answer these questions without asking the model to interpret prose again:

• Who is the human principal behind the decision?
• Which agent proposed the action?
• What action class is requested?
• What target, counterparty, or resource will receive the action?
• Which amount, quantity, category, or other constraint applies?
• Which policy version evaluated the proposal?
• When does the authority begin and expire?
• Which unique request identity connects the proposal to later evidence?

OAuth Rich Authorization Requests offers a useful standards example: structured authorization details can express specific rights more clearly than a broad scope string. A target architecture can adopt that principle without depending on one protocol or copying a private data model.

Standards references last reviewed: 17 September 2026.

Unknown fields should not be silently discarded. If a newly introduced constraint could affect the decision but the deterministic verifier cannot evaluate it, the safe result is to stop and request clarification or a new policy decision.

Exact approval and bounded delegation are different products

Two authority modes need different language and evidence.

Exact transaction approval is human-present. The person sees a closed proposal and accepts those terms. Any material change—recipient, action, amount, quantity, timing, or cancellation condition—creates a new proposal that needs a new decision.

Bounded delegated authority is human-not-present. The person approves constraints in advance, such as an allowed category, a cumulative budget, eligible destinations, a validity window, and conditions that trigger step-up review. The later transaction is authorized only if deterministic evaluation proves that it fits inside every active bound.

Calling both modes “human approved” is misleading. In the second mode, the person approved the boundary, not the later transaction line by line. The audit record should say which mode applied.

Transaction-bound approval

Conceptual target design. This diagram communicates intended trust boundaries and control flows; it is not a deployment topology or claim of production operation.

The important property is not the choice of digest algorithm or object format. It is that the summary a person understands and the request the executor receives are derived from the same decision-relevant terms. If the UI rounds a number, omits a recurring condition, or uses a nickname that can resolve to several destinations, the cryptographic binding can be technically correct while the consent is still unclear.

Worked example

Consider a fictional office-supplies request. All values in this example are illustrative.

An agent proposes purchasing twelve replacement headsets from an approved supplier with a ceiling of USD 1,800. The proposal expires after a short review window and includes a unique request identity. The approval view shows the item, quantity, supplier, total ceiling, delivery destination, and expiration condition.

After approval, inventory changes. The agent finds a substitute model from the same supplier for USD 1,760. That is not automatically the same transaction. If the original authority covered a specific item, substitution requires a new decision. If a prior delegation explicitly allowed equivalent headsets from that supplier below the ceiling, deterministic policy may authorize the changed proposal under the delegation instead. The evidence must record which path applied.

Now consider a more subtle alteration: the item and amount remain the same, but the delivery destination changes. A verifier that binds only the amount will accept the wrong action. A verifier that binds all material terms will reject the mismatch before execution.

This example suggests a practical design rule: build the authorization representation from the set of fields whose alteration would matter to the principal, not from the subset that happens to be convenient for the current API.

Deterministic verification at the commit edge

Immediately before authority is consumed, the verifier should evaluate a stable set of facts:

• the approval or delegation refers to the current principal and request;
• the action type and target match the executable proposal;
• every amount, quantity, category, and cumulative limit remains satisfied;
• the decision and underlying policy are still within their validity windows;
• required separation-of-duties rules still hold;
• the proposal has not been superseded, cancelled, or already consumed;
• the executor audience and workload are permitted to receive the grant.

The model may explain why it believes those checks will pass. Only deterministic controls should produce the authorization result. That keeps persuasive language, prompt injection, and model variability outside the final decision boundary.

The verifier should also return a reasoned outcome rather than a bare boolean. “Approval expired,” “supplier differs,” and “cumulative budget unavailable” lead to different recovery paths. A reason code, policy version, and request identity become part of the evidence chain.

Failure modes

Evidence worth retaining

An inspectable decision record should link the original instruction, normalized proposal, human-readable presentation, policy version, approval or delegation proof, verification result, authorization consumption, and eventual outcome. Sensitive credentials do not belong in that record. Integrity links should make later substitution detectable, while retention and access policy should limit who can inspect the details.

“Tamper-evident” is the accurate design goal. Its strength depends on key custody, write controls, verification, and retention arrangements that must be assessed separately.

Implementation checklist

• Define exact approval and bounded delegation as separate authority modes.
• Identify every decision-relevant field for each action class.
• Generate the human-readable view and executable proposal from the same canonical terms.
• Bind principal, action, target, constraints, validity, policy version, and request identity.
• Reject unknown or unevaluable constraints.
• Re-check policy and freshness when authority is consumed.
• Return explicit allow, deny, clarification, and step-up reasons.
• Keep model output outside proof creation and final verification.
• Preserve a linked decision record without storing downstream credentials.
• Test substitution, expiration, replay, concurrency, and cancellation cases.

The next article, One Authorization, One Commit Boundary, follows this approval to the point where it is consumed and handed to execution. For the broader design, read the Secure Agent Transaction Infrastructure project and the full Target Reference Architecture case study. To discuss the private implementation separately from this public reference design, request repository access.