AI agent approval can expire before execution: bind it to the action

A person approves an agent's plan to update a CRM record. Before the tool runs, the customer record changes or the agent selects a different target. A practitioner discussion asks what teams recheck at that last moment; another discussion argues that a generic “approved” marker says too little about the action itself. These are design prompts, not evidence that any particular vendor's approval feature is unsafe.

Define what the person approves

Show the actor, tool, target system, record identifier, exact payload or diff, expected current version and business consequence. Include the evidence used to prepare the change and its expiry. A person should be able to decide from that view without trusting the model's summary alone.

Recheck immediately before the tool call

At execution, the application compares the current record version, authorization and payload with the approved version. If any material field changed, stop and request a new decision. Enforce the check in the tool gateway or application, where every write path passes, rather than as a prompt instruction that the agent might omit. OWASP guidance recommends structured tool calls and explicit human checkpoints for high-impact actions.

Record the outcome separately

An approval receipt should not be marked “done” merely because the agent issued a call. Store the operation ID, actual response, retry or compensation result, and final state. Test a changed target, revoked permission, duplicate retry and partial failure. The reviewer needs to know what happened after approval, not just what was intended.

Adovo’s view

Approval is a narrow permission to perform one inspectable action under known conditions. It is not a vote of confidence in an agent for the rest of a workflow. Bind the permission to the state, then let changed facts invalidate it without negotiation.