Why does per-step verification against an agent's recorded plan confirm a goal-substitution attack?

## What the check actually computes A per-step verifier in a tool-using agent takes a proposed action — a capability plus its argument values — and the current recorded objective, and asks whether the first serves the second. The implementation varies: a second model judging the pair, a rule set, a schema-plus-policy match. The shape does not. It is a **consistency** test between two things the run holds, and it dereferences the objective record to get one of them. An attacker who edits that record has changed one of the two inputs to the comparison. Nothing in the comparison notices, because nothing in it is a statement about the record's origin. Consistency is not authenticity, and it is not provenance. ## Why the check flips from obstacle to assistant Before the edit, the verifier constrains the run: an action that does not serve the goal is rejected. After the edit, the constraint still operates, but around the substituted goal. Concretely, it will now reject a step that pursues the operator's *original* intent if that step no longer fits the record. The mechanism that was supposed to keep the run on task is keeping it on the attacker's task, and doing so more reliably than the model would on its own. That inversion — the control becoming quality assurance for the construction — is the thing this leaf exists to teach, and it is why the confident answer "we verify every step against the plan" is the wrong answer here rather than the fix. ## Getting the direction of every claim right This is where candidates slip. Line them up: | The evidence | What it proves | What it does not prove | | --- | --- | --- | | A green step-verification result | The action was consistent with the record at that moment | That the record expresses what an operator asked for | | A complete run of green steps | Every action matched the goal on file | That the goal on file was ever legitimate | | A tool-call log entry | Which capability ran with which argument values | Who chose those values | | No injected span found in later steps | That text is not in those contexts | That no injection influenced the run | Read top to bottom, the pattern is one thing: every artefact here attests to an internal match, and none of them attests to an external origin. ## What the check does still catch Saying the control is useless is as wrong as saying it closes the issue, and an interviewer will push on this. Per-step verification genuinely catches a proposed action that diverges from the goal on record — a capability the task never needed, argument values pointing somewhere unrelated, an action injected into one turn that the goal cannot account for. That is real coverage, and it is why single-step abuse is the harder path against an agent that runs the check. The construction here is a response to that coverage: rather than fight the comparison, change the operand it reads, once, and let the comparison do the rest. ## What it costs the attacker The cost is a write path into the record. That is not free. The attacker generally does not write the objective directly; the run does, through whatever step consolidates, refines or summarises the standing goal as work proceeds. So the construction needs an objective that is re-read from a mutable record rather than restated from a fixed source each step, plus a step whose output feeds that record, plus content that survives that step's own selection of what to keep. The attacker also gets no control over the exact wording that lands, and may need several passes before anything sticks. ## Where it stops working It stops when the operand the check reads is not the operand the run can write. If the goal is restated verbatim on every step from a source the run cannot touch, or the verifier compares against the first recorded revision rather than the current one, the edit reaches at most the step that consumed it. It also stops being invisible when a comparison exists between what the run is doing now and what was originally asked — not because that comparison is unbeatable, but because it is a different comparison, against a different operand. ## How to answer under pressure Open with the operand: the check reads the field that was attacked. Then the inversion: it now enforces the substituted goal. Then the proof direction: green means matched the record, not matched the request. Then the honest caveat: the check still stops off-plan actions, which is exactly why the objective is the thing worth attacking.