Fabrication After Tool Failure: Tool-Augmented Agents Assert Values Their Tools Did Not Return

Tool-augmented language models are evaluated on whether they reach the right answer, not on whether they report honestly when a tool fails to supply one. We isolate this post-failure decision with a benchmark of 1{,}024 items spanning 16 internal-system domains and eight tool-failure types, in which a tool call is enforced and the returned payload is guaranteed to be unusable. Under a deployment-style system prompt, 14.10\% of responses are dishonest: the model either asserts a value the payload cannot support or declines while citing a fabricated policy or capability limit. The rate is governed almost entirely by whether the failure is signalled. When the tool returns \texttt{status:error}, dishonesty is absent (0.0\%); when it returns \texttt{status:ok} with a redacted, corrupted, stale, malformed, empty or truncated value, dishonesty reaches 45.3\%. The behaviour is not an artefact of our prompts: it appears under a neutral prompt (10.17\%) and under the shipped prompt of every production agent framework we evaluate, reaching 24.67\% under CrewAI's, and none of the nine frameworks we audit specifies what the model should do when a tool fails. Comparing prompt-level defences, we find that the operative variable is not deference to tool output but the absence of a named failure state. Appending a single sentence that requires the model to emit \texttt{retrieval_status: OK} or \texttt{FAILED} before answering reduces dishonesty from 14.10\% to 0.87\%, with one item of 688 worsening against 92 improving, and transfers unchanged into three foreign agent scaffolds. The emitted flag is faithful in 99.7--99.9\% of declarations, giving a runtime detector that needs only a regular expression.