TOOL APPROVAL · PAYLOAD DIGEST · RE-REVIEW
Email review: invalidate approval after edits
Approve a send_email call, let the agent edit it, and see whether the approval still describes the message that is actually sent.
Your experiment
A reviewer approves one invoice email, then the agent edits the call before it is sent. Start with a flag-only approval and a recipient edit, then bind the approval to a digest of two fields and of every argument, re-serialize without changing values and add a re-review.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, Speed changes the pace and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Teaching model, not an ADK confirmation API or a mail gateway. Digests are 32-bit FNV-1a hashes so they stay readable; a real gate should use a cryptographic hash and keep the approved payload. The reviewer in a re-review rejects a changed recipient or an added attachment and accepts a subject change. Nothing is sent; every address is fictional.
Approved, then edited
The agent drafts send_email to billing@client.example with the subject Invoice 1042, a body and one attachment, and a reviewer approves it. After approval the agent edits the call. With the opening settings What the approval is bound to is only an approved flag on the draft ID, Edit made after approval moves the recipient to the look-alike domain client-payments.example, the gate sees approved=true and the email goes out: UNREVIEWED CHANGE SENT. The reviewer approved a different message from the one that was sent.
Bind the approval to a digest
Choose A digest of every argument. The approval now stores fedee63c, a 32-bit FNV-1a hash of the canonical JSON of all four arguments. The edited call hashes to 80d2334e, so the approval is invalidated and the call is held: HELD FOR RE-REVIEW. Subject and attachment edits are caught the same way. With A digest of to and body the recipient edit is caught, 6cc03c8b becomes 753e45f7, but a changed subject or an added attachment leaves the digest unchanged and is sent unreviewed. A digest protects only the fields it covers.
Re-review decides, not the digest
A reviewer re-checks invalidated calls applies only when an approval was actually invalidated. With the full digest the reviewer sees the look-alike recipient and rejects it: BLOCKED AT RE-REVIEW after 2 reviews. With a subject edit the reviewer approves the new version and it is SENT AS REVIEWED. The digest decides when a human must look again; the human still decides whether the change is acceptable.
Formatting is not a change
Choose Same values, re-serialized: the keys are reordered and indented and every value is identical. With canonical JSON the digest is unchanged and the email is SENT AS APPROVED. Clear Digest canonical JSON and the raw text is hashed instead: 7dcca94e becomes 4a3e7c66 and the call is HELD WITHOUT A REAL CHANGE. That is safe but costs a needless review. Canonical JSON removes formatting noise without hiding real edits. The flag binding sends every edit, and No edit is always sent as approved.
Reading the run and its limits
Play, Next event, Restart, Speed and Inspection time step through the draft, the approval, the edit, the digest comparison, the send or hold and the audit across sixty inspection seconds; the table shows each argument as approved, as sent, and whether the approval covers it. FNV-1a keeps the digests short enough to read but is not collision resistant; a real gate should use a cryptographic hash such as SHA-256 and store the approved payload itself. No email is sent and every address is fictional.