Learning objectives
By the end of this module, you should be able to:
- Classify read, change and high-consequence actions by risk.
- Bind an approval to the exact proposed action instead of a vague permission.
- Resume only after approval is current and the request is revalidated.
Approval is not a polite prompt
Writing 'ask the user before deleting' in a system prompt is helpful instruction, but it is not a hard execution boundary. The application must refuse to execute protected actions until an approval record exists.
Risk should determine the gate
Read-only inspection can often proceed automatically. Changes such as restart or scale may require approval depending on environment. Destructive, financial or security-sensitive actions should require stronger controls or may be prohibited entirely.
Approve the exact action
An approval should identify tool, target, arguments, environment, requester and expiry. 'Approved to fix production' is too broad. If arguments change after approval, the old approval should not silently carry over.
Revalidate before execution
State can change while a human is deciding. Re-check authorization, policy and current target state immediately before execution so an old approval cannot be replayed against a changed request.
Worked examples
Approval card
Action: restart_service
Target: prod-web-03 / nginx
Reason: failed health checks
Risk: brief service interruption
Expires: 10 minutes
[APPROVE] [REJECT]
- The person can see the exact side effect.
- The approval is narrow enough to audit and expire.
Risk tiers
get_logs → READ → usually automatic
restart_service → CHANGE → approval by policy
delete_database → HIGH → strong approval or prohibited
- Risk is based on side effects and business consequence.
- Environment and identity can raise or lower the required control.
Try it · core lab · account-free
Gate a side-effecting action with exact approval
Goal: Allow a read automatically, pause a restart for approval, reject changed arguments, and refuse an explicitly denied destructive action.
Before you start
- Python 3 only. All actions are simulated; the lab performs no real service restart or deletion.
STEP 1Run the approval lab
python3 public/labs/agentic-ai/08_human_approval.py
STEP 2Inspect the approval fingerprint
The approval is bound to tool, target and arguments rather than a vague task description.
STEP 3Watch changed arguments fail
After approval, the lab changes the target and proves the old approval cannot authorize the new request.
Verify
- Read-only activity proceeds without a change approval.
- The restart executes only with matching, unexpired approval.
- A modified or rejected request does not execute.
Expected outcome
- The model can propose an action but cannot grant itself authority.
- Approval and execution are separate auditable events.
Break / fix · diagnose
- If changed arguments still execute, verify that the approval fingerprint covers all consequential fields.
- If rejected actions execute, check the policy gate before the simulated tool handler.
Production viewHuman approval is strongest when it is implemented as durable application state with identity, exact parameters, expiry and audit—not as conversational wording alone.
Avoid these traps
Common mistakes
- Treating 'please ask first' in a prompt as the approval mechanism.
- Approving a broad goal instead of the exact action and arguments.
- Reusing an approval after the target or parameters change.
- Showing a human too little context to understand the consequence.
Knowledge check
Explain the control decision, not just the vocabulary.
Open every answer only after committing to your own answer. Opening all four answers records knowledge-check activity in My Learning.
1What actually prevents a protected tool from running before approval?
Application-enforced execution gating — a prompt can request good behavior, but the runtime must refuse the action without valid approval.
2What should happen if tool arguments change after approval?
Require a new approval — the original approval was for a different action.
3Why revalidate immediately before execution?
Authorization, policy or target state may have changed while approval was pending.
4Should every read-only tool always require human approval?
Not necessarily — approval should be risk-based; low-risk reads can often run automatically under normal authorization and policy.