Verify Agent Approval Records

A visible approval button does not prove that the later tool call is the one a person reviewed. Long-running agents can revise arguments after the prompt. Retries can reuse a decision. A sound receipt binds one human decision to one effect and lets the executor verify it without trusting the model.

Start with an action envelope made by the controller, not free-form model text. Include the authenticated requester, tenant, tool ID, resource ID, normalized arguments, requested time, and policy version. Hide secrets from the display, but keep their safe reference or version in the bound data. The reviewer must see enough of the final effect to make a decision.

Receipt fields

Verify before execution

Use a canonical serialization for the digest. Sort object fields, normalize numbers, and reject unknown fields before computing it. Otherwise two components can hash different representations of the same input. Store the approval record in a service the model cannot edit. The executor should consume the receipt atomically before calling a high-impact tool. If the downstream call fails, do not silently replay it with a new amount or target.

OWASP's MCP security guidance emphasizes authorization at the server boundary. Apply the same rule to approval: the server verifies the receipt, caller, and current authorization immediately before execution. The receipt alone cannot grant a role the caller no longer has.

Test with a disposable action in an owned lab. Approve one request, then change its recipient, amount, tenant, or tool name one field at a time. Every altered request must fail. Check expiry, denial, duplicate delivery, and a revoked user role. Keep an audit record that identifies the request and outcome but not a raw credential. A complete chain has separate events for proposal, decision, execution, and any failure.