WebFetch can fabricate confident factual claims by misreading page boilerplate as live status

Summary

WebFetch returns an LLM-summarised view of a page. When that summariser encounters template / boilerplate text containing factual-looking phrases, it can present them in the response as if they were extracted facts about the specific entity on the page. The calling Claude has no way to tell, from the WebFetch output alone, whether a claim was a literal extraction or an inferred summarisation — so it tends to be passed through as fact.

This is dangerous when the page describes a real person, company, or other entity whose status the user might act on.

Reproduction

URL: any company entry on the Estonian e-Business Register, e.g.
https://ariregister.rik.ee/eng/company/<reg_code>

These pages contain template language including phrases like:

• "A deletion notice concerning a legal person is published in the Ametlikud Teadaanded (Official Announcements)" — which appears as part of a "Subscribe to notification" widget describing the kinds of notifications you can subscribe to
• "Verification from Official Announcements failed" — meaning the live announcement check did not return data
• "Loading..." — placeholder for the JS-driven announcements section

The actual Status field on the entity is Entered into the register (i.e. active, healthy).

Prompt

\\\
WebFetch(url=<that URL>, prompt=\"Extract: full legal company name, registration code, VAT number, registered address, status, board members.\")
\\\

Expected

The response should either:

• Distinguish between fields literally extracted from the entity record (status, registry code, VAT, etc.) and any text drawn from page boilerplate, OR
• Not surface boilerplate as if it were live status

Actual

The response contained a section like:

Note: A deletion notice has been published in Official Announcements regarding this legal person

…stated as a fact about the specific entity, with no indication that the underlying source was template/help text and that the live verification had failed.

Impact

The calling Claude (me) then passed this through to the user as a verified fact about the user's business partner's company, used it to argue for tighter payment terms (\"the dissolution flag, which argues for net 7\"), and repeated it in the final summary as a \"reminder.\" The user caught it because they opened the page themselves and could see no such notice.

In a less attentive pipeline (autonomous agent, scheduled task, downstream tool that consumes WebFetch output as data), this kind of fabrication propagates silently. The defamatory potential — telling someone their business partner's company is being dissolved when it isn't — is non-trivial.

Suggested Mitigations

1. Surface provenance. When a claim in the summary is inferred or drawn from non-primary text (boilerplate, sidebars, templated widgets), mark it as such — e.g. an inferred: prefix or a separate \"caveats\" section, distinct from literal field extractions.
2. Bias the summariser toward literal extraction. When the user prompt asks for specific fields (status, name, VAT, etc.), prefer returning fields that are literally present in the page's structured content over interpretive summary text.
3. Surface verification failures. If the page itself contains \"verification failed\" / \"loading\" / similar signals near a claim, the summary should reflect that uncertainty, not assert the claim.
4. In Claude Code's system prompt or tool docs, warn the calling Claude that WebFetch returns an LLM interpretation, not raw extraction, and that confident factual claims about real entities should be re-verified against raw HTML before being passed through to the user.

Environment

• Claude Code CLI on macOS (Darwin 25.3.0)
• Model: Opus 4.7 (1M context)
• WebFetch tool (built-in)

Workaround currently in use

Re-fetching with curl and grepping the raw HTML for the claim before passing it through.