How to Test Human Approval in an AI Agent Workflow
Prove that approvals bind to an exact action, stale decisions fail closed, and side effects cannot happen early.
Short answer
Test approval as a security and concurrency boundary. No protected mutation should occur before approval; the decision must bind to the exact actor, target, payload, and version reviewed; stale, replayed, denied, or changed requests must fail closed and remain auditable.
Key takeaways
- Approval must bind to immutable action evidence.
- Changing the payload invalidates the prior decision.
- Timeouts and retries must not duplicate the protected action.
Signs this is the problem
Start by confirming the symptom before changing prompts, models, or infrastructure.
- An approval references only a conversation or task ID.
- The agent can change arguments after review.
- A timed-out mutation can be retried without checking remote state.
Step-by-step approach
- 1
Define protected actions
List mutations, disclosures, spend, and irreversible operations that require a person.
- 2
Bind the proposal
Hash or version actor, tenant, target, payload, evidence, and expiry shown to the reviewer.
- 3
Test negative paths
Exercise denial, expiry, replay, changed payload, changed permissions, concurrent decisions, and lost responses.
- 4
Verify the mutation
Record the authorized operation before dispatch and independently confirm the final state afterward.
What to measure
| Metric | What it measures | How to use it |
|---|---|---|
| Pre-approval mutation count | Protected side effects occurring before a valid decision. | The acceptable value is zero. |
| Binding integrity | Approved executions whose actor, target, payload, and version exactly match review. | Reject any mismatch rather than asking the model to reconcile it. |
| Duplicate-effect rate | Repeated mutations caused by retries or replay. | Use idempotency and read-after-timeout evidence to drive this to zero. |
Common mistakes
- Treating a chat message saying yes as durable authorization.
- Reusing approval after the target state changes.
- Logging approval without verifying the resulting side effect.
Practical checklist
- Define protected actions: List mutations, disclosures, spend, and irreversible operations that require a person.
- Bind the proposal: Hash or version actor, tenant, target, payload, evidence, and expiry shown to the reviewer.
- Test negative paths: Exercise denial, expiry, replay, changed payload, changed permissions, concurrent decisions, and lost responses.
- Verify the mutation: Record the authorized operation before dispatch and independently confirm the final state afterward.
Frequently asked questions
What should I do first?
List mutations, disclosures, spend, and irreversible operations that require a person
How should the result be measured?
Protected side effects occurring before a valid decision. The acceptable value is zero.
When is the change ready to ship?
Ship only after the protected cases pass, the primary metric clears its agreed boundary, and the team reviews the remaining failure modes instead of relying on one aggregate score.