A web page can show your staff one thing and show your AI agent something else, and nobody looking at the page in a browser will ever see the version the agent acted on. MITRE ATLAS records this as AML.T0134 AI Targeted Cloaking, a Defense Evasion (AML.TA0007) technique added in ATLAS 2026.09 for the Agentic AI platform and rated Feasible. The server recognises an AI browser, agent or crawler, usually from its user-agent string, and returns prompt injections or misleading content to that client only. This guide explains how the technique works at the level a defender needs, how it was demonstrated against AI browsers and answer engines, and how to detect and contain it in agent fetch pipelines, RAG ingestion and AI search. It is for AI platform owners, detection engineers and teams that let agents read the open web. Search poisoning in general is covered in LLM Grooming and AI Search Poisoning; this page covers the cloaking step that hides it.
Key takeaways
- Cloaking is an evasion layer, not the payload. ATLAS describes it as hiding malicious input from humans, ordinary crawlers and security tools; the payload is usually an LLM prompt injection (AML.T0051) or false information.
- The trigger is cheap. In SPLX's October 2025 research, a server rule keyed on the user-agent header was enough to make ChatGPT Atlas, ChatGPT and Perplexity repeat a fabricated profile as fact.
- AI vendors announce their user agents. OpenAI, Anthropic and Perplexity publish crawler and user-triggered fetcher names and IP ranges, which helps site owners and also tells a cloaking server exactly what to look for.
- Detection means comparing views. Store what the agent actually received, refetch suspicious pages as a normal browser, and alert on material differences.
- Containment does not depend on spotting the cloak. Treat all retrieved web content as untrusted, limit what an agent can do after reading it, and check claims against canonical sources before they drive decisions.
What the technique is
ATLAS defines AI Targeted Cloaking as selectively delivering malicious or manipulated content to AI systems while presenting different benign content to human users, web crawlers or security detection mechanisms. Attackers may identify AI browsers or agents by their user-agent strings and condition the server response so AI clients receive prompt injections or misleading content. ATLAS notes it may be combined with AML.T0078 Drive-by Compromise to deliver AML.T0051 LLM Prompt Injection.
It is the AI-era form of an old search engine abuse. Google's spam policies define cloaking as presenting different content to users and search engines with the intent to manipulate rankings and mislead users, for example adding text only when the requesting user agent is a search engine. The difference with AI clients is the consequence: a cloaked page used to win a ranking, while a page cloaked for an agent can change what the agent says, recommends or does with the user's own permissions.
| Signal a server can key on | Why it identifies an AI client | Defender note |
|---|---|---|
| User-agent string | AI operators publish crawler and fetcher names (see the table below) | The signal SPLX used; trivial to read on any web server or CDN rule |
| Source IP range | Operators publish IP range files for their bots | Same data defenders use for verification can be used to target |
| Request pattern | Agents fetch without loading images, fonts or running the same scripts as a person | Harder to normalise; a reason not to rely only on user-agent changes |
| Rendering path | Some agents read text extracted from the page or screenshots rather than the rendered view | Brave showed text hidden from people being passed to the model through screenshot text recognition |
Who announces what: AI client identifiers
The operators below are listed alphabetically. Each publishes its own names and IP range files; the AI Crawler and Scraper Controls guide covers them in full for site owners. What matters here is that user-triggered fetchers, the agents that read a page because a user asked, are the ones a cloaking site most wants to reach, and they behave differently from training crawlers.
| Operator | Training or search crawlers | User-triggered fetcher | Notes from the operator's documentation |
|---|---|---|---|
| Anthropic | ClaudeBot, Claude-SearchBot | Claude-User | Bots honour robots.txt; blocking IPs is not a reliable opt-out because the bot then cannot read robots.txt |
| OpenAI | GPTBot, OAI-SearchBot | ChatGPT-User | ChatGPT-User visits pages when a user asks; robots.txt rules may not apply; IP ranges published per bot |
| Perplexity | PerplexityBot | Perplexity-User | Perplexity-User generally ignores robots.txt because a user requested the fetch; IP range files are the source of truth for WAF rules |
For your own agents, the lesson is that a distinctive, announced identity makes your agent easy to single out. That is not a reason to disguise it, since honest identification is what site owners rely on, but it is a reason to design the pipeline on the assumption that some sites will show your agent a different page.
How it has been used: cases
- Fabricated reputation (SPLX, October 2025): researchers built a portfolio site for a fictional designer. People saw a normal portfolio; AI agents received a negative profile with invented project failures. ChatGPT Atlas and other tools repeated the negative version as fact, and neither ChatGPT nor Perplexity flagged the inconsistency or checked another source.
- Biased hiring ranking (SPLX, October 2025): five fictional CVs were hosted on separate pages, and one candidate's page served an inflated CV only to AI clients. Reading the live pages, Atlas ranked that candidate first with 88 out of 100; given the human-visible CVs, the same model ranked her last with 26. One conditional server rule changed a hiring outcome.
- Content people cannot see (Brave, October 2025): Brave showed instructions hidden in images as faint text being extracted from screenshots and passed to Perplexity Comet's model with no distinction from the user's request, and Fellou passing page content to the model as soon as a user asked it to visit a site. This is not user-agent cloaking, but it is the same idea: the model receives content the human does not perceive.
The impact is wider than browsers. Any agent that fetches URLs, any answer engine, and any RAG pipeline that ingests web pages can be fed a cloaked version. Once that content is stored it becomes RAG poisoning (see AML.T0070 RAG Poisoning) or agent context poisoning (see MITRE ATLAS AML.T0080 AI Agent Context Poisoning), and links designed to lure agents are covered in MITRE ATLAS AML.T0100 AI Agent Clickbait.
What to detect and where
| Where | What to record | What to alert on |
|---|---|---|
| Agent fetch tool or browsing proxy | URL, final URL after redirects, user agent sent, response status, content hash, the extracted text passed to the model | Pages whose agent view differs materially from a browser-profile refetch |
| RAG ingestion pipeline | Source URL, fetch identity, timestamp and hash per document chunk | New sources whose stored text cannot be reproduced by an independent fetch |
| Prompt and model gateway | Retrieved content included in each prompt, with its source | Instruction-like text in retrieved content, tool calls that follow immediately after reading an external page |
| Agent action log | Tool invocations, parameters and the content that preceded them | Actions the user did not request, especially sends, purchases, credential use or data exports after browsing |
| Your own websites | Web server and CDN configuration changes, rules that branch on user agent | New rules naming AI crawlers or fetchers that the web team did not create, which can indicate a compromised site serving cloaked content |
Differential fetching
The core detection is a comparison. For a sample of pages your agents read, and for every page that preceded a high-impact action, refetch the URL from a separate network location using an ordinary browser profile, extract text the same way, and compare. Expect noise from personalisation, consent banners, A/B tests and dynamic prices, so compare extracted main content rather than raw HTML, and score differences by the presence of instruction-like text, named entities or claims that appear in only one view. A refetch with the same user agent from a different IP range helps separate user-agent cloaking from IP-based cloaking.
Keep the evidence. Without a stored copy of what the agent received, an investigation after a bad decision will only find the clean page a human sees.
Mitigations
As of ATLAS 2026.10 no mitigation is mapped directly to AML.T0134. The controls below come from ATLAS mitigations for the techniques cloaking delivers, and from the SPLX and Brave recommendations.
| Control | ATLAS reference | What it does against cloaking |
|---|---|---|
| Treat retrieved content as untrusted data, never instructions | AML.M0020 Generative AI Guardrails | Limits what an injection delivered by a cloaked page can make the model do |
| Block or confirm tool calls after reading untrusted content | AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data | Stops a cloaked page triggering actions directly |
| Human approval for consequential actions | AML.M0029 Human In-the-Loop for AI Agent Actions | Puts a person between the agent's reading and its acting |
| Log prompts, retrieved content and tool calls | AML.M0024 AI Telemetry Logging and Monitoring | Makes differential review and investigation possible |
| Keep provenance for ingested documents | AML.M0025 Maintain AI Dataset Provenance | Lets you trace and purge cloaked content from RAG stores |
| Separate agentic browsing from the user's normal sessions | AML.M0032 Segmentation of AI Agent Components | Brave's recommendation; limits what a page can reach with the user's logged-in privileges |
| Red team AI workflows for content-layer attacks | AML.M0035 AI Red Team | Tests whether your agents notice or resist a different view |
Practical controls beyond ATLAS:
- Verify claims against canonical sources: for decisions about people, suppliers or security, require the agent to cite at least one authoritative source rather than a single page it fetched, which is the validation step SPLX recommends.
- Allow lists for high-trust tasks: agents that make or support decisions should read from approved domains; open web reading belongs in lower-trust workflows.
- Show the user what the agent read: where agents summarise pages, give the user a view of the extracted text, so a person can notice content they would not have seen in the browser.
- Bot authentication with care: SPLX calls for provenance signals and crawler authentication. Signed-request schemes for automated traffic, such as the IETF web bot authentication work based on HTTP Message Signatures, help sites trust agents, but proving who the client is also makes it easier to identify, so they do not prevent cloaking.
Where your own site could be the source, secure the web estate: change control on CDN and server rules, integrity monitoring of templates, and periodic fetching of your key pages with the published AI user agents to confirm they get the same content as people.
Where identity fits
Cloaking matters most when the agent holds authority. An agentic browser running with the user's logged-in sessions, or an agent with OAuth tokens for mail and files, turns a lie told only to the agent into an action taken as the user. Scope agent credentials to the task, keep them separate from the user's personal sessions, and require step-up approval for sends and payments. See the Agentic Browsers Security Guide for session and token handling in AI browsers.
How to test
- Build a test page you control: host a page that returns different, clearly marked benign content to the user agents your agents send. Do this only on infrastructure you own.
- Run your agents against it: ask them to summarise, rank or act on the page, and record whether the output reflects the agent-only version.
- Check detection: confirm your differential fetch flags the page and that the stored record shows exactly what the agent received.
- Check containment: include benign instruction-like text in the agent-only version and confirm the agent does not call tools because of it, or that the call is held for approval.
- Repeat by channel: run the same test through the RAG ingestion path, the browsing tool and any AI browser in use, since each extracts content differently.
- Roll back safely: remove the test pages and purge their content from any vector store or cache they reached.
Measuring it
- Share of agent web fetches stored with content hash and extracted text (target 100% for agents that can act).
- Share of high-impact agent actions preceded by an external page that was independently refetched and compared.
- Number of cloaking differences detected per month, and the share confirmed as malicious after review.
- Share of agent decision workflows that require a canonical source.
- Pass rate of cloaking tests in AI red team exercises.
Common failure patterns
- Checking the page in a browser: an analyst opens the URL, sees clean content and closes the case. Without the agent's stored copy the cloak wins.
- Trusting popular domains: a compromised legitimate site can add a user-agent rule; reputation of the domain says little about what it served your agent.
- Single-source decisions: as in the SPLX hiring test, one page fetched by the agent decided a ranking without any cross-check.
- Ingesting without provenance: once a cloaked page is chunked into a vector store without source and fetch metadata, it cannot be traced or removed cleanly.
- Agents with the user's full session: an agentic browser acting with every logged-in session the user has turns misleading content into account actions.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0134 (AML.TA0007 Defense Evasion) | The technique; combined with AML.T0078 Drive-by Compromise to deliver AML.T0051 |
| MITRE ATLAS mitigations | AML.M0020, AML.M0024, AML.M0025, AML.M0029, AML.M0030, AML.M0032, AML.M0035 | Controls for the delivered injection and for investigation (not mapped to T0134 by ATLAS) |
| OWASP Top 10 for LLM Applications 2025 | LLM01:2025 Prompt Injection, LLM09:2025 Misinformation | Indirect injection through external content; false content presented as fact |
| NIST SP 800-53 Rev. 5 | SI-10, AU-2, SI-4 | Input validation of retrieved content, event logging, monitoring |
Related ATLAS technique pages: AML.T0051 LLM Prompt Injection and MITRE ATLAS AML.T0068 LLM Prompt Obfuscation, which hides instructions inside content rather than serving a different page.
Practitioner checklist
- Store the URL, fetch identity, hash and extracted text for every page an agent reads.
- Refetch pages that preceded high-impact actions as a normal browser and compare.
- Treat retrieved web content as data and hold tool calls that follow it for approval.
- Require canonical sources for decisions about people, suppliers and security.
- Keep provenance metadata on every ingested RAG document so cloaked content can be purged.
- Separate agentic browsing from users' personal sessions and scope agent tokens.
- Monitor your own CDN and server rules for unexpected branches on AI user agents.
- Add cloaking scenarios to AI red team plans and track the pass rate.
Standards and references
- MITRE ATLAS: AI Targeted Cloaking
- OWASP: LLM01:2025 Prompt Injection
- Google Search Central: Spam policies (cloaking)
- SPLX: AI-targeted cloaking research on OpenAI Atlas
- Brave: Unseeable prompt injections in AI browsers
- OpenAI: Overview of OpenAI crawlers
- Anthropic: Crawler documentation for site owners
- Perplexity: Perplexity crawlers
Related NHI Mgmt Group resources: MITRE ATLAS Guide · LLM Grooming and AI Search Poisoning · OWASP LLM Top 10 LLM01 Prompt Injection Guide · MITRE ATLAS Mitigations Guide