Human-in-the-loop approvals for AI agents
Add human approvals to AI agent actions without loopholes: risk-based policy, payload-bound approvals, expiry, separation of duties and dual control.
By the Voidex team · Updated · 7 min read
What “human in the loop” should mean for agents
Asking a person to click “approve” is easy. Making sure that click authorizes exactly one, specific, unchanged action is the hard part. Many approval flows approve a description of an action, and the actual request sent later can differ.
Payload-bound approval — An approval that is valid only for the exact action it was granted on, identified by a cryptographic hash of the action’s tool, target, input, environment and governing policy version.
Step 1: Classify actions by risk
- Read — fetch data; usually allowed.
- Low-risk write — reversible, narrow scope; allowed in test, approval in production.
- Sensitive write — money, customer-visible changes; always one approval.
- High-impact — irreversible posting, deletion, permission changes; two approvers or denied.
Encode this as deterministic policy with conditions on inputs (for example, amount over 10,000 requires approval). Default to deny: if no rule allows an action, it does not run.
Step 2: Show reviewers what will actually happen
A reviewer needs the tool and version, the target resource, the environment, the input (with sensitive fields redacted), whether the action is reversible, which policy rule triggered the review, and which checks will run afterwards. A plain-language summary at the top prevents rubber-stamping.
Step 3: Bind the approval to the payload
Compute a binding hash over the canonical form of the action. The reviewer’s decision records the hash they saw. If the input, target, account or policy changes, the hash changes and the old approval cannot be used.
POST /api/v1/approvals/apr_…/approve
{ "bindingHash": "9f2c4e…b1", "comment": "Matches the signed order" }Step 4: Enforce separation of duties
- The requester cannot approve their own action (including through an API key they created).
- API keys and agents can never approve.
- High-impact actions require two distinct approvers.
- Approvals expire; an expired request times the action out.
Step 5: Validate again at execution time
Queues introduce delay. Right before execution, recompute the binding hash from the stored action and confirm the approval is still approved, unexpired, bound to that hash and to the currently active policy version. If anything differs, route the action back through policy instead of executing it.
How Voidex does it
Voidex implements this end to end. Policies are versioned and test cases must pass before a version is published. Approval requests carry a binding hash over the exact action; reviewers decide on that hash in the console; the worker recomputes it before calling the target system. Amending the payload or publishing a new policy supersedes the old request. High-impact tools always require two approvers as a platform guardrail. See Voidex Verify.
Frequently asked questions
- How do you stop an approved AI agent action from being changed before it runs?
- Bind the approval to a hash of the exact action — tool, target, input, environment and policy version — and recompute that hash immediately before execution. If anything changed, the approval no longer matches and the action must be reviewed again.
- Should AI agents ever approve their own actions?
- No. Approvals should come from authorized people, the requester should not approve their own request, and high-impact actions should need two different approvers.
- Which AI agent actions need human approval?
- Typically anything that moves money, changes customer-visible data in production, is irreversible, or changes permissions. Use deterministic policy rules on risk class, environment and input values to decide, rather than asking the model.