When an agent gets approval, what exactly is approved?

An agent asks to send a report. The approval card lists one recipient, but a resumed tool call adds a blind-copy recipient. If the system records only that “the run was approved,” the action may differ from what the person saw.

Approval needs to identify the action that will execute. The person also needs a clear view of that same action, built from structured data rather than an agent-written summary.

A concrete mismatch

This is a schematic design test, not a reported incident. A user asks an agent to email a report. The approval screen shows To: security@example.com, Cc: none, Bcc: none, and Attachment: report.pdf. After a pause, the pending request adds a Bcc recipient or replaces the file. The original approval cannot authorize those changed details. The system should stop before sending, show the changed action, and ask for a new approval.

What the paper measured

An October 15 paper, “Approve What, Exactly?”, calls tying approval to the executable action effect binding and building the approval view from that same action trusted rendering. In eight runtime rows with measurable effect binding, the authors report three passed, one partial, and four failed. They reproduced post-approval argument substitution in tested paths for LangGraph 1.2.15, Agno 3.1.3, and Pydantic AI 2.56.0. For CrewAI 1.15.27, the paper separately reports a low-severity binding gap in a hook-based path where a later hook can change arguments approved by an earlier hook. These are results for pinned versions and paths, not every deployment. Tests against third-party implementations ran locally with placeholder data and mocked resources. No production third-party system, real account, credential, or person was involved; there were no human participants and the authors did not contact maintainers. The paper makes no novelty claim for action binding and notes that the Agno substitution class had already been publicly reported.

Existing design examples

Google's Agent Payments Protocol (AP2) v0.2 specifies a consent surface and cryptographically linked checkout and payment mandates. Microsoft's Agent Governance Toolkit ADR 0030 describes recomputing an action digest at execution. These are design examples within their stated scopes. Their existence does not establish that any particular agent integration binds every action correctly.

Make approval refer to an action

• Define the full action record: acting identity, operation, target, every effect-changing argument, and relevant policy version. Normalize values with a documented, versioned format.
• Render every consequential value from that record. Show all recipients, paths, amounts, attachments, and other fields that can change the result. Make hidden or optional values visible.
• When approval is granted, store the exact action record with its digest, approver, expiry, and a one-time identifier. Do not store only a session-level approved flag.
• Immediately before execution, rebuild the action record from the request and compare it with the approved record. Execute only the stored approved action when they match.
• On any mismatch, execute nothing. Invalidate the old approval, show the changed fields, and require the user to review and approve the new action. Never carry consent forward to the changed request.
• Test changes to recipients, files, amounts, omitted versus default fields, and target resources during pause and resume. Also test retries, duplicate requests, replay, and rollback. Verify that every mismatch produces no side effect.

Binding approval to an action does not show that the action is harmless or that the person understood every consequence. Canonicalization bugs, misleading displays, alternate execution paths, and weak policy can still defeat the intended control. Treat action binding as one part of an authorization design, with least privilege, independent policy checks, and auditable execution.