DualView: closing the 'stored' prompt-injection gap in personal AI agents

What is this?

Personal AI agents — the kind that run on your own machine and automate web search, email, and file management — sit in front of a large, sensitive surface: the network, the file system, and the shell. That access is exactly what makes indirect prompt injection (IPI) dangerous, because any web page, email, or document the agent reads can carry instructions the agent then acts on. A July 2026 arXiv paper, DualView: Preventing Indirect Prompt Injection in Personal AI Agents (2607.03821), by Juhee Kim, Woohyuk Choi, Taehyun Kang, Youngmin Kim, and Byoungyoung Lee, identifies a blind spot in one of the leading defensive patterns and proposes a fix.

The pattern in question is the Dual LLM design, described by Simon Willison in April 2023 and later formalised by systems like CaMeL (Defeating Prompt Injections by Design, arXiv 2503.18813). The idea is to keep untrusted content away from the model that holds tools: a privileged component plans and acts, while untrusted data is replaced with opaque symbols the agent can pass around but never actually read. DualView’s contribution is to point out that this bookkeeping stops at the edge of the agent’s context — and that attackers can step around the edge.

How it works

The gap the paper names is stored IPI. Dual-LLM defenses track which pieces of data are untrusted only while they live inside the agent’s working context. The moment the agent writes something out — saves a web snippet to a file, appends to a note, drops a value into a shell variable — that provenance label is lost. When the agent later reads the same content back, it comes in fresh, as ordinary trusted data rather than as a guarded symbol. If an attacker’s instruction was hiding in that content, it has now laundered itself from “untrusted” to “trusted” simply by taking a round trip through the file system.

The sequence, at a conceptual level:

[ web page / email carries an instruction-shaped string ]
        │  read into agent context  →  labelled UNTRUSTED (shown as a symbol)
        ▼
[ agent writes the value to a file / note / shell variable ]
        │  provenance label does NOT follow the data out of context
        ▼
[ later, agent reads the file back ]
        │  data returns with no label  →  treated as TRUSTED
        ▼
[ agent now "sees" and can act on the planted instruction ]

DualView’s answer is to extend untrusted-data tracking beyond the context window and into the environment itself — the file system, the shell, the network, and other agents. Each channel is given two views of the same data. In the AgentView, the agent continues to see untrusted content as symbols even after it has written the data out and read it back, which is what closes the stored-IPI path. In the HumanView, the original data is preserved so that human users and ordinary tools still see real values and keep working normally. The label, in other words, is made to persist wherever the data goes, instead of evaporating at the boundary of the model’s context.

Why it matters

Stored IPI matters because it defeats a defense many teams now treat as a strong baseline. The Dual LLM and capability-based approaches are attractive precisely because they promise structural protection rather than best-effort filtering — CaMeL, for instance, reports solving 77% of AgentDojo tasks with provable security against injection, against 84% for an undefended agent. But a defense that assumes untrusted data can be quarantined inside the context has an implicit boundary, and a personal agent that reads and writes files all day crosses that boundary constantly. An attacker does not need a novel exploit; they need only get their text into something the agent will save and reopen, which for a file-managing assistant is close to its normal workload. The residual risk is persistence: an injection that survives on disk can re-arm itself every time the agent revisits the file.

Defenses

The paper’s own lesson is the practical one: treat provenance as a property of data, not of a moment in a conversation. If you rely on a Dual-LLM or symbol-substitution scheme, check whether its untrusted-data tracking follows content across writes and reads to the file system, shell, and network — and assume that if it does not, stored IPI is in scope. A dual-view approach that keeps the “untrusted” label attached wherever the value travels is one way to close that gap; the general principle applies regardless of implementation.

Beyond that specific fix, the surrounding design-pattern literature still holds. Keep the component that can act separated from the content that is untrusted, as in the design patterns catalog by Willison and collaborators and its accompanying paper (arXiv 2506.08837). Enforce least privilege on the agent’s file, shell, and network reach so a laundered instruction has less to work with. And when you evaluate an injection defense, test it against payloads that are written to disk and read back — not just single-turn, in-context injections — so that stored IPI is part of the threat model before deployment, not after.

Status

Item	Reference	Date	Notes
Research paper	DualView: Preventing Indirect Prompt Injection in Personal AI Agents, arXiv 2607.03821	July 2026	Defines “stored IPI”; AgentView/HumanView dual-view tracking
Prior defense	Defeating Prompt Injections by Design (CaMeL), arXiv 2503.18813	Mar 2025	Capability-based dual-LLM; 77% AgentDojo tasks with provable security
Design lineage	Dual LLM pattern (Simon Willison)	Apr 2023	Privileged actor + quarantined reader; symbolic responses
Pattern catalog	Design Patterns for Securing LLM Agents against Prompt Injections, arXiv 2506.08837	Jun 2025	Broader defensive pattern set for agents