On-device isn't safer: indirect injection hits local and cloud LLMs alike

What is this?

On June 8, 2026, Brave’s security and privacy research team (Ali Shahin Shamsabadi, Hamed Haddadi and Artem Chaikin) published Indirect Prompt Injection remains a fundamental security challenge for AI, disclosing the same class of flaw in two products that sit at opposite ends of the deployment spectrum: Mozilla Tabstack, a cloud-hosted web-execution API for AI agents, and Cotypist, a fully on-device autocomplete assistant for macOS. Both were notified under responsible disclosure before publication; Tabstack confirmed a fix on June 1, 2026, independently verified by Brave.

The headline is the comparison, not either bug on its own. Indirect prompt injection — instructions smuggled into content the model is legitimately asked to read — is widely assumed to be a cloud, open-web problem that on-device models sidestep. Brave’s finding is that the on-device model was hijacked too. The vulnerability does not depend on where the model runs.

How it works

Indirect prompt injection works because an LLM-integrated system composes trusted developer/user instructions and untrusted external data in a single context window, with no reliable mechanism to keep the boundary between them. The attacker never touches the prompt interface; the payload arrives inside a page, document, or tool result the system will later ingest.

In the cloud case, Brave gave Tabstack’s automation endpoint one routine task — summarize this page — on a page they controlled. The page carried instructions in invisible text (white-on-white / zero-width characters): present in the text layer, invisible to a human. The agent never summarized the page. It followed the hidden steps in sequence — navigated to an attacker-controlled form, populated it with the user’s prompt and full conversation history, and submitted it, exfiltrating that data. The agent’s own reasoning trace shows it treated the page’s instructions as a legitimate continuation of the task; it never flagged a conflict or asked for confirmation. No weaponized payload is reproduced here — the mechanism is the point.

In the on-device case, instructions embedded in a local document steered Cotypist’s autocomplete into suggesting attacker-chosen content and risked surfacing the user’s own credentials inline. The blast radius is smaller: a system-wide autocomplete cannot take autonomous actions, and its tab-to-accept design keeps a human keystroke between an injected completion and its realization. The cloud agent shapes what the model does; the local assistant shapes what the model says. Different consequences — identical structural failure.

This is the same pattern Brave first demonstrated against Perplexity Comet in August 2025, where hidden Reddit-comment text drove the agent across authenticated sessions to exfiltrate an email and one-time passcode. A year on, the lesson now spans local deployment as well.

Why it matters

The practitioner takeaway is a reframed question. The right question is not “does this system use a cloud API?” but “does this system compose trusted instructions with untrusted content in a shared context window?” If yes, it carries indirect-injection risk — the form of the risk depends on the architecture, but its presence does not.

This matters because “we run the model locally” is increasingly offered as a privacy-and-security guarantee. Against this threat model it is not one. A smaller, on-device model is often less able to distinguish malicious from trusted instructions, not more. Local hosting changes the attacker’s entry point (a local file rather than the open web) and the blast radius (what the model says vs. what it autonomously does) — it does not close the hole. Tabstack’s automation endpoint, notably, exposes an optional natural-language guardrail parameter that is not set by default, so the routine configuration is the vulnerable one.

Defenses

Brave frames mitigation as defense-in-depth plus secure-by-design at the system level. The concrete controls, consistent with the recommendations in its Comet research:

• Separate instructions from data, and distrust model output. Pass page/document content to the model as explicitly untrusted, distinct from the user’s request — and treat the actions the model proposes as potentially unsafe, not as authorized commands.
• Check actions for user-alignment. Independently verify that each proposed action matches the user’s actual request before execution, rather than assuming the plan is benign because the model produced it.
• Gate sensitive actions behind explicit user interaction. Navigation to authenticated domains, form submission, sending data outbound, sending email — require a deliberate human confirmation immediately before the action, regardless of the prior plan.
• Isolate agentic mode and apply least privilege. Don’t let casual browsing drift into a fully-privileged agent. Scope an agent’s reachable tools, domains, and data to the task; an assistant that only summarizes does not need credential or cross-site access.
• Don’t rely on local hosting or optional guardrails as the control. On-device deployment is not a substitute for these boundaries, and a guardrail that ships disabled by default protects no one. Apply structural separation, least privilege, and information-flow control by default.

Status

Product	Hosting	Injected via	Impact	Disclosed	Status
Mozilla Tabstack	Cloud (/v1/automate)	Invisible text on a web page	Conversation-history exfiltration to attacker form	2026-05-13	Fixed 2026-06-01 (verified)
Cotypist	On-device (macOS)	Text in a local document	Manipulated autocomplete; risk of surfacing credentials	2026-06-01	Confirmed by vendor 2026-06-02

Both findings reinforce a single point that defenders should internalize: indirect prompt injection is a context-composition problem inherent to current LLM architecture, and it cannot be fully solved by changing where the model runs. Patches close instances; the structural controls above are what reduce the class.