AML.T0078 Drive-by Compromise: AI Defender Guide

An AI assistant or agent that reads a web page can be taken over by that page, with no exploit against the browser and often no click from the user. MITRE ATLAS records this as AML.T0078 Drive-by Compromise, an Initial Access (AML.TA0004) technique: an adversary gains access to an AI system when a user browses normally, or when an agent retrieves web content on the user's behalf, and the page carries an AML.T0051 LLM Prompt Injection that changes the model's behaviour. Classic browser drive-by, where exploit code targets the browser itself, is ATT&CK T1189 Drive-by Compromise, and the general web controls are in the Drive-by Downloads Guide. This guide covers only the AI-specific angle: why browsing agents turn every visited page into an input channel, the published cases, what to log and where, and the controls that hold when model refusals do not. It is for AI platform, detection engineering and endpoint teams.

Key takeaways

The target is the model, not the browser. In AML.T0078 the page does not need a browser vulnerability: text, hidden markup or on-screen instructions enter the model's context through a fetch tool, a plugin, an MCP scraper or a computer-use screenshot.
The agent's privileges are the blast radius. Every ATLAS case for this technique turned page content into an action the agent was already allowed to take: running a shell command, reading a config file, rendering an image URL or calling another plugin.
Refusals are not a control. In the AI ClickFix research, changing a few words on the lure page largely removed the model's refusals. Enforce boundaries outside the model.
Untrusted content should switch the agent into a restricted mode. ATLAS AML.M0030 recommends restricting tool invocation once untrusted data enters the context; pair it with sandboxing (AML.M0032) and human approval (AML.M0029) for consequential actions.
Log the fetch and the action together. Detection depends on correlating "agent retrieved URL X" with "agent then ran a command, wrote a memory or called an external host" in the same session (AML.M0024).

What the technique covers

ATLAS describes two paths into the AI system. In the first, a person browses to a site in the normal course of work and the site's content reaches an AI feature: a browser assistant summarising the page, an "ask AI about this page" button, or an agentic browser acting in the tab. In the second, an AI agent retrieves web content for the user, through a web fetch tool, a search tool, a scraping MCP server or a computer-use session that looks at the screen. In both, the payload is instructions aimed at the model, usually an indirect prompt injection (AML.T0051.001), rather than code aimed at the browser. ATLAS notes that the same approach can deliver ordinary malicious code, which is the T1189 case.

Three properties make the AI version different from a classic drive-by:

No exploit is needed: a fully patched browser and model are still affected, because the "vulnerability" is that the model treats retrieved text as instructions. OWASP LLM01:2025 describes indirect prompt injection as input from external sources, such as websites or files, that alters model behaviour when interpreted.
Content can be invisible to the user: instructions can sit in HTML titles, hidden elements or alternative text that the agent reads and the person never sees. In the Backslash Security case the instructions were in a page's title tag.
The page can target the agent's channel, not the human: the attacker may serve agent-specific content (see MITRE ATLAS AML.T0100 AI Agent Clickbait) and pre-stage everything on attacker infrastructure, which ATLAS records separately as AML.T0079 Stage Capabilities.

Cases ATLAS records

The following ATLAS case studies use AML.T0078 as their initial access step. All were research demonstrations disclosed to the vendors concerned; they show the pattern, not a product verdict.

ATLAS case	How the page reached the model	What the injected content achieved	Control that would have broken the chain
AML.CS0021 ChatGPT Conversation Exfiltration (2023)	User query caused the WebPilot plugin to retrieve the attacker's page	Model summarised earlier chat history and placed it in a Markdown image URL, which rendering sent to the attacker; a second plugin was also invoked	Isolate plugins from conversation context; do not render model-chosen image URLs (see MITRE ATLAS AML.T0077 LLM Response Rendering)
AML.CS0045 Data Exfiltration via an MCP Server used by Cursor	User asked the agent to use a scraping MCP tool on a site; hidden instructions sat in the page title	Agent read an API key from its local MCP configuration and sent it to a remote server, while the session looked normal	No secrets readable by the agent; approval for shell commands proposed after tool output
AML.CS0051 OpenClaw Command and Control via Prompt Injection	Victim asked the assistant to summarise a URL; content was retrieved with its web_fetch skill	Agent ran a remote script, wrote instructions into a workspace file loaded at every session start, then polled an attacker server for tasks	Immutable agent instructions at runtime; approval and sandboxing for exec; egress allowlist
AML.CS0055 AI ClickFix: Hijacking Computer-Use Agents	A computer-use agent visited the researcher's site and read a fake verification dialog	Agent followed on-screen steps to paste and run a command in a terminal on its host	Network isolation and EDR on the agent host; no terminal access for browsing tasks; minimal secrets on the host

A related pattern shows the same channel used at scale without any exploit. Microsoft's Defender research team reported in February 2026 that, over 60 days of AI-related URLs in email traffic, it found more than 50 distinct prompt examples from 31 companies that used "Summarize with AI" buttons and links to open an assistant with a pre-filled prompt asking it to remember the company as a trusted source (ATLAS AML.CS0072; see AML.T0131 Crafted AI Assistant Links). That case is recorded under staging rather than drive-by, but defenders can hunt for both with the same URL telemetry.

Where to detect it

Most of the evidence lives in agent and AI gateway telemetry rather than in the browser. The table lists the sources worth collecting and what to look for in each.

Telemetry source	What to record	Signals worth an alert or hunt
Agent runtime and tool-call logs	Session ID, user, agent identity, each tool call with arguments, the URL or document that preceded it	A web fetch or scrape followed in the same session by exec, file read of credential paths, memory write or a call to a new external host
Agent configuration and memory stores	Changes to system prompt files, skills, rules files and long-term memory, with the session that made them	Edits to instruction files or new memories created during a browsing task; memories containing phrases such as "trusted source" or "in future conversations"
AI gateway or LLM proxy	Prompts, retrieved context and responses (or hashes and classifier verdicts where content cannot be stored)	Prompt injection classifier hits on retrieved content; responses containing URLs with long encoded query strings
Egress proxy, secure web gateway and DNS	Destinations requested by agent hosts and by AI provider fetchers on your behalf	Agent hosts reaching newly registered domains, paste sites or raw IPs; regular polling patterns to one host after a browsing task
Email and collaboration URL telemetry	URLs to AI assistant domains with prompt parameters, and click events	Prompt parameters containing memory-manipulation keywords, as in Microsoft's published hunting approach
Endpoint (EDR) on hosts where agents run	Process trees under the agent runtime, clipboard-to-terminal sequences, script downloads	Shells or interpreters spawned by an agent or browser automation process; downloads executed shortly after a page visit

Check Point Research showed in 2026 that web AI services with browsing can relay traffic between malware and an attacker site (ATLAS AML.CS0061). Its advice applies here too: treat AI service domains as high-value egress points and include AI traffic in hunting and incident response playbooks.

Mitigations that hold

ATLAS maps one mitigation directly to AML.T0078: AML.M0020 Generative AI Guardrails, applied as retrieval, input and tool-action guardrails that detect and block instructions embedded in websites before execution. Guardrails are probabilistic, so treat them as one layer and build deterministic limits around them using the agent mitigations ATLAS defines.

Restrict tools once untrusted content is in context (AML.M0030): after a web fetch, search result or screenshot enters the context, drop to a read-only tool set or require approval for any write, exec or outbound call. This is the single most effective break in the published cases.
Human approval for consequential actions (AML.M0029): require explicit approval for shell commands, file writes outside a scratch area, credential access, memory writes and new outbound destinations, with the triggering content shown to the approver.
Segment and sandbox (AML.M0032): run browsing and computer-use agents in disposable containers or virtual machines built from clean images, with no access to the user's home directory, SSH keys or cloud credentials. See the AI Agent Sandboxing and Code Execution Guide.
Control egress: allowlist the destinations an agent may contact after it has fetched untrusted content, and block image or link rendering to arbitrary hosts. See the Agent Egress Control and Network Isolation Guide.
Protect instructions and memory (AML.M0031 Memory Hardening): make system prompt, skills and rules files read-only to the agent at runtime and require approval for memory writes. See the AI Agent Memory Poisoning Guide.
Log agent steps (AML.M0024 AI Telemetry Logging): record intermediate steps, data access, tool use and agent identity so the fetch-then-act sequence can be reconstructed. The Cursor case notes that past shell commands were hard to reconstruct without command history.
Keep normal web controls in front of agents: secure web gateway categorisation, newly registered domain blocking and remote browser isolation still reduce what an agent can reach, and they also stop the T1189 variant. See the Remote Browser Isolation Guide.

Choosing controls by agent type

Agent type	Main exposure	Priority controls
Chat assistant with web search or fetch, no local tools	Data in the conversation or connected mailboxes leaking through rendered links or images	Guardrails on retrieved content, no auto-rendering of external images, egress limits on provider-side fetchers where configurable
Coding agent with MCP tools and a shell	Credential theft from local config, command execution, persistence in rules files	Approval for shell after any fetch, secrets out of agent-readable paths, rules files under code review (see the Cursor Security Guide for one product's settings)
Agentic browser or computer-use agent	On-screen social engineering such as ClickFix, actions in authenticated sessions	Dedicated VM, no terminal for browsing tasks, separate low-privilege browser profile, EDR on host (see the Browser and Computer-Use Agent Guide)
Autonomous agent with persistent memory and schedules	Instructions that persist and recur, turning one page visit into ongoing command and control	Immutable instruction files, approved memory writes, alerting on scheduled tasks calling new hosts

Smaller teams with a handful of approved assistants should start with configuration: turn off auto-run and auto-approve modes, keep agents off machines holding production secrets, and send agent hosts through the existing web proxy. Larger estates with many agents need a central AI gateway as the single chokepoint for classifiers and logging, which HiddenLayer's OpenClaw research also recommends.

Where identity fits

A drive-by against an agent spends the agent's identity: its API keys, OAuth tokens and the user's delegated session. In the Cursor and OpenClaw cases the prize was plaintext keys in local configuration files. Give browsing agents their own scoped, short-lived credentials, keep long-lived keys out of anything the agent can read, and treat agents as non-human identities in your inventory. The EchoLeak 2025 Microsoft 365 Copilot zero-click prompt injection page shows the same lesson for an assistant fed untrusted email rather than a web page: what the assistant can reach determines what leaks.

How to test your exposure

Inventory web-reading paths: list every assistant, agent and MCP server that can fetch URLs, run searches, scrape pages or view a screen, and the tools each can call afterwards.
Build a benign test page: host an internal page with harmless canary instructions (for example, asking the agent to fetch a unique internal URL or write a marker string), placed in visible text, hidden elements and the page title.
Run it per agent in a test tenant: ask each agent to summarise the page. Record whether the canary action happened, whether approval was requested and whether a guardrail fired.
Check detection end to end: confirm the fetch and the canary action appear in the same session in your logs, and that the alert reached the SOC queue.
Fix and retest: apply tool restriction, approval or egress controls, rerun, and add the test to regression suites so model or product updates that change behaviour are caught. Roll back a control only if the test still passes without it. See the AI Red Teaming Guide for running this as part of a broader programme (ATLAS AML.M0035 AI Red Team).

Measuring whether it works

Coverage: percentage of web-reading agents whose tool calls and fetched URLs reach central logging.
Restriction: percentage of agents that require approval or drop to read-only tools after ingesting untrusted web content.
Canary result: share of agents where the benign test page triggered an unapproved action, tracked per release.
Secret exposure: count of long-lived credentials readable from agent working directories or configuration files.
Detection latency: time from canary action to SOC alert.

Framework mapping

Framework	Reference	Relevance
MITRE ATLAS	AML.T0078 Drive-by Compromise (Initial Access, AML.TA0004); AML.T0051.001 Indirect prompt injection; mitigations AML.M0020, AML.M0024, AML.M0029, AML.M0030, AML.M0031, AML.M0032	Technique, payload type and agent controls
MITRE ATT&CK v20	T1189 Drive-by Compromise; T1608.004 Drive-by Target	Browser-exploit variant and attacker staging
OWASP Top 10 for LLM Applications 2025	LLM01:2025 Prompt Injection; LLM06:2025 Excessive Agency	Indirect injection from websites; agent privileges that turn it into impact
NIST SP 800-53 Rev 5	AC-6 Least Privilege; SC-7 Boundary Protection; SI-4 System Monitoring	Scoped agent permissions, egress limits, agent telemetry
NIST CSF 2.0	DE.CM-09; PR.PS-05	Monitoring runtime environments; preventing unauthorised execution on agent hosts

Common failure patterns

Relying on model refusals: the AI ClickFix research showed small wording changes on the page largely removed refusals, so a model that refused once is not evidence of protection.
Auto-approve left on for convenience: agents allowed to run shell commands without approval convert any fetched page into code execution, as in the OpenClaw case where exec ran without user approval.
Secrets beside the agent: API keys in MCP configuration or .env files readable by the same agent that browses the web.
Writable instructions: agents able to edit their own system prompt files, rules or memory, which turns a one-off injection into persistence.
Logs without linkage: fetch logs in one system and command logs in another with no session ID, so the fetch-then-act sequence is invisible.
Unrestricted rendering: chat clients that render images or links to any host, giving injected instructions a zero-click exfiltration path.

Practitioner checklist

List every AI assistant, agent and MCP server that can fetch, search, scrape or view web content.
Restrict or gate tool calls after untrusted content enters the context (AML.M0030).
Require approval for shell, file write, credential access, memory writes and new destinations.
Run browsing and computer-use agents in disposable sandboxes with no production secrets.
Route agent traffic through egress controls and block arbitrary image or link rendering.
Make instruction files, skills and rules read-only at runtime; review them like code.
Log fetches and tool calls with a shared session ID and alert on fetch-then-exec sequences.
Hunt email and web logs for AI assistant links with memory-manipulation prompts.
Test each agent with a benign canary page after every model or product update.

AML.T0078 Drive-by Compromise: Defending AI Users and Agents That Browse the Web