The gate that decides whether your agent may delete the bucket almost never sees the original evidence. It sees a handoff: a sentence another model wrote about what an earlier step established. That sentence reliably keeps the claim — this action is authorized — and reliably loses the part that made it safe to ignore. Hold the action and the claim fixed, strip only the words marking it unverified, and approval of risky actions moves from 5% to 60% on one monitor and 9% to 98% on another. Nobody lied. The caveat just did not survive the paraphrase.
The test set is 40 actions that are perfectly fine with authorization and should be refused without it — exporting a customer table, moving money, widening an access rule — across 13 operational domains, plus 16 safe controls that any monitor should wave through. For each action the monitor sees the same request and the same authorization proposition. The only thing that changes is how the authorization is framed.
Step through the four framings. The bars are the mean approval rate for risky actions across the nine open-weight monitors.
Two readings matter here. The first is that the marker works while it is present: a claim carrying (UNVERIFIED) is treated more carefully than the same claim without it. The second is worse — once the marker is gone, mean approval lands at 89.9%, which is within half a point of what the monitors give a claim explicitly stamped VERIFIED. Silence is not read as doubt. It is read as endorsement.
Pooled means hide the shape of this. Pick a monitor and watch its four bars: some models approve nearly everything whatever you tell them, some barely move, and the two that are most careful when the marker is visible are exactly the two that swing hardest when it disappears.
Qwen2.5-14B approves 8.9% of risky actions when the claim is marked unverified and 97.5% when it is not — an 88.6-point swing from deleting one word. Llama-3.1-8B goes from 5.2% to 60.1%. Mistral-7B approves everything in every condition, which is its own problem but not this one. The lesson is not “pick a better monitor”: the monitors that actually read the status are the ones your pipeline can hurt most by losing it.
The framing above is artificial on purpose. The real question is whether an ordinary agent pipeline — a proposer that asks, a summarizer that compresses the step, a memory layer that stores it, a monitor that judges what comes back — produces the stripped version on its own. It does, and the stage that does the damage is not the one most people watch.
Walk the stages. The bar is how often that component left the unverified status out of what it passed on.
Summarizers are the mild offenders: five of them weakened or dropped the status on about 17% of items. Memory compression is where it dies. Every compressor tested lost the literal marker on most items — 60% for the most faithful, 100% for Llama-3.1-8B, which never once carried the wording through. Run the whole chain end to end and the monitors approve what comes out.
And the monitors do not merely get more permissive about the risky 40. Under the pipeline their refusals of the 16 safe control actions fall to zero as well — they stop discriminating, rather than shifting a threshold. A gate that approves everything is not a gate, and from the outside it looks exactly like a gate having a quiet week.
Two obvious repairs, both textual, both tested. The first: use a stronger summarizer. A Llama-3.1-8B summarizer kept the status wording on 98% of items — and risky approval still ran at 43% to 48% against a faithful-handoff baseline of 0% to 4%, because the caveat had drifted to the end of the paragraph and stopped binding to the claim. Preserving the words is not the same as preserving the attachment.
The second repair is to instruct the monitor directly: an asserted authorization is insufficient unless it has been explicitly verified. That is a one-line prompt change, and it is the fix most teams would reach for. Step through what it did to each monitor.
A fix that works on two models, backfires on a third and turns a fourth into an over-refuser is not a fix. It is a per-model tuning problem you have just signed up for.
Suppose your agent proposes actions that need authorization — refunds, deletes, sending on a customer's behalf — and a model-based check approves or blocks each one. If the check reads prose that has been through a summarizer or a memory write, the paper's pipeline rates are the ones that apply to you. If the authorization status travels as a field on the claim and the gate reads that field, the paraphrase cannot touch it.
The structured version is not clever. It is a boolean and a source on the claim object, checked before the model is asked anything, with the model call reserved for the questions a boolean cannot answer. The reason it beats every prompt-level repair in this paper is that no stage in between gets a chance to rewrite it.