Guided security lab

Human Approval

A guided exercise on when a human approval is informed, action-specific, current, authenticated and safely bound: exact-action binding, reviewer evidence, stale approvals after material change, model-authored approval claims and fixed batch review.

Conceptual simulationAdvanced15 minutes2026-09-26

Conceptual simulation

This exercise uses authored, deterministic examples with fictional names and neutral synthetic content. It calls no tools, APIs, agents or models, and it does not predict how any real model or system behaves.

Step 3 of 63/6

Learning objectives

Distinguish human approval from deterministic authorization and capability.
Identify the authoritative application-side evidence needed for an informed review.
Bind approval to the fully resolved exact action rather than a generic intent or tool name.
Recognize model-authored approval claims and rationales as variable content, not authority.
Detect stale approval after a material parameter or state change and require re-evaluation and re-approval.
Evaluate reviewer identity, eligibility and separation of duties from application policy.
Understand when an enumerated fixed batch can be reviewed safely and why blanket future-chain approval is not equivalent.
Keep approved, authorized, executed, succeeded, failed, cancelled, timed out and unobserved distinct.

Prerequisites

Agent Authorization lab (recommended)
Tool-Chain Analysis lab (recommended)

Choose a scenario

Each fictional scenario shows what the model proposes and, separately, the action record, policy, reviewer and approval events the application records. You judge whether a recorded approval is valid for the exact action.

Exact refund approvalThe agent proposes a refund of 40 synthetic credits for order O-204 to the verified original payment method. Deterministic authorization already permits this exact refund; policy additionally requires human approval for refunds above 25 credits.Generic tool confirmationThe agent proposes a routine internal status update. The review dialog only asks "Allow send_mail?" and shows a model-written rationale, although the proposed action record contains recipient, attachment, data class and side effects.Material change after approvalA reviewer approved a refund of 40 synthetic credits for order O-305 to the verified original payment method, bound to action version v1. Before execution, the proposed amount changes to 60 credits in version v2.Model-authored approval claimThe agent proposes changing the status of a fictional account workflow. Its proposal includes a note that the user already approved, but the approval store has no authenticated human decision for this exact action. The user is signed in.Enumerated fixed batch approvalThe agent proposes archiving exactly three closed synthetic draft reports, R-17, R-18 and R-19. Policy requires approval for archival batches larger than two. The request shows the full list and a preview generated from the bound action record.

Approval path and trust flow

Deterministic policy decides whether review is required, the model proposes an action with a rationale, the application resolves the exact action record and stores authenticated decisions. The proposal and rationale stay variable content.

Deterministic approval policySystem component->
ModelSystem component->
Proposal and rationaleVariable content->
Exact action recordSystem component->
Authenticated approval storeSystem component->
Execution-time enforcement (separate)System component

Model-visible proposal and rationale

What the model reads or writes. It is not approval evidence.

User request
Please refund order O-204, the item arrived damaged.
Model rationale
Damage report matches the order; a full refund of 40 credits seems appropriate.

Application-recorded approval evidence

Task and run IDs, principal, acting agent, exact action version, policy and risk tier, bound fields, material state, reviewer identity and eligibility, approval events and execution state, recorded outside model text.

Task and run: task t-204, run r-204a; initiating principal support-user-ana; acting agent refund-agent-2
Exact action: act-204 v1: refund(order O-204, amount 40, destination verified original payment method)
Policy and risk tier: approval-policy v7: refunds above 25 credits need review; tier R2; deterministic authorization for act-204 v1: permitted
Material state: O-204 delivered, no prior refund, refund window open
Reviewer and eligibility: reviewer lead-omar, authenticated; eligible for tier R2; not the initiating principal
Approval event: approved act-204 v1 at 2026-09-26 10:14 UTC with the bound fields shown; no field changed since
Execution state: Pending; not executed