What must an AI agent record when a human approves a destructive action?

## The record is a control, not a log line Teams usually treat approval logging as compliance paperwork bolted on after the gate works. That gets it backwards. The record is what makes the approval *mean* something: it pins a specific human to a specific action at a specific moment, and it is the artifact you execute against. A row that says `approved: true, at: 14:32` proves nothing — approved what, by whom, and is the thing that ran the thing they saw? ## Fields that earn their place - **Approver identity, from the identity provider.** The authenticated session of the person who clicked. Never a name supplied by the model, parsed from free text, or inherited from the agent's service account. If the agent can influence who the log says approved, the log is fiction. - **The literal payload.** Tool name and the exact arguments, stored verbatim — not the model's prose summary. A screen reading "issue the customer refund" gives the human nothing to verify; a screen reading `issue_refund(order=A-8812, amount_usd=500.00)` does. - **A hash of what was approved.** Hash the argument payload, and for plan-level approvals the plan document too. Comparing the hash at execution time turns "we think it was the same call" into a check. - **Timestamp and expiry.** When the request was raised, when the decision landed, when the approval stops being valid. - **The policy that fired.** Which rule demanded the gate, and its version. Without it you cannot tell later whether a gap was a policy bug or an operator decision. - **Decision and edits.** Approve, reject, or approve-with-modification, plus the modified payload and any free-text rationale. Rationale is often the only place the *why* survives. - **Correlation.** Run id, trace id, conversation id, tenant. The record must join to the agent's trajectory, or investigating an incident means guessing. ## Binding: approval must attach to a payload, not a vibe The defect that turns a working gate into theatre is re-generation. The flow that fails looks like: model proposes a call, the human approves, the harness tells the model "the human approved, go ahead", and the model emits a *new* tool call. Nothing constrains that new call to match the old one. Sampling variance, a re-read of a poisoned observation, or an ambiguous instruction is enough for the amount, the account or the environment to shift. The human approved a $500 refund; a $50,000 one executes; the record says "approved". The fix is structural. The pending call is stored at gate time. On resume, the executor takes the stored payload, verifies the hash, re-evaluates policy against it, checks preconditions, and executes it directly. The model is not consulted about the approved action at all — it is only resumed with the *result*. If the approver edited the arguments, the edited payload is what gets stored, hashed and re-checked; edits are a first-class path, not a bypass. ## Four eyes, and who may approve For high-consequence actions, identity is not enough — you need separation of duties. The approver must not be the person who initiated the run, and above a threshold you want two distinct approvers. A treasury agent releasing a wire over $50,000 under a four-eyes rule needs two authenticated humans whose sessions are independent, and the record must show both. This is also where entitlement checks belong. Being logged in is not the same as being *allowed* to approve production DDL or a chargeback reversal. Check the approver's role against the action class, and record the entitlement that permitted it, so a later privilege change does not erase the reasoning. ## Making the record trustworthy A few properties separate an audit trail from a text file: append-only or otherwise tamper-evident storage; the agent's own credentials having no write access to it; retention aligned with the regulatory shape of the action, which for payments is usually years; and redaction discipline, because argument payloads carry account numbers and personal data. Emitting the record as structured events on the same tracing backbone as the agent's spans is what makes it queryable — you want to ask "show every gated production DDL last quarter, its approver, and whether it executed" and get an answer in one query. ## What interviewers listen for The distinguishing answer connects the record to enforcement rather than reciting fields. Say that you store the payload and execute *that*, that identity comes from the IdP, that the human is shown the real arguments and not a paraphrase, and that a rejected or expired approval leaves a record too — the absence of an execution is itself evidence. Candidates who describe only "we log approvals to a table" have built the paperwork without the control.