What must a human approval prompt show before an agent's irreversible action?

## Why approval is the layer that survives Every prompt-level mitigation shares one dependency: the model has to cooperate. A human approval gate does not. It is enforced in code before the side effect fires, so it holds whether or not the model was persuaded by something it read. That makes it the most valuable single control in this taxonomy — and it makes the integrity of the approval *surface* the thing worth interrogating, because a gate whose display is attacker-influenced fails silently. ## The failure that makes this a senior question Picture a recruiting screener that reads candidate PDFs and can advance a candidate to interview. A résumé carries an invisible line instructing the reader to advance this candidate. The agent complies and asks for confirmation, and the confirmation reads: "Advance the strongest candidate to the interview stage?" The recruiter approves. The gate was present, the human was in the loop, and nothing was actually reviewed — because the sentence the recruiter read was generated by the same model the attacker had already influenced. The fix is structural. The approval UI must be rendered by the harness from the serialized call it is about to execute, never from model prose. Concretely: - **The tool and target.** Which capability, and which specific record, file, recipient or endpoint. Identifiers resolved to human-readable names, but the identifier shown too. - **Every argument, verbatim.** Not a paraphrase, not a truncation that hides a suffix. For edits and deletions, a diff or the exact rows affected. - **Provenance.** Which document, retrieved chunk or tool result the agent was reading when it proposed this. An action traceable to an uploaded PDF rather than to the user's own request is the single most useful signal a reviewer gets. - **Blast radius.** Whether the action is reversible, and how many entities it touches. "Advance 1 candidate" and "advance 340 candidates" must not look alike. - **Nothing rendered as markup.** The approval surface is itself an output sink; argument values must be escaped so a crafted value cannot restyle or hide part of the dialog. ## Where the gate is placed At the side-effect boundary, in the harness, not in the model's judgment. Two placements are wrong in ways that recur. Asking the model to decide whether an action is risky and to request approval accordingly puts the gate back inside the compromised component. The classification must be a property of the tool, declared in code. Gating everything — reads included — is the other failure. Approval fatigue is not a UX quibble; it is the mechanism by which the control degrades to a click-through. Gate writes, external sends, deletions, spends and state transitions; let reads run. Grouping a batch into one approval is fine only if the group is shown item by item. ## What approval does not solve It does not stop an agent from reading something it should not, and it does not stop information leaving through channels that are not gated. A model that has been persuaded can encode data into an argument of an action a human will plausibly approve. So the gate is one layer: it constrains side effects, while keeping untrusted free text away from the deciding component and restricting what the agent can invoke at all constrain the rest. It also does not survive a poor human factor. If the reviewer cannot tell what "good" looks like — because the argument is an opaque identifier, or the diff is 200 lines — the gate is decorative. Design the surface so the decision is answerable in a few seconds. ## Operating it Record the approval: who approved, the exact serialized call, the provenance, and the time. That record is what makes an incident reconstructable and what tells you whether reviewers are approving in one second or ten. Rising approval rates with falling review time is the measurable signature of fatigue, and it is a reason to narrow what gets gated rather than to add more gates. ## Interview framing Lead with the sentence that shows you understand the threat: under injection the model's description of the action is attacker-controlled, so the approval must render the resolved call from the harness. Then add provenance, blast radius and the fatigue tradeoff. Candidates who answer only "add a human in the loop" have named the layer without knowing what makes it work.