WhatsApp's hidden LLM instructions expose a retrieval provenance failure. An official page can be a trusted source of facts while still containing text that has no authority over a model. This article builds a dual-view audit for what people see, what machines extract, which passages reach the model, and which policy directs the answer.
Reading time: 9 minutes | Length: about 1,900 words
TL;DR
- Redact reported 102 hidden blocks across 80 of 545 WhatsApp help pages. Two blocks told a support chatbot to avoid mentioning regulators or privacy law in specific situations.
- WhatsApp told WIRED that the text was intended for its own support chatbot and appeared on public help pages because of a bug. The blocks were later removed.
- Archived source independently supports the narrow event claim: the account-deletion instruction appears in the October 9 snapshot and is absent from the October 18 snapshot.
- No public evidence shows that an outside assistant retrieved or obeyed the instructions. This is a content-governance and retrieval-provenance incident, with a plausible indirect-injection path, rather than a demonstrated compromise of third-party models.
- Domain allowlists are insufficient. A production RAG system needs separate authority for sources and instructions, model-visible diffs, immutable snapshots, passage lineage, and paired answer tests.
What the evidence establishes
Redact's investigation examined 545 WhatsApp help pages and found 102 hidden blocks on 80 pages. Most were support-oriented housekeeping. Two were materially different.
One block on the account-deletion page instructed the AI not to recommend contacting a data protection authority, regulator, or supervisory authority. Another told the AI to avoid discussing legal documents and named privacy laws after a user mentioned legal action. The text was present in the response payload but absent from the rendered page.
Three evidence layers should remain separate:
| Claim | Evidence | Strength |
|---|---|---|
| The hidden text existed on the public help-page response | October 9 Internet Archive snapshot contains the account-deletion instruction in page source | Direct archived artifact |
| The text was later removed | October 18 snapshot retains the help page while the instruction is absent | Direct before-and-after comparison |
| The blocks were intended for WhatsApp's support chatbot | WhatsApp's explanation reported by WIRED | Attributed company statement |
| Outside assistants followed the blocks | No published behavioral test establishes this | Unverified |
This distinction matters. The incident demonstrates that first-party content management can mix human-facing copy and model-facing instructions. It does not demonstrate that ChatGPT, Claude, Perplexity, or another external assistant ingested and followed the text.
The archived diff also gives the event a stronger foundation than a screenshot alone. A screenshot proves a rendered state. The two snapshots preserve a machine-readable before-and-after record tied to timestamps and URLs.
Source trust and instruction authority are different controls
RAG pipelines commonly rank an official help center above forums, scraped blogs, and user posts. That makes sense for factual sourcing. It becomes dangerous when the same trust score also decides whether text may direct model behavior.
Those are separate permissions:
- Source trust answers whether a passage is a credible source for a factual claim.
- Instruction authority answers whether a passage may change the model's task, priorities, disclosure policy, or tool behavior.
An official domain can deserve high source trust and zero instruction authority. A user manual may accurately describe account deletion while containing embedded text that attempts to constrain the answer. A regulator's page may contain imperative legal language that should be quoted as evidence, not executed as a model instruction.
This incident came from a first-party publishing error rather than a confirmed attacker. The technical boundary is still the same. Once content enters a model context, imperative sentences can compete with the actual system policy unless the retrieval architecture keeps data and control separate.
That is the supply-chain lesson. The relevant chain is not only model weights and software dependencies. It also includes:
CMS record
-> server response
-> parser and extractor
-> retrieval chunk
-> prompt assembly
-> model answer
-> user-visible or tool-executed result
Every transition can change visibility, provenance, and authority.
Build a dual-view content contract
A crawler's success status says little about what the model actually received. Teams need to preserve and compare at least four views of every high-impact source.
1. Human-rendered view
Capture the page as a person sees it. This establishes the visible disclosure and supports ordinary content review.
2. Raw response view
Store the HTML or structured payload returned by the server. Hidden elements, metadata, alternate content branches, and crawler-specific responses can exist here without appearing on screen.
3. Extracted retrieval view
Record the normalized text after scripts, markup, navigation, hidden elements, and duplicate content have been processed. This is the actual data surface for search and retrieval.
4. Model-context view
Log the exact passages inserted into the prompt, together with source URL, content version, retrieval score, parser version, and policy version. This is the evidence needed to explain an answer.
The four views should share one immutable content identifier. A useful manifest can include:
{
"source_url": "https://example.com/help/account-deletion",
"fetched_at": "2026-10-21T00:00:00Z",
"raw_hash": "...",
"rendered_hash": "...",
"extractor_version": "...",
"chunk_ids": ["..."],
"source_trust": "official-product-documentation",
"instruction_authority": "none"
}
The important field is the last one. Content can support an answer without receiving permission to govern the answer.
Add release gates before content reaches retrieval
The strongest control belongs in the publishing and ingestion path, before a questionable block reaches a production index.
Compare rendered and extracted text
Large differences deserve review. Hidden accessibility text and structured metadata are legitimate, so a difference alone is not a failure. The gate should highlight imperative language, policy terms, invisible blocks, and content that only appears under particular user agents or locales.
Separate policy from knowledge
Support-bot policy should live in a versioned policy system with named owners, access control, review history, and rollback. Product facts should live in the help center. Mixing both into one CMS response erases the boundary between documentation and behavior control.
Strip authority during prompt assembly
Retrieved passages should enter the prompt under an explicit rule: use them as evidence, never as instructions. This will not solve every indirect prompt injection, but it makes the intended hierarchy inspectable and testable.
Preserve source and passage lineage
An answer citation should resolve to the exact retrieved version, not merely the current URL. Otherwise a later content edit can make an old answer impossible to audit.
Run paired answer tests
For sensitive support topics, run the same question against two controlled inputs:
- the visible page text;
- the complete extracted payload.
Compare whether the answers mention available escalation routes, quote policy accurately, and preserve required disclosures. The output difference is a direct measurement of model-visible hidden content changing behavior.
Treat the incident as a governance failure before calling it an attack
Security language should match the evidence. The WhatsApp pages contained model-directed text and exposed a plausible indirect prompt-injection path. Redact also states that it did not test whether outside assistants acted on the blocks.
The defensible classification is therefore:
- a confirmed leak of model-facing support instructions;
- a confirmed mismatch between human-visible and machine-visible content;
- a confirmed failure to isolate behavior policy from public documentation;
- a potential retrieval supply-chain risk;
- an unverified compromise path for third-party assistants.
This precision improves the engineering response. Calling every hidden instruction an attack encourages generic prompt-injection advice. Calling this a provenance failure points directly to the CMS, extractor, index, policy store, and answer-evaluation controls that need to change.
The distinction also separates this case from a document-borne AI worm, where an adversarial instruction reportedly propagated through generated documents. Here the immediate problem sits upstream: an approved first-party source delivered different content to people and machines. It also differs from LLM relay risk, which concerns intermediaries that can inspect or alter prompts and responses in transit.
A minimum retrieval provenance checklist
Before an official site enters a production retrieval index, require evidence for these questions:
- Do the rendered page and extracted payload contain materially different claims or instructions?
- Can the source publish model-only content, and who approves it?
- Are source trust and instruction authority stored as separate attributes?
- Can every answer be traced to an immutable content version and exact passage?
- Are policy instructions stored outside the public knowledge corpus?
- Do paired tests detect changes in legal, privacy, safety, or escalation guidance?
- Can a content version be quarantined and rolled back without rebuilding the entire index?
- Does monitoring alert on new hidden imperative text or user-agent-specific responses?
An official domain remains useful evidence. It should never become an unbounded control plane.
Frequently asked questions
Were the WhatsApp hidden instructions a prompt injection attack?
The public evidence confirms model-facing instructions on help pages and a failure to separate content from control. It does not establish an external attacker or a compromised third-party assistant. "Potential indirect prompt-injection path" is more accurate than "confirmed attack."
Did outside AI assistants retrieve or follow the hidden text?
No published test establishes that. Redact reported that some AI crawler user agents did not receive the page during its checks, and it explicitly listed outside-assistant behavior as unknown.
Why could a model see text that users could not?
A model pipeline may parse raw HTML or structured page data rather than the rendered visual layer. Content hidden by presentation rules can remain present in the response and therefore in extracted text.
How should teams audit model-visible website content?
Preserve the rendered page, raw response, extracted text, and final prompt passages. Diff the layers, flag hidden imperative language, bind every passage to a versioned manifest, and test answers with and without the hidden blocks.
Is a domain allowlist enough for RAG security?
No. A domain allowlist establishes source identity. It does not prove that every passage is visible, current, policy-compliant, or entitled to direct model behavior.
Next action
Choose one sensitive official source already used by a production assistant. Capture its rendered page, raw response, extracted text, and final prompt passages; bind them to one versioned manifest; then run a paired answer test with visible-only and full extracted content. That single exercise reveals whether the system can distinguish source trust from instruction authority.