ai agent approvals
AI agent approval is evidence, not the whole authorization decision
Approval records a person's decision about a proposed action. Authorization determines whether that action may cross the execution boundary under current identity, policy, payload, reviewer, and expiry constraints.
- For
- Developers, platform engineers, and security reviewers designing human-in-the-loop tool execution
- Reviewed
- Jul 14, 2026
- Length
- 969 words
The plain-language distinction
A reviewer clicking Approve records consent to the operation on screen. The system still has work to do: it must decide whether the current identity, policy, action payload, review requirements, and time window permit that operation to cross the execution boundary.
Approval becomes one input to authorization. It carries no power to erase a deny decision, qualify an ineligible reviewer, cover changed arguments, or serve as a reusable credential for a later call.
Four layers that are easy to collapse
- Identity establishes who or what is making the request and who is reviewing it.
- Policy evaluates the proposed action and sourced policy context to return allow, deny, or require approval.
- Approval captures a decision by an eligible person about the reviewed payload.
- Execution authorization proves that this action may enter a particular executor path now, under the final validated state.
Where an approval-only design breaks
Imagine a reviewer approves an email to one recipient, but the queued arguments are replaced before dispatch. Or the active policy changes to deny that category of send. Or the approval is replayed against a second execution attempt. The original click may be authentic, yet none of these later operations is the action the reviewer considered.
Handling those cases requires a stable representation of the proposed action, a binding between that representation and the review, and a controlled executor that rejects missing, expired, replayed, or mismatched authority.
How the layers meet in ActionProxy's canonical paths
- A supported adapter creates a canonical action request with sourced policy context; ordinary request metadata cannot replace trusted transport or server fields on those paths.
- Deterministic YAML policy returns
allow,deny, orrequire_approval. - For a pending review, ActionProxy stores the original action evidence and an approval authorization containing action, input, decision, policy, reviewer requirements, nonce, and expiry bindings.
- An eligible reviewer decides on the original payload or, in a supported single-reviewer flow, edited input.
- The service validates the binding and re-evaluates the active policy before final authorization.
- A short-lived, one-use execution authorization or signed external grant controls the transition into dispatch, and the lifecycle records the attempt and reported outcome.
Questions for an architecture review
- What exact bytes or normalized fields does the reviewer approve?
- Which identity and policy version are included in that decision?
- Does changing an argument invalidate the prior review or trigger policy evaluation again?
- Can the authorization be consumed twice, by another executor, or after expiry?
- Does dispatch reload current state, or trust a stale queue message?
- How is an unknown post-dispatch outcome represented without an automatic duplicate attempt?
Policy still matters after a human says yes
In ActionProxy, deny is terminal. A human decision is requested only when policy returns require_approval; there is no approval route that overrides a deny result. Before final authorization, the service checks the stored binding and evaluates the active policy again, including any supported edit.
That separation makes selective review possible. Policy can allow a defined operation, deny another, and reserve require_approval for calls where a person should decide. The risk-based human approval guide shows how to draw those lanes without treating an approver as an exception to policy.
Placement changes the size of the boundary
A framework-level pause can be a sensible choice when one runtime owns the whole action lifecycle. An external checkpoint becomes useful when multiple adapters, agents, or applications should share policy and execution control. Neither placement removes the need to bind the reviewed action to dispatch.
Compare those shapes in framework HITL versus an external approval gateway, or start with the full AI agent approval gateway architecture.
Common questions
Questions developers ask
Is human approval the same as authorization?
No. The review supplies a person's decision; authorization checks whether that decision and the current request still satisfy identity, policy, payload, reviewer, and expiry constraints at dispatch.
Why bind an approval to the tool-call arguments?
The reviewer approved one recipient, amount, resource, or command. Action and input hashes let the executor reject a substituted payload rather than extend that decision to a merely similar call.
What happens when policy changes after approval?
Finalization evaluates the active policy again. If it now returns deny, the action stops; the earlier human decision cannot reopen an approval path.
Can execution authorization be reused?
No. The local authority is short-lived, process-local, and consumed once. External runners receive an expiring one-use grant, while provider idempotency and reconciliation remain separate responsibilities.
