Tool-using agents are evaluated on whether they can finish a task with a tool. Almost never on what happens when the tool hands back something plausible and false. Corrupt the returns of three ordinary tools — web search, a delegated sub-agent, a code sandbox — and fourteen models adopt the corrupted content in more than a third of runs on every tool, and 68.0% of the time on search. On 53.9% of those the model had already answered that same question correctly with no tool at all. And on the code sandbox, over 90% of the runs that adopted a wrong number had noticed the conflict in their own reasoning — 1.8% mentioned it to the user.
The three tools are the ones sitting in most production agents: a web search, a sub-agent you delegate a document to, and a sandbox that runs code and returns a number. For each, the study lets the agent call the tool normally and then rewrites what comes back — a credible-looking wrong value, kept internally consistent so nothing about the formatting gives it away. Then it reads the final answer.
Two numbers matter. Adoption is how often the corrupted content ends up in the answer the user sees. Override is narrower and much more damning: adoption measured only on the items the model answers correctly when you ask it with no tool at all. Override is the model throwing away something it knew.
The code sandbox is the reassuring case and the search tool is the alarming one, which is the wrong way round from how most teams reason about it. Arithmetic is the one domain where the model can check the tool from first principles, and it still adopts a wrong number in 35.4% of runs. Search is the tool nobody can check — and it is also the tool the model defers to hardest.
If agents had any real verification behaviour, corruption would be rejected in proportion to how wrong it is. It is not. The study varies how the fake value is built, and the pattern that comes out is a coherence filter, not a truth filter: content is rejected when it looks out of place, and swallowed when it looks like it belongs.
Watch what happens on search when the injected value moves from a credible number, to a real answer taken from a different question, to a value with no real-world referent at all. And on the sandbox, watch what one minus sign does.
The middle case is the tell. A real answer belonging to some other question is the most factual corruption in the set and it is rejected hardest — 12.6% adoption against 68.0% — because it does not fit the question being asked. Meanwhile pure invention, which no coherence check would catch, gets through three times as often. And on the sandbox, a wrong number with the right sign is adopted 56.4% of the time against 14.3% for one that flips positive to negative: the same magnitude of error, sorted entirely by whether it looks like an answer.
There is a second, sharper version of this. Take an identical false statement and change only the channel it arrives on — the tool returns it, or the user asserts it in the prompt, or it appears in a retrieved document.
Same sentence, same falsehood: 39.9% adoption when a tool says it, 1.8% when the user does. That factor of twenty-two is not a fact about the model's reasoning. It is a fact about the frame your harness put the content in — and it is the one lever in this entire paper that moves the number by an order of magnitude.
This is the finding that should change what you build. Reading the reasoning traces of the thinking models, the study separates three things that could happen inside a run that ends in adoption: the model notices the tool's value disagrees with what it believes; the model actually derives the correct value itself; the model tells the user any of this.
Step through the two tools and compare what was in the reasoning against what reached the user.
On the sandbox the model calls the tool again, sometimes an order of magnitude more times than it does on a clean run — measurable, billable evidence that it is unhappy — and then reports the tool's number with no caveat at all. The information required to warn you existed inside the run. It simply never crossed the boundary into the response.
One model in the pool, Muse-Glimmer-30B, warns in about half of its adopting answers. So this is a behaviour, not a law of nature. It is just not a behaviour anything in the standard training or prompting stack currently produces.
There are exactly three parties who can act: you, writing the prompt; whoever operates the tool, attaching metadata to the return; and whoever trains the model. The study tries all three.
Start with prompting. Four instruction policies — plain, compare the tool against your own belief, verify before answering, disclose any conflict — scored on clean returns (accuracy you keep) and corrupted returns (adoption you want to lose).
Compare is the best of them and it costs you three and a half points of clean accuracy on search to buy five and a half points of adoption. Verify barely moves search at all. Nothing here dominates; every policy that helps on one tool gives it back on another.
Now the tool provider's turn. Attach a source to each search return, or an explicit reliability score, and see which way the agent moves.
Every label lands in a nine-point band around 67%, whether the corrupted claim is attributed to a wire service or to a message board. Worse, the labels work backwards: a return stamped with a higher reliability score is adopted 3.7 points more often with numeric labels and 4.5 points more often with categorical ones. The metadata is not being read as evidence about the source. It is being read as permission.
That leaves post-training. Three recipes on Qwen3-30B: supervised fine-tuning on traces that recovered correctly, supervised fine-tuning on correct tool use, and preference training on fixed contexts.
Preference training buys five points on search and nothing on the sandbox. Training on correct tool use makes both worse — the model learns harder that tool returns are the thing to use. None of it transfers across tool channels, which is the pattern you would expect if overtrust is not a skill deficit at all but the default posture of a model towards anything arriving in a tool-result slot.
Put the paper's measured rates against a traffic volume. Pick the tool your agent leans on, set how often its returns carry something wrong — a stale index entry, a hallucinating sub-agent, a unit bug in a sandboxed script — and the arithmetic does the rest. The adoption and warning rates are the paper's; the traffic and the error rate are yours to set.
The number that should decide your architecture is the silence column. A wrong answer your agent flags is a support ticket. A wrong answer it delivers with the same confidence as a right one, having internally noticed the problem and decided not to mention it, is something you will find out about from a customer.