Checklist
Approve the exact action that will actually run
Approved is meaningless until you say what was approved.
When it fits
- An AI agent prepares an edit, send or other consequential action for human approval.
When to avoid it
- A confirmation button without backend enforcement is not a security boundary. Approval also does not prove that the proposed content is factually correct.
Checklist
- Present the exact target and significant action details before approval.
- Enforce that execution uses the approved payload and current permissions.
- Invalidate stale approval when significant details or applicable preconditions change.
Why it matters
Show the meaningful payload: target, scope, changed values and relevant consequences. Bind the approval to that payload at execution. If the proposal changes materially, obtain fresh approval instead of reusing permission granted for a different action.
An example
A reviewer approves a message to three named recipients. Adding a fourth recipient produces a new proposal, not a silent extension of the old approval.
Check your result
A test that changes a significant field after approval is blocked or requests approval again.
Keep this limit in mind
- A confirmation button without backend enforcement is not a security boundary. Approval also does not prove that the proposed content is factually correct.
Connected ideas
Useful withMake the write conditional on the version you reviewed
Evidence and sources
Supports
OWASP transaction authorization requires the user to identify significant transaction data and advocates server-side verification of that data.
AI action approval must be bound to the executed payload; a generic approval screen does not establish that binding.
Transaction Authorization Cheat Sheet · Sections 1.1 and 2.3