Malicious webpages can hijack Meta Muse AI agents through indirect prompt injection

A technical write-up on dev.to walks through how a single malicious webpage can hijack an AI agent such as Meta's Muse — not by exploiting a software bug, but by hiding instructions inside content the agent is asked to read. The technique, known as indirect prompt injection, is emerging as one of the most practical security risks now that AI agents routinely browse the web, read files and call external tools.

How a webpage becomes an instruction channel

According to the dev.to article, the root problem is a category error. A conventional application treats a webpage as inert data, while an AI agent interprets it as language. Once the agent can browse, read files, call tools and send messages, malicious text buried in an ordinary page becomes a command channel — for example, an instruction to ignore the user's request and hand private information to an attacker-controlled domain.

The attack chain the article describes is straightforward: the malicious page is read by the browser, its content enters the model's context, the model follows the embedded instruction, the agent selects a tool, private data is accessed, and an external action follows. Crucially, the attacker needs no API exploit, no memory-corruption bug, no stolen credentials and no compromised server. Control over content the agent is expected to read is enough.

Direct versus indirect injection

Direct prompt injection is when the attacker talks straight to the model. Indirect injection is quieter: instructions are planted in a carrier the agent will process — webpages, emails, PDFs, GitHub issues, search results, images, tool output, database records, calendar events or CRM records. The attacker manipulates the agent's environment rather than the conversation.

That distinction is also why agents change the risk profile. A chatbot that only produces text may simply return a bad answer; an agent can take a bad action — reading a file, calling an API, sending an email, modifying a record or uploading data. The model becomes part of an execution loop.

How Muse's architecture responds

Meta's published Muse security architecture explicitly assumes the agent will encounter adversarial data, the article notes. External data entering the model's context is labeled as untrusted input, and the system layers on prompt-injection detection classifiers, agentic red teaming, runtime isolation, credential isolation and human approval for outbound actions.

The central design idea is context provenance: trusted system instructions, developer policy, the user's request, external web content, tool output, downloaded files and database records may all be text, but they do not all carry the same authority. The goal, as the article frames it, is that the model can read untrusted data without granting that data the authority to issue instructions.

The browser gets special treatment. Muse's browser sub-agent reportedly sees an accessibility-tree representation of a page rather than unrestricted raw page execution, and independent classifiers screen page content, images and media, downloaded files, personal-data egress and high-risk forms. The browser, in effect, becomes a security boundary of its own.

The lethal trifecta

The article invokes the "lethal trifecta," a phrase it credits Simon Willison with popularizing, to describe an agent that combines access to private data, exposure to untrusted content and the ability to communicate externally. When all three conditions hold, an attacker can try to turn the agent into a data-exfiltration mechanism. Muse's published defenses — untrusted-context handling, injection detection, credential isolation, runtime controls and approval gates — map directly onto those three conditions.

Injection beyond text and browsers

The attack surface is not limited to visible text or the web. A multimodal model can read instructions hidden inside an image, and the article lists screenshots, PDFs, diagrams, scanned documents, advertisements, video frames and OCR text as possible carriers. The principle: anything the model can perceive can potentially become an instruction channel.

Tool output is another surface. A database result returned through an MCP tool can carry an injected instruction just as easily as a webpage, which is why the article argues tool output should be treated as potentially untrusted context, and why MCP security and prompt-injection security are tightly connected.

Why it matters

Indirect prompt injection requires no exploit and no stolen secrets — only control of content an agent will read. As agents gain browsers, file access and tool integrations, the failure mode shifts from wrong answers to wrong actions, including data exfiltration. Muse's approach suggests the workable defenses are architectural rather than model-level: provenance labeling, runtime and credential isolation, egress controls, and human approval for sensitive actions. The broader lesson the article draws applies to any agent deployment: untrusted data should never automatically inherit the privileges of trusted instructions.