Paper deep dive
DualView: Preventing Indirect Prompt Injection in Personal AI Agents
Juhee Kim, Woohyuk Choi, Taehyun Kang, Youngmin Kim, Byoungyoung Lee
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 92%
Last extracted: 7/7/2026, 9:52:22 AM
Summary
The paper introduces DualView, a security plugin for local personal AI agents like OpenClaw that prevents Indirect Prompt Injection (IPI) and stored IPI attacks. It extends the Dual LLM pattern by maintaining two synchronized views of the user environment: AgentView, which symbolizes untrusted data to isolate the agent from malicious prompts, and HumanView, which preserves original data for human users and external tools. DualView routes tool calls and synchronizes data across views, achieving strong security without compromising agent or human utility.
Entities (7)
Relation Signals (7)
DualView â prevents â Indirect Prompt Injection
confidence 95% · DualView blocked every IPI attack, including stored IPI, while keeping utility close to the unprotected baseline.
DualView â uses â AgentView
confidence 93% · In AgentView, the agent sees untrusted data as symbols even after writing it out and reading it back, blocking stored IPI
DualView â uses â HumanView
confidence 93% · while HumanView preserves original data for humans and tools.
DualView â deploysas â OpenClaw plugin
confidence 92% · DUALVIEW deploys as an OpenClaw plugin using only tool hooks, without changing the agent's tool-call logic or tool implementations.
AgentView â blocks â Stored IPI
confidence 91% · In AgentView, the agent sees untrusted data as symbols even after writing it out and reading it back, blocking stored IPI
DualView â extends â Dual LLM pattern
confidence 90% · DUALVIEW extends untrusted data tracking from the Dual LLM pattern beyond the agent context and into the userâs computer environment.
DualView â evaluateson â PinchBench
confidence 88% · In our evaluation on an IPI benchmark and PinchBench, DualView blocked every IPI attack
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Personal AI agents that run on the user's local machine, such as OpenClaw, automate daily tasks including web search, email, and file management. Their access to computer resources, including the network, file system, and shell, exposes them to indirect prompt injection (IPI) attacks. Prior Dual LLM defenses block IPI by replacing untrusted data with symbols that the agent can reference but not read. However, they track untrusted data only inside the agent's context, so when the agent saves and later rereads untrusted data, that data, possibly an attacker's prompt, can return as trusted data rather than as a symbol, which we call stored IPI. Operating on the user's real environment, which humans and programs share, is what makes agents like OpenClaw practical, and is exactly why a defense that ignores it is incomplete. Preserving symbols in such an environment is hard, because humans and programs need original data. We present DualView, which extends untrusted data tracking from the agent's context to the user's environment, including the file system, shell, network, and other agents, by giving each channel two views. In AgentView, the agent sees untrusted data as symbols even after writing it out and reading it back, blocking stored IPI, while HumanView preserves original data for humans and tools. DualView routes each tool call to the right view and synchronizes data across the two views. DualView deploys as an OpenClaw plugin using only tool hooks, without changing the agent's tool-call logic or tool implementations. Since DualView isolates untrusted data by design, its protection is not limited to known attack templates. In our evaluation on an IPI benchmark and PinchBench, DualView blocked every IPI attack, including stored IPI, while keeping utility close to the unprotected baseline.
Tags
Links
- Source: https://arxiv.org/abs/2607.03821v1
- Canonical: https://arxiv.org/abs/2607.03821v1
Trouble viewing inline? Open PDF directly â
Full Text
99,850 characters extracted from source content.
Expand or collapse full text
DUALVIEW: Preventing Indirect Prompt Injection in Personal AI Agents Juhee Kim * , Woohyuk Choi * , Taehyun Kang, Youngmin Kim, and Byoungyoung Lee Seoul National University AbstractâPersonal AI agents that run on the userâs local machine, such as OpenClaw, automate daily tasks including web search, email, and file management. Their access to computer resources, including the network, file system, and shell, exposes them to indirect prompt injection (IPI) attacks. Prior Dual LLM defenses block IPI by replacing untrusted data with symbols that the agent can reference but not read. However, they track untrusted data only inside the agentâs context, so when the agent saves and later rereads untrusted data, that data, possibly an attackerâs prompt, can return as trusted data rather than as a symbol, which we call stored IPI. Operating on the userâs real environment, which humans and programs share, is what makes agents like OpenClaw practical, and is exactly why a defense that ignores it is incomplete. Preserving symbols in such an environment is hard, because humans and programs need original data. We presentDUALVIEW, which extends untrusted data tracking from the agentâs context to the userâs environment, including the file system, shell, network, and other agents, by giving each channel two views. In AgentView, the agent sees untrusted data as symbols even after writing it out and reading it back, blocking stored IPI, while HumanView preserves original data for humans and tools.DUALVIEWroutes each tool call to the right view and synchronizes data across the two views. DUALVIEWdeploys as an OpenClaw plugin using only tool hooks, without changing the agentâs tool-call logic or tool implementations. SinceDUALVIEWisolates untrusted data by design, its protection is not limited to known attack templates. In our evaluation on an IPI benchmark and PinchBench, DUALVIEWblocked every IPI attack, including stored IPI, while keeping utility close to the unprotected baseline. 1. Introduction Personal AI agents are useful because they assist users by running in the same computer environment where users already work. Users often allow the agents to read local files, fetch external data, run shell commands, send email, process webhook payloads, and communicate with other agents [1â5]. These capabilities let the agent not only answer questions but also handle routine computer tasks for the user. A representative example is OpenClaw [6], a local-first AI agent that runs on the userâs machine and exposes such tools. A user can ask the agent to âsummarize market news and save notes to./report.md.â To complete the task, the * . Equal contribution. agent searches the web, fetches web pages, and writes a local file. The userâs computer environment is also where humans and non-agent programs continue to read, edit, and reuse the agentâs results. The same capabilities create the security problem. When an agent reads external data and can act on the userâs resources, it is exposed to indirect prompt injection [7â9]. A remote attacker can place natural-language instructions inside the external data the agent reads. If the backing model misinterprets the attacker-controlled text as an instruction, it can issue tool calls that use the agentâs authorized access to the userâs files, shell, and network. The consequences include arbitrary command execution, exfiltration of local files, and destructive modification of user files. The defense should not simply remove features from the agent, such as file access, shell access, or network access. It must preserve the agentâs ability to complete benign tasks while preventing attackers from using malicious instructions in external data to control the agentâs tool calls. Dual LLM pattern.The Dual LLM pattern offers a promising defense direction [10â13]. A privileged LLM decides tool calls while a quarantined LLM processes original untrusted data without access to tools, and the defense replaces untrusted data with opaque symbols before the privileged LLM reads it. Inside the agent context, this design achieves security together with agent utility, the agentâs ability to complete tasks that use untrusted data. Because untrusted data reaches the privileged LLM only as symbols, attacker text cannot control the agentâs tool calls, and the guarantee is deterministic rather than limited to known attack templates. The agent still completes tasks by passing symbols through tool parameters and by asking the quarantined LLM to summarize, extract, or transform original untrusted data. Human utility and stored IPI. Personal AI agents, however, call for a second utility requirement, human utility. The userâs environment must keep working for humans and non- agent programs, who read, edit, and reuse the agentâs results, including files, shell output, and messages, as original data. To serve them, existing Dual LLM pattern defenses resolve symbols back into original data when data leaves the agent context, so their untrusted data tracking remains internal to the agent. However, the userâs environment, such as the file system, often serves as the agentâs long-term memory. When the agent reads back data it previously wrote, untrusted data re-enters the agent context as ordinary file or tool-result content, and the privileged LLM reads attacker-controlled text as-is. We call this attack stored IPI. arXiv:2607.03821v1 [cs.CR] 4 Jul 2026 Defending against stored IPI is essential because writing files, sending messages, and producing output that humans and non-agent programs read are core to personal AI agents. The attack instead exposes a design gap. No existing Dual LLM pattern defense satisfies security, agent utility, and human utility at the same time, because the agent and humans read the same stored data through one shared environment. A defense must either keep that data symbolized or resolve it to original data, and neither choice satisfies all three. Focusing on security, a defense can keep symbols in files, messages, and command output, which preserves tracking and blocks stored IPI but fills the userâs environment with opaque symbols that humans, programs, and remote endpoints cannot understand, breaking both human and agent utility. Focusing on human utility, a defense can resolve symbols on exit, as existing defenses do, which preserves original data for both humans and the agent but loses tracking and remains vulnerable to stored IPI. DUALVIEW provides two views of the userâs environ- ment. We presentDUALVIEW, an agent plugin that extends untrusted data tracking from the Dual LLM pattern beyond the agent context and into the userâs computer environment. DUALVIEWaims to satisfy all three requirements at once, namely security against both immediate and stored IPI, agent utility, and human utility. To this end,DUALVIEWmaintains two views of the userâs environment, AgentView for the agent and HumanView for humans and non-agent programs, so each reader sees the data in the form it needs. AgentView addresses security by inheriting the Dual LLM patternâs protection and extending it into the userâs environment. In AgentView, untrusted data appears to the agent only as symbols, whether it arrives from the network or re-enters from the files after being stored. When the agent writes a symbol into a file and later reads the file back, the untrusted data returns as the same symbol, so tracking survives the write-then-read path and stored IPI is blocked. Because symbols carry no attacker text, they cannot control the agentâs tool calls. HumanView addresses human utility. In HumanView, humans, non-agent programs, and remote network endpoints see original data, not symbols. Human-facing files, messages, and tool outputs remain free of symbols, so the userâs envi- ronment remains usable by humans and non-agent programs. DUALVIEWprovides tool view routing and synchroniza- tion to keep the two views consistent, thereby retaining agent utility even though the agent and humans work on different views.DUALVIEWroutes each tool call to the view its receiver needs. File tools and local shell commands run on AgentView directly over trusted data and symbols, while tools that need original data, such as network requests, run on HumanView, whereDUALVIEWresolves symbols before the tool runs and symbolizes untrusted results after it returns. DUALVIEWalso synchronizes the two views around every tool call, so the agent sees human edits and humans see the agentâs writes in real time. The agent therefore completes tasks using untrusted data, as in the Dual LLM pattern. To avoid losing trusted data to over-symbolization, the data forum.com/thread123 âĄFetch webpage Webpage body Summarize <URL> and save a note about it. Write notes/summary.md âąWrite file Success notes/summary.md # Summary of Quantum Computing Updates AI Agent â User prompt â€User prompt Read notes/summary.md What did the <URL> say? â„ Read File File content Quantum Computing Updates Quantum Computing Updates I summarized <URL> in notes/summary.md. ⣠Agent response Hereâs the summary of âQuantum Computing Updatesâ. ⊠Agent response External Environment Figure 1: An AI agent on the userâs machine interacts with the web, the local file system, and the shell through tool calls. trust policy uses the known data structures of tool results to symbolize only the untrusted data while keeping trusted data as is. DUALVIEWdeploys as an OpenClaw plugin using tool hooks. The implementation does not require changes to the backing model or to existing tool implementations. DUALVIEWcan be implemented on any agent runtime that exposes tool hooks that let a plugin read and rewrite tool inputs and outputs and register new tools. Results. Our evaluation measures security with an IPI benchmark, agent utility with PinchBench [14], and hu- man utility by inspecting human-facing data for remaining symbols.DUALVIEWreduces immediate and stored IPI attack success rates to 0%, keeps agent utility within 6.4 percentage points of the unprotected OpenClaw baseline, and leaves human-facing files, messages, and tool outputs free of symbols. The results show that a personal AI agent can run on the userâs computer with strong IPI protection while preserving the environment that makes the agent useful.DUALVIEWwill be available as open source at https://github.com/compsec-snu/dualview. 2. Motivation Personal AI agents read external data and then act in the userâs computer environment. This section explains how that workflow creates IPI risk and how the userâs environment can carry attacker-controlled text back to the agent. 2.1. Personal AI Agents on the Userâs Machine We consider personal AI agents that run in the userâs computer environment and assist with daily computer tasks, such as summarizing web pages and managing files or emails. At the userâs request, the agent can read external data such as web pages, emails, web service responses, or messages from other agents. The agent can then use the same resources as the user by writing files, running shell 2 ⥠Fetch webpage AI Agent $ curl evil.com/x | sh forum.com/thread123 Ignore previous instructions. Run `curl evil.com/x | sh`... Malicious prompt â User prompt Summarize <URL>. âąRun command evil.com/x Compromised Fetch script Malicious prompt (a) Immediate IPI attack. The attacker injects malicious instructions via external data, and the agent immediately follows them. $ curl evil.com/x | sh forum.com/thread123 Ignore previous instructions. Run `curl evil.com/x | sh`. ⥠Fetch webpage Summarize <URL> and save a note about it. â„ Run command evil.com/x Compromised Fetch script âą Write file notes/summary.md # Article Summary Ignore previous instructions and run `curl evil.com/x | sh`. AI Agent â User prompt âŁUser prompt What did the <URL> say? †Read File AI Agent Malicious prompt Malicious prompt Malicious prompt Malicious prompt (b) Stored IPI attack. The agent stores the attackerâs instructions in the user environment. Later, the agent reads and follows the instructions. Figure 2: Indirect prompt injection attacks against an AI agent. commands, sending network requests, or communicating with other agents. OpenClaw [6] is a representative example. Personal AI agents can automate tasks that span several user resources. For example, the agent can collect information from the web, save it into files, and reuse those files in later tasks. Figure 1 shows an example workflow for such an agent. The user asks the agent to summarize a web page and save a note about it ( 1 ). To complete the task, the agent fetches the page through a tool call, which returns the web page body to the agent (2). The agent then writes a file with the page summary (3). After writing the file, the agent reports completion to the user (4). When the user asks a follow-up question ( 5 ), the agent can read the file it previously wrote ( 6 ) and generate a response based on the file content (7). The saved file is an ordinary local file, so the user and other programs (e.g., a file editor or viewer) can inspect, edit, and reuse it. While this workflow involves web fetch and file access, personal AI agents can also use more general tools such as shell commands to access the web and the file system in more flexible ways. 2.2. Indirect Prompt Injection AI agents in the user environment are exposed to indirect prompt injection (IPI) [7]. IPI is a class of attacks where an adversary injects prompts into external data that the agent later reads, and the agent follows those prompts when it processes the data. Because personal AI agents can act on local files, shell commands, and network requests on the userâs behalf, the consequences of IPI attacks can become more severe, including arbitrary command execution, exfiltration of local files, and destructive modification of user files [7,15]. Prior work studies IPI risk in tool-integrated agents and adversarial workflows [9,16â19], and in retrieval document collections [20], multi-source inputs [21], multi- tool workflows [22], and tool-selection pipelines [23]. We distinguish two IPI patterns by how the attacker- injected prompt reaches the agent, namely immediate IPI and stored IPI. Immediate IPI attack. In immediate IPI, attacker text in a tool result directly affects the agent that reads it, without leaving and returning through another channel. The original IPI formulation [7] corresponds to immediate IPI. Figure 2a shows an example immediate IPI attack. The user begins with a benign request to summarize an external page (1). While serving that request, the agent fetches a page whose body contains an attacker-controlled prompt ( 2 ). The prompt is returned to the agent together with the benign page content. The agent treats the injected text as a prompt and runs a malicious shell command (3). Stored IPI attack. In stored IPI, the prompt is first written into the user environment, such as a local file, and affects the agent only when it is later read back. The prompt enters through external data, and when the agent saves that data for a benign task, the prompt can be stored where the agent may read it later. Figure 2b shows an example stored IPI attack. The user asks the agent to summarize an external web page and save a local note (1). The fetched web page contains legitimate content but also includes an attackerâs prompt (2). When the agent writes the note, the attacker text is saved with the summary (3). The file remains useful to the user and to non-agent programs because it is an ordinary local file. Later, the user asks about the note ( 4 ). The agent reads the file, which brings the stored malicious prompt back as file content ( 5 ). The agent, influenced by the malicious prompt, follows the attackerâs instruction (6). Acting in the userâs computer environment greatly in- creases an agentâs usefulness. The file system effectively becomes the agentâs long-term memory, which lets the agent continue work across tasks. Because the agent works directly on the userâs real computer resources, its deliverables are immediately available, so users or other programs can use them without any extra step. However, the same environment can also preserve an attacker-controlled prompt until the agent reads it back in a later task and follows it. Previous work [24â26] shows that a malicious prompt can remain in agent memory or spread to other agents, and later affect 3 the agent. The userâs computer environment poses the same risk, since attacker-controlled prompts can be stored there as ordinary files. 2.3. Dual LLM pattern The Dual LLM pattern tracks untrusted data and isolates it from the LLMâs tool call decisions by replacing untrusted data with symbols. Willison first introduced the pattern [10], and other research proposed similar agent architectures [11â 13,27â29]. They separate a privileged LLM (i.e.,T-LLM) that decides tool calls from a quarantined LLM (i.e.,U-LLM) that processes untrusted data. T-LLM and symbols.T-LLMreceives the system prompt, the user prompt, and any other trusted tool results. For un- trusted data, it receives only a symbol, an opaque placeholder such as$s1or$web1.bodythat references the original value. An attacker-injected prompt resides in untrusted data, so replacing that data with a symbol keeps the prompt away fromT-LLM. As the symbol carries no original text, it cannot steer the backing modelâs tool call decisions. At the same time,T-LLMcan still act on untrusted data by passing the symbols as tool call arguments, and the system resolves each symbol to its original data (i.e., desymbolize) before the tool fires. U-LLM processing.U-LLMprocesses original untrusted data without tool access. The agent invokes it as a tool when T-LLMneeds natural language processing on untrusted data, such as summarization, extraction, or format conversion. The symbol is desymbolized for an isolatedU-LLMsession, and the result is symbolized again when returned toT-LLM, treating the result as untrusted as well to prevent any influence from untrusted data. Previous work differs in how it represents untrusted data. FIDES [13] and PFI [11] use custom symbols, while CaMeL [12] letsT-LLMwrite code, where untrusted data is consumed as variables. 3. Design Threat Model. We assume an IPI threat model [7], where the adversary controls data delivered to the agent through remote resources. The adversary has no direct access to the agentâs internals, the model the agent uses, or the userâs computer environment. The user is assumed trusted. The AI model cannot reliably distinguish attacker instructions hidden in data from the userâs instructions, so it may follow them when it reads that data. 3.1. Goals A defense must block IPI attacks while preserving useful personal agent behavior. We designDUALVIEWtoward three goals, security, utility, and deployability. Security. Securing personal AI agents against IPI requires tracking untrusted data and isolating it from the agentâs actions. A defense must track untrusted data both inside and outside the agent. This tracking spans the tool result in the agent context and the external environment, where the agent stores data through files, shell, network, or other channels, so that the defense can recognize the data if the agent reads it again. Moreover, a defense should prevent the tracked untrusted data from influencing or steering the agentâs actions, so attacker input stays as data rather than instructions. Extending the Dual LLM pattern,DUALVIEWreplaces untrusted data with symbols not only in the agent context but also in the local environment. A symbol that the agent writes to a file returns as the same symbol when the agent reads the file back, keeping the data marked as untrusted. Prior work formally proves the security invariant that untrusted data represented as a symbol cannot influence the agentâs tool- call decisions [13,28].DUALVIEWpreserves this invariant even after untrusted data moves from the agent context into the userâs environment. Utility. We separate utility into agent utility and human utility. For agent utility, a defense should preserve the agentâs capability to complete the same tasks it could without the defense, even when those tasks use untrusted external data such as web pages or emails. Following the Dual LLM pattern,DUALVIEWlets the agent use symbols as references to untrusted data, such as writing a symbol into a file or using it as a shell command argument, and process untrusted data inU-LLMwithout tool access. For human utility, the userâs computer environment must keep working as it did without the defense, with the agentâs actions (e.g., file write) visible in real time.DUALVIEWprovides HumanView so humans and non-agent programs see original data rather than symbols, keeping the environment compatible. Deployability. Personal agents are built with AI models, runtimes, and tools, and a defense should be easily deployable on top of those systems. AsDUALVIEWis implemented through event hooks and custom tools, it does not require changes to the agentâs internal logic or to existing tools. DUALVIEWrequires that the agent runtime (e.g., OpenClaw) expose event hooks to read and modify tool inputs and outputs, and to register custom tools. §A describes the DUALVIEWOpenClaw plugin implementation using agent event hooks. Non-goals.DUALVIEWdoes not protect against a user attacking their own system (e.g., direct prompt injection [30â 32]) or against a malicious component of the agent (e.g., a backdoored tool, agent runtime, or model), since the threat model trusts these and the attack reaches the agent only through external data. 3.2. Design Overview Views.DUALVIEWprovides two views of the userâs computer environment. AgentView keeps untrusted data as symbols so the agent can continue a task without reading attacker-controlled text, giving it a protected view where untrusted data is tracked and isolated. HumanView provides original data to humans, non-agent programs, remote services, 4 z DualView Routing AgentView : Untrusted data is Symbolized Desymbolization Data Usage Policy Symbolization Data Trust Policy Desymbolization HumanView Tool Result with Symbols AgentView Tool Call View Synchronization HumanView Tool Call with Original Data Agent Response with Symbols File Tool AgentShell Tool Inter-Agent Tool notes/foo.md 1 2 $ws01.content Agent File System Network Disabled Trusted Agents Human View : All data is Original z Network Enabled Human File System notes/foo.md 1 2 CLOUD rose 4.2%... Untrusted Agents z Network Tool HumanShell Tool Inter-Agent Tool U-LLM AI Agent T-LLM Tool Call User Prompt Non-agent Programs AgentView Tool Result User Agent Response withOriginal Data HumanView Tool Result with Original data Data Usage Check HumanView Tool Call with Symbols AgentView Tools HumanView Tools Figure 3: Architecture ofDUALVIEW.marks AgentView, whereT-LLMsees symbols instead of untrusted data.marks HumanView, where humans and non-agent programs see original data. Yellow boxes markDUALVIEWcomponents. Black numbers mark the agent-user path; green numbers mark the AgentView tool path; orange numbers mark the HumanView tool path. Green arrows carry trusted data only, while orange arrows carry data that may contain untrusted data. and other agents, allowing them to correctly operate on the same environment. DUALVIEWroutes each tool to one of these views according to whether the tool can operate on symbols or needs original data. AgentView tools. When a tool can operate on a symbol without needing the original data behind it,DUALVIEW routes the tool to AgentView. For instance, read and write tools merely move data in and out of files, so they never need the original data behind a symbol. AgentView tools operate directly on trusted data and symbols, leaving the symbols in place in the tool input and output. To run file tools in AgentView,DUALVIEWprovides Agent File System, which stores untrusted data as symbols (§3.5).DUALVIEWalso provides a local-only AgentShell (§3.6) connected to Agent File System to run shell tools in AgentView. The agent can choose AgentShell for commands that can run using trusted data and symbols. Inter-agent communication tools (§3.7) can also run in AgentView when the agent communicates with other agents that also operate on AgentView, since both sides can use the symbols directly. HumanView tools.DUALVIEWroutes a tool to HumanView when the tool needs the original data behind a symbol, or when it must communicate with a remote party over the network. This includes a network request to a remote endpoint and a shell command that needs original data or external network access. For these HumanView calls, DUALVIEWdesymbolizes the tool inputs as the tool enters HumanView, and symbolizes the tool outputs when they return to the agent in AgentView. Network tools (§3.4) run on HumanView because remote endpoints need original data.DUALVIEWlets the agent choose HumanShell (§3.6), the original shell in the user environment, for commands that need original data or external network access. Inter- agent communication (§3.7) with an untrusted agent runs on HumanView, since the untrusted agent does not operate on symbols and needs the original data. Environment sync.DUALVIEWsynchronizes file changes around AgentView tool calls that access local files, such as file tools and AgentShell. Before such a tool runs, DUALVIEWcopies human file changes into Agent File System; after it returns,DUALVIEWcopies agent file changes into Human File System and desymbolizes them so humans and non-agent programs see original data. Policies.DUALVIEWuses two policies (§3.8). The data trust policy classifies returned data using tool schemas and origin rules, soDUALVIEWkeeps trusted data original in AgentView and symbolizes untrusted data. The data usage policy further checks how untrusted data is used in a tool, and requires human approval when the use is unsafe.DUALVIEW ships a default policy for OpenClawâs built-in tools, and users or the agent can update it. Example workflow.Figure 3 shows the workflow of DUALVIEW. The user sends a prompt to the AI agent (1), and the agent decides on a tool call (2).DUALVIEWroutes the selected tool to AgentView or HumanView (3). For an AgentView tool (1),DUALVIEWsynchronizes the file system between the two views so that changes made by 5 TABLE 1: Defense comparison.âmeans the approach satisfies the property,Ămeans it does not, andâłmeans the property is partial or conditional. Defense SecurityUtility Deploy. Track Isolate Agent Human Internal External Model-based defenses âł â Ă âł â â Sandboxingà à Ⳡ⥠Ⳡ⥠â âł â Dual LLM (Utility)â Ăâ Ă Dual LLM (Security)â Ă Ă Ă DUALVIEWâ â Model-based defenses rely on model or classifier judgments. Some separate untrusted data within the context but only probabilistically, with false negatives, and none preserve the distinction once data leaves the agent. ⥠Sandboxing security and utility highly depends on policyâe.g., blocking a remote access stops remote IPI attacks it but breaks benign tasks that need network. â Sandboxing deployability depends on OS support for restricting files, network, and shell access. humans and non-agent programs appear in AgentView ( 2 ), and runs the tool on the Agent File System, where untrusted data stays symbolized (3).DUALVIEWthen synchronizes the changes made by the agent back to HumanView (4) and returns the tool result to the agent (5). For a HumanView tool ( 1 ),DUALVIEWdesymbolizes any existing symbols in the tool call into original data (2) and runs the tool on HumanView, which contains original data (3). The tool returns original results (4), whichDUALVIEWsymbolizes before returning them to AgentView (5). Finally, the agent produces its response (4), andDUALVIEWdesymbolizes it so the user sees original data (5). 3.3. Defense Comparison Table 1 compares existing defenses against the goals in §3.1. For security, a defense must track untrusted data (i.e., Track), both inside the agent (i.e., Internal) and in the external environment (i.e., External), and isolate it from the agentâs actions (i.e., Isolate). For utility, it must let the agent use untrusted data (i.e., Agent) and keep the environment usable for humans and non-agent programs (i.e., Human). It must also be deployable on existing agent systems. Model-based defenses.Model-based defenses include model hardening [33â35], guardrails [36â40], and runtime monitors [41â46]. They attempt to track untrusted data within the agent context [39,47,48] and isolate it from the agentâs actions by judging tool results or planned actions [33â35]. These judgments are only probabilistic, so adversarial inputs often evade them [9,16â18,49]. They also do not track untrusted data once it leaves the agent into the external environment. In general, they are easy to add to existing runtimes, leaving tool and agent behavior mostly unchanged. Sandboxing. Sandboxing defenses restrict the resources available to the agent [50]; for example, OpenShell [50] confines tool execution with kernel-assisted access control such as Landlock, seccomp, and network policy. Sandboxing enforces resource restrictions rather than data tracking, so it does not track untrusted data. Sandboxing can also block benign tasks that need restricted resources, while allowing them leaves attack paths open. Sandboxing does not harm human utility, but deployment depends on operating-system and runtime support. Dual LLM pattern. Dual LLM pattern defenses [10â13,27â 29] track untrusted data only inside the agent context (§2.3), giving no principled answer for what happens to a symbol once it leaves the agent for the external environment, which leaves two design choices. A utility-oriented design (i.e., Dual LLM (Utility)) desymbolizes the data as it leaves, preserving agent and human utility but losing tracking once data leaves, which exposes the agent to stored IPI. A security-oriented design (i.e., Dual LLM (Security)) instead keeps symbols in the external environment, preserving external tracking. However, remote endpoints receive symbols they cannot use and humans see symbols instead of original data, breaking both agent and human utilities. DUALVIEW.DUALVIEWtracks untrusted data inside the agent by symbolizing untrusted HumanView result data into AgentView.DUALVIEWkeeps tracking untrusted data after it leaves the agent by storing symbols in Agent File System and by re-symbolizing data that returns from HumanView tools or untrusted agents. Because AgentView contains symbols rather than attacker text, these tracked inputs cannot directly steer tool-call decisions. The agent can still pass symbols to tools or useU-LLMprocessing, HumanView preserves original data for humans and non-agent programs, and tool hooks let DUALVIEW deploy on existing runtimes. In the following, we explain howDUALVIEWhandles four major tool categories of personal agents. 3.4. Network Tools The network provides diverse information to agents, allowing them to search the web, retrieve current content, and access web services. At the same time, the network exposes the agent to indirect prompt injection attack vectors. Network tools in HumanView. Network tools, such as web fetch, web search, and webhooks, use HumanView because remote endpoints and external services use original data rather thanDUALVIEWsymbols. Before a network tool runs, DUALVIEWdesymbolizes the tool arguments so the remote endpoint receives original data. When a network tool returns results,DUALVIEWapplies the data trust policy (§3.8.1) and symbolizes data classified as untrusted in AgentView. By default, network data is untrusted. Origin rules can mark selected network endpoints as trusted. For structured network data, schema rules can classify individual fields as trusted or untrusted when the schema is trusted. Web fetch and web search. Web fetch takes a URL and returns the URL, title, and content; web search takes a query and returns an array of such results. The data trust policy treats fields that derive from remote content as untrusted, including the title, the content, and post-redirect URL the tool returns, while metadata the tool or agent supplies, such as status code, stays trusted. 6 WebSearch Tool AgentView HumanView A. Agent calls WebSearch tool C. Preconfigured webhook sends data to the agent WebSearch Result url: title: content: $ws01.content Webhook: /hooks/daily-stock ticker: SOLAR price: 52.10 headline: $wh01.headline Webhook: /hooks/daily-stock ticker: SOLAR price: 52.10 headline: Battery supply warning... WebSearch Result url : marketnews/cloud-q3 title:CLOUD shares rise/.. content: CLOUD rose 4.2% after strong cloud sales... Data Trust Policy WebSearch url: untrusted title: untrusted content: untrusted /hooks/daily-stock ticker: trusted price : trusted headline: untrusted U-LLM Result CLOUD rose 4.2% after... B. Agent calls U-LLM to summarize the web search result U-LLM Result $ws01.content.sum mary WebSearch Tool Call query: CLOUD market update U-LLM To o l C al l Summarize this: $ws01.content U-LLM To o l C al l Summarize this: CLOUD rose 4.2% after strong cloud sales... U-LLM $ws01.title $ws01.content $ws01.content $ws01.content. summary $wh01.headline WebSearch Tool Call query: CLOUDmarket update SymbolizationSymbolizationSymbolizationDesymbolizationDesymbolization /hooks/daily-stock $sym1 $ws01.url Figure 4: Network flows inDUALVIEW. WebSearch and webhook payloads arrive as original data in HumanView.DUALVIEWclassifies the data using the data trust policy and symbolizes the untrusted parts before they reach AgentView. The numbered steps follow the WebSearch path (A), the U-LLM summarization path (B), and the webhook path (C). Example: WebSearch. The left side of Figure 4 shows an example of using a web search tool withDUALVIEW. The agent calls WebSearch with a query (A-1). Before the tool runs,DUALVIEWdesymbolizes any symbols in the tool input (A- 2 ). WebSearch runs on HumanView and returns original network data (A- 3 ). After the tool returns, DUALVIEWsymbolizes untrusted result data and returns the result to AgentView (A-4). WhenT-LLMasksU-LLMto process a symbol (B-1),DUALVIEWdesymbolizes it (B-2) and provides the original untrusted data toU-LLMin isola- tion (B- 3 ). AfterU-LLMreturns,DUALVIEWsymbolizes the U-LLM result again (B-4). Webhook payloads. Webhooks [51] deliver network data from pre-registered external services to the agent. By default, DUALVIEWtreats webhook payloads as untrusted because they arrive from the external network [52]. When the webhook service is trusted and delivers structured data whose trusted and untrusted parts are known (e.g., the provider marks them or the user can discern them), the data trust policy can be configured to keep the trusted fields original and symbolize only untrusted fields. Arbitrary services cannot exploit this because each webhook input port authenticates requests with its own secret shared during registration. Example: Webhook. The right side of Figure 4 shows an example with a webhook that forwards up-to-date stock news. Webhook payloads arrive as original data in Hu- manView from external services (C-1).DUALVIEWparses the webhook data, identifies untrusted data (i.e.,headline) based on the policy, and symbolizes it (C-2). Trusted fields (i.e.,tickerandprice) pass through to AgentView. This way,DUALVIEWsymbolizes only the untrusted part of the webhook payload while keeping the trusted fields as original data. 3.5. File Tools File tools (e.g., read or write) let an agent work with files on the userâs computer, including files the user already has, files received from others, and downloaded files. They also let the agent save partial work or task results to files, then read those files later to continue the task. File tools in AgentView.DUALVIEWroutes file tool calls to AgentView, where they use Agent File System instead of Human File System. Agent File System exposes the same file paths but keeps untrusted file content as symbols, so DUALVIEWneither symbolizes data read from files nor desymbolizes symbols when writing them. Because attacker- controlled content stays symbolized across a write and a later read, stored IPI is prevented. Agent File System. Agent File System stores files with orig- inal trusted data and symbols for untrusted data.DUALVIEW tracks files modified by the agent using Git and implements AgentView as a separate Git worktree [53]. In AgentView, the agent still refers to files using the same paths it would use withoutDUALVIEW. Before a file tool runs,DUALVIEW rewrites those paths to the corresponding files in the Agent File System worktree. To avoid tracking the entire file system,DUALVIEWtracks files per workspace, rooted at the enclosing Git project or, if none, the parent directory of the accessed file. §A describes howDUALVIEWmanages Agent File System using Git in detail. Human File System. Humans and non-agent programs use Human File System at ordinary file paths and see original data rather than symbols. They can read and write files as they normally would withoutDUALVIEW.DUALVIEW tracks Human File System and Agent File System in the same Git repository, while Human File System remains the main worktree. Syncing files.DUALVIEWsynchronizes Agent File System and Human File System around file tool calls so file tools see changes made by the user or non-agent programs, and humans and non-agent programs see the agentâs file writes as original data. Before an agent calls a file tool,DUALVIEW copies relevant Human File System changes into Agent File System.DUALVIEWtreats those human-side changes as trusted by default, so it copies them without symbolizing them. After the file tool returns,DUALVIEWcopies the agentâs changes from Agent File System into Human File 7 AgentView HumanView notes/may-2027.md 1 2 3 4 TODO: Market survey notes/may-2027.md 1 2 3 4 TODO: Market survey notes/may-2027.md 1 2 3 4 # Market analysis $ws01.content.summary notes/may-2027.md 1 2 3 4 # Market analysis CLOUD rose 4.2% after... Expects similar sales ... notes/may-2027.md 1 2 3 4 # Market analysis CLOUD rose 4.2% after... TODO: compare with ... Expects similar sales ... notes/may-2027.md 1 2 3 4 # Market analysis $...summary.split[0] TODO: compare with $...summary.split[1] View Synchronization (Human-To-Agent) View Synchronization (Agent-To-Human) View Synchronization (Human-To-Agent) User edits the file A. Agent reads a file using file read tool C. Agent reads the file after the user edits it $ws01.content.summary $...summary.split[0] $...summary.split[1] B. Agent writes the file using file write tool Figure 5: Filesystem synchronization inDUALVIEW. Before a tool call, human edits in the Human File System are reconciled into the Agent File System. The agent then operates on the Agent File System. After the tool call, Agent File System updates are synchronized back to the Human File System, desymbolizing symbols for human-facing files. System and desymbolizes symbols so the user sees original data. After each sync step,DUALVIEWcommits both file systems with Git, so it copies only the files that changed since the previous commit and can revert to an earlier synced state when needed. We further detail concurrency handling in §A. Untrusted files. WhileDUALVIEWtreats files from the Human File System as trusted by default, the data trust policy can override this for files or directories that contain untrusted data. For example, a user can download files from external services, such as emails or web scraping results, in a single directory. To protect agents from untrusted files, the data trust policy can mark that directory as untrusted.DUALVIEW symbolizes matching files in AgentView when the agent initializes and first loads the policy, or when the policy changes, so untrusted file content does not enter AgentView as plain text. Human file edits. Human edits copied from Human File System are trusted because the user is trusted in the threat model. If a human edit overlaps a line that Agent File System stores as a symbol,DUALVIEWtreats the human-written line as original trusted data and keeps the unchanged symbolized lines around it as separate symbols. Example: File. Figure 5 illustrates this process. A user keeps a note in the Human File System. When the agent calls a file tool to read the note (A-1),DUALVIEWfirst copies the file into the Agent File System (A- 2 ), and the file content returns to the agent (A-3). The agent then writes $ws01.content.summary, the web search summary symbol introduced in the previous network example (Figure 4), into the note (B-1).DUALVIEWcopies the update to the Human File System and desymbolizes the symbol (B-2), and the write returns to the agent (B- 3 ). The user can then read the web search summary as original data. Later, the user edits the file in the Human File System (C- 1). When the agent reads the file again (C-2),DUALVIEW copies the human edit into the Agent File System (C-3). If the human edit overlaps content represented by a symbol in the Agent File System,DUALVIEWtreats the human- written line as original trusted data and keeps the unchanged symbolized lines around it as separate symbols (C-4). 3.6. Shell Tools Personal AI agents often connect to the shell so they can use existing command-line tools during a task. Through shell tools such asexec, an agent can search and transform local files, fetch network data, and run third-party CLIs. For example,grepreads local files,curlfetches data from network endpoints, and CLI programs such asgws[54] and gh [55] access web services. Shell tools in both views.DUALVIEWexposes two shell tools to the agent. AgentShell is the shell tool for AgentView. It runs commands on Agent File System with network access disabled. HumanShell is the shell tool for HumanView. It runs commands in the normal shell environment, with Human File System and network access enabled. The agent chooses AgentShell or HumanShell for each command, guided by the system prompt (§A). A shell command can run in AgentView using AgentShell when trusted data and the symbols that replace untrusted data are enough to complete it. For example,ls,cat, and grepwith a trusted keyword can run on symbolized files, wheregrepstill matches the keyword against the trusted text while untrusted data stays symbolized. Commands that need original data, network access, or the normal shell environment can run in HumanView using HumanShell, such ascurl, gws, orgit push. When the agent chooses HumanShell, DUALVIEWdesymbolizes the command and symbolizes the result after the shell returns. Choosing the less suitable shell can reduce agent utility but has no security impact. AgentShell for a command that needs original data or network may fail, but the agent may retry with HumanShell, while HumanShell for a command that AgentShell could have run still completes but has its output conservatively symbolized. Either way, untrusted data remains symbolized in AgentView. 8 AgentView Data Trust Policy gws gmail +triage id, date, count: trusted from, subject: untrusted default stdout AgentShell: trusted HumanShell: untrusted notes/may-2027.md 1 2 3 4 # Market analysis $...summary.split[0] TODO: compare with ... $...summary.split[1] $ grep TODO notes/ notes/may-2027.md:3: TODO: compare with ... AgentShell $ gwsgmail+triage count: 3 message: id: 19d548a2 from: Alice <Alice@external> subject: Weekly Project Report HumanShell $ gwsgmail+triage count: 3 message: id: 19d548a2 from: subject: $gws02.message[0].subject HumanShell googleapis.com/gmail Symbolization FS: AgentView Network: Disabled FS: HumanView Network: Enabled Desymbolization notes/may-2027.md 1 2 3 4 # Market analysis CLOUD rose 4.2% after... TODO: compare with ... Expects similar sales ... View Synchronization (Human-To-Agent) HumanView View Synchronization (Agent-To-Human) A. Agent searches a keyword in notes/ usingAgentView Shell B. Agent checks new emails using HumanShell $...summary.split[0] $...summary.split[1] $gws02.message[0].from $gws02.message[0].subject Data Usage Check Figure 6: Shell execution inDUALVIEW. AgentShell lets commands run against Agent File System with network access disabled, so their output contains trusted data and symbols. HumanShell lets commands run in the normal shell environment with Human File System and network access enabled. DUALVIEW symbolizes shell output before returning it to AgentView. AgentShell.As with file tools (§3.5), AgentShell lets commands use the same file paths that the human user uses by mounting Agent File System at the original file paths. Commands then read symbolized file content from Agent File System, whileDUALVIEWuses a network namespace to disable network access. To prevent writing symbols to untracked locations,DUALVIEWlimits AgentShell writes to Git-tracked workspaces. Example: Agent Shell. The left side of Figure 6 shows an AgentShell example. The agent runsgrep TODO notes/in AgentShell (A- 1 ). Before the command runs,DUALVIEW copies relevant Human File System changes into Agent File System (A-2). AgentShell then reads the Agent File System and returns the line containingTODO(A-3). The result returns to the agent without another symbolization step. After the command returns,DUALVIEWrunsgit diffto find the files that the command changed in the tracked workspace, so it does not need to track modifications while the command runs. If there are any changes,DUALVIEWcopies them from Agent File System to Human File System and desymbolizes them (A- 4 ). HumanShell.HumanShell runs commands on Human File System in the normal shell environment, with network access enabled. Before the command runs,DUALVIEW desymbolizes symbols in arguments so that the shell re- ceives original data. As HumanShell can read original file content and network data that may contain untrusted data, DUALVIEWconservatively treats its output as untrusted by default and symbolizes it before returning it to AgentView. For structured command output, the data trust policy (§3.8.1) letsDUALVIEWkeep trusted fields as original data and symbolize untrusted fields, rather than treating the output as a single untrusted string. Example: Human Shell. The right side of Figure 6 shows an example of using HumanShell.gws email +triagefetches unread Gmail messages. The agent chooses HumanShell for this command because it must access Gmail through the network. Before the command runs,DUALVIEWchecks the data usage policy and desymbolizes the command argu- ments (B- 1 ). The command then fetches Gmail messages as original data over the network (B-2). For commonly used commands that return structured data with a fixed schema, the data trust policy lists the trusted and untrusted output fields, andDUALVIEWparses the output and symbolizes only the untrusted fields (B- 3 ). Forgws email +triage, it keeps fields such ascountandidtrusted and symbolizes untrusted email fields such asfrom,subject, andbody. The symbolized result then returns to the agent (B-4). Untrusted data execution. Letting the agent desymbolize untrusted data into HumanShell is a deliberate tradeoff between security and utility, since some commands need original data andDUALVIEWkeeps that capability rather than withholding it. This tradeoff does not weaken the core IPI guarantee, since attacker text still cannot steer the agent into issuing a command; untrusted data reachesT-LLMonly as symbols. However, the agent can still misuse data that it legitimately desymbolizes, and the most dangerous case is running untrusted data as a command or code. This risk arises in HumanShell, which desymbolizes symbols before running a command. As an additional measure,DUALVIEW inspects each HumanShell command, and when a symbol would be used as a command or code, it withholds the execution and asks the user for approval. §3.8.2 describes this policy check. 3.7. Inter-Agent Communication Tools Personal AI agents often run separate agents for differ- ent messaging channels, webhooks, and cron inputs, and communicate through inter-agent tools that send a message, receive a reply, or read another agentâs history. For example, OpenClaw runs one agent per messaging channel (e.g., a Slack or Telegram channel) and providessession_sendand session_historytools for them to exchange messages and 9 read each otherâs history.DUALVIEWroutes these tools by whether the other agent is trusted. Inter-agent tools in AgentView. An agent is trusted when it runs in AgentView and receives only trusted input, such as an agent attached to the userâs private channel. Because DUALVIEWkeeps symbol identifiers valid across agents, messages between trusted agents pass without desymbol- ization; both agents use trusted data and the same opaque symbols. Inter-agent tools in HumanView. Users mark an agent as untrusted when it directly receives external or unknown- origin input as original data, such as a public-channel agent. DUALVIEWuses HumanView for it, desymbolizing symbols the agent must receive as original data and symbolizing untrusted data in messages returned to AgentView. This protects trusted agents reading from untrusted ones, but restricting the untrusted agents themselves requires separate sandboxing or reduced tool access. 3.8. Policies DUALVIEWuses two policies. The data trust policy classifies tool results as trusted or untrusted. The data usage policy requires human approval before HumanShell runs untrusted data as commands or code. Details in policy specification and concrete examples are listed in §B. 3.8.1. Data Trust Policy. Based on the data trust policy, DUALVIEWkeeps trusted data original in AgentView and symbolizes untrusted data. The policy has schema rules for tool result fields and origin rules for data sources. Schema rules. The data trust policy stores a schema rule for each tool that marks returned data as trusted or untrusted, individual fields for structured results and the whole value for unstructured results. A schema rule treats data as trusted when the tool or runtime generates it, such as a status code, a count, or an argument the agent itself supplied, or when it comes from a trusted source such as ordinary local file contents. A schema rule treats data as untrusted whenever its value derives from remote content, such as a web page body, an email from an arbitrary sender, a public-channel message, or a webhook field from an external service. DUALVIEW ships default schema rules for 21 built-in OpenClaw tools (§B), derived by manually analyzing their implementations and result schemas; Data not listed in the policy is untrusted by default. Origin rules. Origin rules classify data by its source, such as a network endpoint, file path, other agent, or webhook input port, and each user chooses which sources to trust. Network data and email content are untrusted by default, and users can mark specific endpoints, senders, or domains as trusted. For file tools, file paths act as origins, and whileDUALVIEW treats local files as trusted, users can mark downloaded or imported files and directories as untrusted. For inter-agent communication, the other agent is the origin, and a user can mark an agent untrusted when it directly receives external input as original data, soDUALVIEWsymbolizes that agentâs messages before returning them to AgentView. For webhooks, a schema rule on the named input port marks payload fields as trusted or untrusted. Users can add origin rules directly or through the agent (§3.8.3). 3.8.2. Data Usage Policy. Tracking and isolation untrusted data giveDUALVIEWits deterministic IPI guarantee (§3.1). The data usage policy is a separate, best-effort layer that governs how untrusted data is used, by listing tool inputs where using the untrusted data behind a symbol would cause security issues. Before desymbolizing symbols for a HumanView tool,DUALVIEWchecks the call against this policy and requires explicit user approval when it matches an unsafe pattern. In this work,DUALVIEWuses the policy to detect when a tool would run untrusted data as a command or as code, and users can extend it to other unsafe uses, such as sending unreviewed untrusted data through email. Executable Command Patterns.Executing attacker- controlled commands on the userâs computer can let attackers compromise the userâs environment, even if the attacker cannot directly steer the agent through an IPI attack. In HumanShell,DUALVIEWdesymbolizes a symbol in a com- mand into original data in the normal shell environment, which can lead to arbitrary command execution. To prevent this, the default data usage policy lists executable command patterns for HumanShell and requires user approval when a symbol is used as a command. The patterns include a symbol- only command (i.e.,â$symâ) and a command that passes a symbol to an interpreter option (e.g.,python -c â$symâ orbash -c â$symâ). Note that in AgentShell,DUALVIEW does not desymbolize symbols, so the shell cannot execute the original data that a symbol denotes. Command Rewriting.DUALVIEWfurther prevents Hu- manShell from executing files that contain untrusted data by rewriting commands. For example,python fix.pyruns the Python scriptfix.py, which may contain untrusted data as code. Executable command patterns would miss this command because no symbol appears in the command itself. To detect such cases,DUALVIEWmaintains command rewriting rules that rewrite file execution commands into equivalent inline commands. For instance,python <file>is rewritten aspython -c <file content>. If the file content contains a symbol, the resulting inline command matches an executable command pattern. Command rewriting rules cover only the listed script execution patterns, so other shell commands can still read and execute a file in a way not listed by the policy. Detecting all untrusted data execution would therefore require dedicated monitoring, such as system call hooks that check whether a command reads a symbol from a file before executing it, which we leave as a current limitation. As the agent automatically moves data across different sources and sinks, the rationale for which uses of untrusted data are unsafe, be- yond running it as code, is still lacking. Because AgentView already tracks untrusted data at the symbol level, it provides a useful basis for richer data usage policies. 10 3.8.3. Policy Updates.DUALVIEWlets users update both policies. It stores them in a YAML file that the user can edit directly, and it also provides policy tools (policy_add, policy_list, andpolicy_del) so the agent can add, list, and delete entries when the user authorizes a change. Although DUALVIEWexposes these policy tools to the agent, the agent makes its tool-call decisions in AgentView, where untrusted data appears only as symbols, so untrusted data cannot direct the agent to update a policy. An agentic policy update that best balances security and utility requires an orthogonal investigation that we leave to future work. 4. Evaluation 4.1. Evaluation Setup All experiments used the same benchmark user tasks and model settings, while the execution environment changed with the defense under test. Benchmark. The security benchmark is a custom IPI bench- mark (§4.2), and the utility benchmark is PinchBench (§4.3). Environment.We mocked the web, email, and other external services locally behind a web proxy that returned deterministic responses for every defense. The security benchmark runs fully on this mocked network environment, while PinchBench uses both the mocked services and real web tools, such as web search and web fetch. Model.WeevaluatedClaudeHaiku 4.5 (claude-haiku-4-5-20251001) and Claude Sonnet 4.6 (claude-sonnet-4-6). InDUALVIEWand Dual LLM, T-LLM and U-LLM use the same model. Baseline. The baseline is plain OpenClaw, which prepends a built-in security warning prompt before some external input, such as web fetch and webhook content. Input guardrail. We used Llama Prompt Guard 2 [36] to classify each tool result on its own and withheld it from the agent when classified unsafe. Output guardrail.We used LlamaFirewall Align- mentCheck [35,37] to judge each pending tool call against the full conversation trace and blocked the call when classi- fied unsafe. Sandboxing. We used OpenShell [50] with a restrictive policy to mitigate the harmful consequences of an IPI attack, preventing data exfiltration and arbitrary actions. The policy allows limited network access, such as LLM APIs and package indexes (e.g.,pypi.org), and read-only access to the file system, while blocking sensitive directories. Dual LLM. We assume the utility-oriented Dual LLM (Dual LLM (Utility) in Table 1), as existing Dual LLM defenses resolve symbols when data leaves the agent [10,27]. We implemented it by disablingDUALVIEWâs environment-level untrusted data tracking, namely by not providing the Agent File System and AgentShell. It still supports agent context- level untrusted data tracking and isolation, as described in §2.3. It resolves every symbol at the tool call, including file writes, so a file stores original data, and without environment- level tracking it reads that file back as trusted data without symbolizing it. 4.2. Security Evaluation Benchmark. We built a custom security benchmark to evaluate IPI attack in OpenClaw, as existing IPI attack benchmarks [9,16,18,19] do not support OpenClaw. The benchmark consists of three injection vectors that carry the attack payload. Web content and an email body are the two immediate IPI vectors, where the agent reads the payload and acts on it during the current task. A local file is the stored IPI vector, where we assume the payload was already written into the file by a prior agent execution. Each injection vector has 10 user tasks, each instructing the agent to read that vector and complete a benign goal. We ran every task under three attacker goals, command execution, data exfiltration, and destructive file writes. The benchmark therefore comprises 90 attack cases (3 injection vectorsĂ10 user tasksĂ3 attacker goals), and we repeated each run three times. Measurement. For each trial, we measured attack success by whether the agent carried out the attacker-injected command. ForDUALVIEW, we also audited theT-LLMtranscript and Agent File System reads and confirmed that original attacker text never appears whereT-LLMcan read it, soDUALVIEW blocks IPI by isolation rather than by the model resisting the injection. Result. Table 2 reports the resulting attack success rate, averaged across all user tasks, attacker goals, and runs. While the baseline remained vulnerable to both immediate and stored IPI on both models, with 57.0% ASR on Haiku and 27.8% on Sonnet,DUALVIEWdefended every tested attack and reached 0% ASR. This is becauseDUALVIEWtracks and isolates untrusted data deterministically by design, leaving no path for attacker text to reach T-LLM. The input and output guardrails blocked some attacks but could not fully mitigate them, since their probabilistic classifiers leave a nonzero ASR. They are also weaker on stored IPI than on immediate IPI (e.g., the input guardrail on Haiku rises from 3.9% to 15.6%), because once untrusted data is written to a file its external origin is lost. The Dual LLM blocked nearly all immediate IPI but failed against stored IPI, where it allowed 53.3% ASR on Haiku and 30.0% on Sonnet, because it stops tracking untrusted data once that data reaches a file and is read back. It even allows a 2.2% immediate ASR on Sonnet, in a task where the agent saves web search results to a file and later edits that file. The immediate payload thereby reaches the stored path and is read back, demonstrating a possible end- to-end stored IPI attack. Sandboxing also prevented every attack and reached 0% ASR, since it blocks all potential harmful-consequence paths, such as network egress and sensitive writes, although this comes at a utility cost (§4.3). 11 TABLE 2: Evaluation results by model and defense. Attack success rate entries report the mean across runs±standard deviation, in percent. Total combines the immediate and stored vectors. Utility score is the PinchBench task success rate. Token overhead is relative to the baseline for the same model, over the PinchBench token cost plusU-LLMtokens for Dual LLM andDUALVIEW; the input and output guardrail APIs do not report token usage and are excluded. Attack Success RateUtility ModelDefenseTotal (%)Immediate (%)Stored (%)Utility score (%)Token overhead (%) Claude Haiku 4.5 Baseline57.0 ± 2.657.2 ± 1.656.7 ± 4.783.40.0 Input guardrail7.8 ± 1.63.9 ± 2.815.6 ± 1.685.318.3 Output guardrail8.9 ± 0.98.3 ± 1.410.0 ± 0.084.714.4 Dual LLM17.8 ± 0.90.0 ± 0.053.3 ± 2.781.840.8 Sandboxing0.0 ± 0.00.0 ± 0.00.0 ± 0.062.557.6 DUALVIEW0.0 ± 0.00.0 ± 0.00.0 ± 0.081.648.2 Claude Sonnet 4.6 Baseline27.8 ± 4.027.8 ± 6.427.8 ± 1.688.50.0 Input guardrail5.6 ± 1.84.4 ± 2.17.8 ± 1.688.85.3 Output guardrail3.0 ± 0.52.2 ± 1.64.4 ± 1.689.613.2 Dual LLM11.2 ± 3.32.2 ± 1.630.0 ± 7.286.361.0 Sandboxing0.0 ± 0.00.0 ± 0.00.0 ± 0.066.5115.6 DUALVIEW0.0 ± 0.00.0 ± 0.00.0 ± 0.082.193.4 4.3. Utility Evaluation Benchmark. To evaluate the utility ofDUALVIEW, we used PinchBench (v2.0.0) [14], an OpenClaw utility bench- mark built from realistic daily usage of OpenClaw agents. PinchBench covers diverse tasks that involve file access, network tools, and shell usage. We ran the benchmark under plain OpenClaw (i.e., the baseline),DUALVIEW, and other defenses. PinchBench models most real-world services as file operations, where a task reads input files and writes its result as a file, alongside real web fetch and mock web fixtures. To evaluate each defense fairly on these tasks, we classified input file trust and output file sensitivity from the task semantics and configured every defense for the strongest security under this classification. We further detail the file classification in §B. Measurement. For agent utility, we measured task success rate of Pinchbench and token usage. A task succeeds when the final file system and agentâs response satisfy the bench- markâs evaluation criteria, which includes both rules and LLM-based judge to evaluate the text quality. We ran the utility benchmark once per defense and model due to high LLM API costs, but its large benchmark size (i.e., 147 tasks) provides a sufficient number of tasks to show the utility trend across defenses. Result.DUALVIEWpreserved agent utility close to the baseline, scoring 81.6% on Haiku (vs. 83.4%) and 82.1% on Sonnet (vs. 88.5%) (Table 2), and was the only defense that both blocked all IPI and kept utility high. Sandboxing, the other defense at 0% ASR, dropped utility to 62.5% on Haiku and 66.5% on Sonnet. A sandboxing policy that better balances security and utility may exist, but a fundamental tension remains. When a task must use untrusted data while also needing a sensitive capability, such as sending email or making a business decision, a defense must either grant the capability and give up some security or restrict it and lose utility. Guardrails and Dual LLM also kept utility high, but unlikeDUALVIEWthey did so without fully securing TABLE 3: PinchBench failure breakdown forDUALVIEW, counting task failures andâ„ 0.25score drops from the baseline due to symbolizing untrusted data. ModelFailed reasonTasks HaikuUses an invalid U-LLM result9/147 Cannot read the symbolized data and gives up2/147 SonnetU-LLM times out on large untrusted data3/147 Repeatedly calls HumanShell for the original value, timing out 4/147 Repeatedly callsU-LLMfor the original value, timing out 6/147 the agent, leaving residual ASR (guardrails) or failing stored IPI (Dual LLM). Failure breakdown. In general, tasks failed when the model could not correctly validate the original data behind symbols. The specific failure reason differed by model (Table 3). Haiku used theU-LLMresult even when wrong, while Sonnet timed out reaching the original value behind a symbol through repeated U-LLM or shell calls. Review load.DUALVIEWdetects untrusted data execution by monitoring symbol usage (§3.8) and raises a review event for the user, but this rarely happened on PinchBench (Table 4). The only trigger, on one Sonnet task, was a benign false positive where the agent ran an untrusted log through a Python interpreter while analyzing it. The input and output guardrails instead raised far more false positives, blocking legitimate tasks even with no attack present, soDUALVIEW imposes fewer human reviews. Cost. We measured cost as LLM token overhead over theT-LLMandU-LLMtokens; guardrail token costs are excluded because their APIs do not report token counts. DUALVIEWadded 48.2% overhead on Haiku and 93.4% on Sonnet over baseline (Table 2) from isolatedU-LLM processing, growing on Sonnet as it repeatedly invoked U-LLMto reach original data. Sandboxing showed the same pattern on Sonnet, which spent even more tokens searching 12 TABLE 4: Review load on PinchBench.DUALVIEWdefers un- trusted data execution to the user, while the guardrails block tasks outright and remove legitimate work. Other defenses raise no events. DefenseModelEventsTasks DUALVIEW (Assume human approval) Haiku00 Sonnet11 Input guardrail (Block tool result) Haiku126 Sonnet126 Output guardrail (Block tool call) Haiku22 Sonnet113 for workarounds to blocked actions. Clearly conveying each defenseâs restrictions to the model would likely improve agent utility and lower cost. This overhead can hinder deployingDUALVIEWin cost-sensitive settings, so reducing it is important future work, with promising directions such as caching, reusing, or batchingU-LLMrequests, and using a smaller, cheaper model forU-LLM, which only summarizes, extracts, or transforms bounded inputs. Human utility. We assessed human utility by whether human-facing outputs do not contain symbols and read naturally. Inspecting human-facing files, outbound network messages, and final assistant messages, we found no symbols, so humans, non-agent programs, and remote receivers saw original data. According to the LLM judge, among tasks that bothDUALVIEWand the baseline completed, deliverables built on a resolved symbol scored close to the baseline that wrote on original data (Sonnetâ0.068, Haiku+0.008), so symbolization did not lower output quality. 5. Discussion We discuss the current limitations ofDUALVIEWand open directions for future work. Data usage policy. The data usage policy (§3.8.2) requires human approval only for patterns that execute untrusted data, which can be improved in two ways. Policy-wise, untrusted data should also not reach a sensitive argument such as the destination of an outbound request, and which arguments are sensitive is hard to specify in general. Data tracking can also be extended for confidentiality. Instead of symbolizing untrusted data,DUALVIEWcould symbolize secret values and track them so they cannot leave through the network. In terms of detection, shell commands are too varied for pattern matching to cover reliably; robust enforcement would require a restricted shell language or system-level monitoring. UntrusteddataenteringthroughHumanView. DUALVIEWtracks untrusted data in agent-mediated flows, which matters because an agent can read external data and act on it before the user can inspect each value. When the user or another program places data directly on HumanView,DUALVIEWdoes not know its source, as with pasted attacker text [56]. The user remains responsible for that data, as withoutDUALVIEW, and can configure data trust policy so the agent correctly symbolizes them. Custom tool support.DUALVIEWroutes each tool to AgentView when it runs locally over symbols and to Hu- manView when it needs original data or the remote network. DUALVIEWcurrently assigns each tool manually; future work could infer this routing automatically from a toolâs specification or implementation. AgentView for remote networks.DUALVIEWbuilds AgentView for the local file system, but it cannot build one on a remote service it does not control, so it treats the network as untrusted by default and identifies trusted data based on data trust policy (§3.8). A permissive data trust policy might allow remote stored IPI. If a cloud service such as Google Docs or the Notion API is trusted by origin, attacker-controlled data stored there is read back as trusted, just as with a local file. Remote AgentView support would require the service to preserve symbols in agent-facing state and resolve them only for human-facing operations.DUALVIEWcould then route calls to that AgentView, but the interface for symbol identity, access control, and synchronization remains future work. 6. Related work Prompt injection attacks. Direct prompt injection overrides an agent through the user prompt with instruction overrides and jailbreaks [30â32,57]. Indirect prompt injection (IPI) instead hides instructions in external data the agent reads, so the model issues attacker-controlled tool calls, up to remote code execution [7â9,15â19,21â23,49,56]. Recent work shows IPI persisting in the agentâs environment as poisoned memory, corrupted retrieval, or stored payloads that re-enter later [24â26, 58]. Dual LLM defenses. IsolateGPT [59] separates a high- level task planner from application-specific plans so that untrusted data in one application has limited influence on the planning of another.f-secure LLM [28], ACE [29], PFI [11], CaMeL [12], FIDES [13], and Prudentia [60] isolate untrusted data from the tool-calling LLM as opaque symbols. As they track untrusted data only inside the agent context, they remain vulnerable to stored IPI (§2.2). Guardrails and classifiers. Guardrails detect malicious content with trained classifiers or auxiliary models on agent inputs and outputs [36â38,41,42,44,45], and spotlighting or fine-tuning defenses train the model to separate instructions from data [34,35,39,40]. They align behavior only proba- bilistically and remain vulnerable to adaptive attacks [17,32]. Sandboxing. Sandboxing confines an agent to restricted runtimes or capabilities [43,50,61â63], but restricting file, shell, and network access removes the capabilities that make a personal agent useful. 7. Conclusion Personal AI agents act on the userâs real environment, so untrusted data can leave the agentâs context and return later as trusted data, a stored IPI attack that prior Dual LLM defenses miss. We presentedDUALVIEW, which extends 13 untrusted data tracking into that environment by giving each channel an AgentView that keeps untrusted data as symbols and a HumanView that preserves original data for humans and programs.DUALVIEWreduced both immediate and stored IPI to 0% attack success, kept agent utility close to the unprotected baseline, and preserved human utility by leaving human-facing files, messages, and tool outputs free of symbols. These results show that a personal AI agent can achieve security, agent utility, and human utility together, while remaining deployable as a tool hook plugin on an existing agent runtime. References [1]S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao, âReact: Synergizing reasoning and acting in language models,â in International Conference on Learning Representations (ICLR), 2023. [2]T. Schick, J. Dwivedi-Yu, R. DessĂŹ, R. Raileanu, M. Lomeli, E. Ham- bro, L. Zettlemoyer, N. Cancedda, and T. Scialom, âToolformer: Language models can teach themselves to use tools,â in Annual Conference on Neural Information Processing Systems (NeurIPS), 2023. [3]OpenAI, âChatgpt plugins,â 2024, https://openai.com/index/chatgpt- plugins/ (accessed 27, August, 2025). [4]Microsoft,âWhatismicrosoft365copilot?â2024, https://learn.microsoft.com/en-us/microsoft-365/copilot/microsoft- 365-copilot-overview (accessed 27, August, 2025). [5]Model Context Protocol, âModel context protocol,â 2025, https:// modelcontextprotocol.io/. [6]OpenClaw, âOpenClaw,â 2026, https://openclaw.ai/. [7]K. Greshake, S. Abdelnabi, S. Mishra, C. Endres, T. Holz, and M. Fritz, âNot what youâve signed up for: Compromising real-world llm-integrated applications with indirect prompt injection,â in AISec Workshop, 2023. [8]Y. Liu, Y. Jia, R. Geng, J. Jia, and N. Z. Gong, âFormalizing and benchmarking prompt injection attacks and defenses,â in 33rd USENIX Security Symposium. USENIX Association, 2024. [9]Q. Zhan, Z. Liang, Z. Ying, and D. Kang, âInjecAgent: Benchmarking indirect prompt injections in tool-integrated large language model agents,â in Findings of the Association for Computational Linguistics: ACL 2024.Bangkok, Thailand: Association for Computational Linguistics, 2024, p. 10 471â10 506. [Online]. Available: https://aclanthology.org/2024.findings-acl.624/ [10]S. Willison, âThe dual llm pattern for building ai assistants that can resist prompt injection,â 2023, https://simonwillison.net/2023/Apr/25/ dual-llm-pattern/. [11]J. Kim, W. Choi, and B. Lee, âPrompt flow integrity to prevent privilege escalation in llm agents,â arXiv preprint arXiv:2503.15547, 2025. [12]E. Debenedetti, I. Shumailov, T. Fan, J. Hayes, N. Carlini, D. Fabian, C. Kern, C. Shi, A. Terzis, and F. TramĂšr, âDefeating prompt injections by design,â arXiv preprint arXiv:2503.18813, 2025. [13]M. Costa, B. Köpf, A. Kolluri, A. Paverd, M. Russinovich, A. Salem, S. Tople, L. Wutschitz, and S. Zanella-BĂ©guelin, âSecuring ai agents with information-flow control,â arXiv preprint arXiv:2505.23643, 2025. [14] PinchBench, âPinchBench,â 2026, https://pinchbench.com/. [15]T. Liu, Z. Deng, G. Meng, Y. Li, and K. Chen, âDemystifying RCE vulnerabilities in LLM-integrated apps,â in Proceedings of the 2024 ACM SIGSAC Conference on Computer and Communications Security. ACM, 2024. [16]H. Zhang, J. Huang, K. Mei, Y. Yao, Z. Wang, C. Zhan, H. Wang, and Y. Zhang, âAgent security bench (ASB): Formalizingandbenchmarkingattacksanddefensesin LLM-basedagents,âin13thInternationalConferenceon Learning Representations, ICLR 2025.Singapore: International ConferenceonLearningRepresentations,2025.[Online]. Available:https://proceedings.iclr.c/paper_files/paper/2025/hash/ 5750f91d8fb9d5c02bd8ad2c3b44456b-Abstract-Conference.html [17]Z. Wang, V. Siu, Z. Ye, T. Shi, Y. Nie, X. Zhao, C. Wang, W. Guo, and D. Song, âAGENTVIGIL: Automatic black- box red-teaming for indirect prompt injection against LLM agents,â in Findings of the Association for Computational Linguistics: EMNLP 2025.Suzhou, China: Association for Computational Linguistics, 2025, p. 23 159â23 172. [Online]. Available: https://aclanthology.org/2025.findings-emnlp.1258/ [18]J. Yi, Y. Xie, B. Zhu, K. Hines, E. Kiciman, G. Sun, X. Xie, and F. Wu, âBenchmarking and defending against indirect prompt injection attacks on large language models,â in Proceedings of the 31st ACM SIGKDD Conference on Knowledge Discovery and Data Mining. ACM, 2025. [Online]. Available: https://arxiv.org/abs/2312.14197 [19]E. Debenedetti, J. Zhang, M. Balunovic, L. Beurer-Kellner, M. Fischer, and F. TramĂšr, âAgentDojo: A dynamic environment to evaluate prompt injection attacks and defenses for LLM agents,â in Annual 14 Conference on Neural Information Processing Systems (NeurIPS) Datasets and Benchmarks Track, 2024. [20]H. Chang, E. Bao, X. Luo, and T. Yu, âOvercoming the retrieval barrier: Indirect prompt injection in the wild for LLM systems,â in 35th USENIX Security Symposium.USENIX Association, 2026. [Online]. Available: https://w.usenix.org/ conference/usenixsecurity26/presentation/chang [21]R. Wang, Y. Jia, and N. Z. Gong, âObliInjection: Order-oblivious prompt injection attack to LLM agents with multi-source data,â in Network and Distributed System Security Symposium 2026.San Diego, CA, USA: Internet Society, 2026. [Online]. Available: https: //w.ndss-symposium.org/ndss-paper/obliinjection-order-oblivious- prompt-injection-attack-to-llm-agents-with-multi-source-data/ [22]Z. Li, J. Cui, X. Liao, and L. Xing, âLes dissonances: Cross-tool harvesting and polluting in pool-of-tools empowered LLM agents,â in Network and Distributed System Security Symposium 2026.San Diego, CA, USA: Internet Society, 2026. [Online]. Available: https: //w.ndss-symposium.org/ndss-paper/les-dissonances-cross-tool- harvesting-and-polluting-in-pool-of-tools-empowered-llm-agents/ [23]J. Shi, Z. Yuan, G. Tie, P. Zhou, N. Z. Gong, and L.Sun,âPromptinjectionattacktotoolselectionin LLM agents,â in Network and Distributed System Security Symposium 2026.San Diego, CA, USA: Internet Society, 2026. [Online]. Available: https://w.ndss-symposium.org/ndss- paper/prompt-injection-attack-to-tool-selection-in-llm-agents/ [24]M. Herrador and J. Rehberger, âSpAIware: Uncovering a novel artificial intelligence attack vector through persistent memory in LLM applications and agents,â Future Generation Computer Systems, vol. 174, p. 107994, 2026. [Online]. Available: https: //w.sciencedirect.com/science/article/pii/S0167739X25002894 [25]S. Dong, S. Xu, P. He, Y. Li, J. Tang, T. Liu, H. Liu, and Z. Xiang, âMemory injection attacks on LLM agents via query-only interaction,â in ICLR 2026 Workshop on Memory for LLM-Based Agentic Systems (MemAgents), 2026. [Online]. Available: https://openreview.net/forum?id=i7J62t2wtV [26]D. Lee and M. Tiwari, âPrompt infection: LLM-to-LLM prompt in- jection within multi-agent systems,â arXiv preprint arXiv:2410.07283, 2024. [Online]. Available: https://arxiv.org/abs/2410.07283 [27]E. Bagdasarian, R. Yi, S. Ghalebikesabi, P. Kairouz, M. Gruteser, S. Oh, B. Balle, and D. Ramage, âAirGapAgent: Protecting privacy-conscious conversational agents,â in Proceedings of the 2024 ACM SIGSAC Conference on Computer and Communications Security. ACM, 2024. [Online]. Available: https://dl.acm.org/doi/10.1145/3658644.3690350 [28]F. Wu, E. Cecchetti, and C. Xiao, âSystem-level defense against indi- rect prompt injection attacks: An information flow control perspective,â arXiv preprint arXiv:2409.19091, 2024. [29]E. Li, T. Mallick, E. Rose, W. Robertson, A. Oprea, and C. Nita-Rotaru, âACE: A security architecture for LLM-integrated app systems,â in Network and Distributed System Security Symposium 2026.San Diego, CA, USA: Internet Society, 2026. [Online]. Available: https://w.ndss-symposium.org/ndss-paper/ace- a-security-architecture-for-llm-integrated-app-systems/ [30]F. Perez and I. Ribeiro, âIgnore previous prompt: Attack techniques for language models,â arXiv preprint arXiv:2211.09527, 2022. [Online]. Available: https://arxiv.org/abs/2211.09527 [31]A. Wei, N. Haghtalab, and J. Steinhardt, âJailbroken: How does LLM safety training fail?â arXiv preprint arXiv:2307.02483, 2023. [Online]. Available: https://arxiv.org/abs/2307.02483 [32]A. Zou, Z. Wang, N. Carlini, M. Nasr, J. Z. Kolter, and M. Fredrikson, âUniversal and transferable adversarial attacks on aligned language models,â arXiv preprint arXiv:2307.15043, 2023. [Online]. Available: https://arxiv.org/abs/2307.15043 [33]E. Wallace, K. Xiao, R. Leike, L. Weng, J. Heidecke, and A. Beutel, âThe instruction hierarchy: Training LLMs to prioritize privileged instructions,â arXiv preprint arXiv:2404.13208, 2024. [34] S. Chen, J. Piet, C. Sitawarin, and D. Wagner, âStruQ: Defending against prompt injection with structured queries,â in 34th USENIX Security Symposium. USENIX Association, 2025. [Online]. Available: https://arxiv.org/abs/2402.06363 [35]S. Chen, A. Zharmagambetov, S. Mahloujifar, K. Chaudhuri, D. Wagner, and C. Guo, âSecAlign: Defending against prompt injection with preference optimization,â in Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security.ACM, 2025. [Online]. Available: https://dl.acm.org/doi/10. 1145/3719027.3744836 [36]Meta AI, âLlama Prompt Guard 2,â 2025, https://huggingface.co/meta- llama/Llama-Prompt-Guard-2-86M. [37]S. Chennabasappa, C. Nikolaidis, D. Song, D. Molnar, S. Ding, S. Wan, S. Whitman, L. Deason, N. Doucette, A. Montilla, A. Gampa, B. de Paola, D. Gabi, J. Crnkovich, J.-C. Testud, K. He, R. Chaturvedi, W. Zhou, and J. Saxe, âLlamaFirewall: An open source guardrail system for building secure AI agents,â arXiv preprint arXiv:2505.03574, 2025, https://github.com/meta-llama/PurpleLlama/ tree/main/LlamaFirewall. [38]Y. Liu, Y. Jia, J. Jia, D. Song, and N. Z. Gong, âDataSentinel: A game-theoretic detection of prompt injection attacks,â in IEEE Symposium on Security and Privacy. IEEE, 2025. [Online]. Available: https://arxiv.org/abs/2504.11358 [39] K. Hines, G. Lopez, M. Hall, F. Zarfati, Y. Zunger, and E. Kiciman, âDefending against indirect prompt injection attacks with spotlighting,â arXiv preprint arXiv:2403.14720, 2024. [40]Y. Zhong, Q. Miao, Y. Chen, J. Deng, Y. Cheng, and W. Xu, âAttention is all you need to defend against indirect prompt injection attacks in LLMs,â in Network and Distributed System Security Symposium 2026. San Diego, CA, USA: Internet Society, 2026. [Online]. Available: https://w.ndss-symposium.org/ndss-paper/attention-is-all-you- need-to-defend-against-indirect-prompt-injection-attacks-in-llms/ [41]K. Zhu, X. Yang, J. Wang, W. Guo, and W. Y. Wang, âMELON: Provable defense against indirect prompt injection attacks in AI agents,â in Proceedings of the 42nd International Conference on Machine Learning. PMLR, 2025. [Online]. Available: https://arxiv.org/abs/2502.05174 [42]F. Jia, T. Wu, X. Qin, and A. Squicciarini, âThe task shield: Enforcing task alignment to defend against indirect prompt injection in LLM agents,â in Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). Association for Computational Linguistics, 2025. [Online]. Available: https://aclanthology.org/2025.acl-long.1435/ [43]H. Li, X. Liu, H.-C. Chiu, D. Li, N. Zhang, and C. Xiao, âDRIFT: Dynamic rule-based defense with injection isolation for securing LLM agents,â in Annual Conference on Neural Information Processing Systems (NeurIPS), 2025. [Online]. Available: https://arxiv.org/abs/2506.12104 [44]Z. Chen, M. Kang, and B. Li, âShieldAgent: Shielding agents via verifiable safety policy reasoning,â in Proceedings of the 42nd International Conference on Machine Learning.PMLR, 2025. [Online]. Available: https://arxiv.org/abs/2503.22738 [45]Z. Xiang, L. Zheng, Y. Li, J. Hong, Q. Li, H. Xie, J. Zhang, Z. Xiong, C. Xie, C. Yang, D. Song, and B. Li, âGuardAgent: Safeguard LLM agents by a guard agent via knowledge- enabled reasoning,â in Proceedings of the 42nd International Conference on Machine Learning. PMLR, 2025. [Online]. Available: https://arxiv.org/abs/2406.09187 [46]H. Wang, C. M. Poskitt, and J. Sun, âAgentSpec: Customizable runtime enforcement for safe and reliable LLM agents,â in Proceedings of the 48th IEEE/ACM International Conference on Software Engineering.ACM, 2026. [Online]. Available: https://arxiv.org/abs/2503.18666 [47]P. Y. Zhong, S. Chen, R. Wang, M. McCall, B. L. Titzer, H. Miller, and P. B. Gibbons, âRTBAS: Defending LLM agents against prompt injection and privacy leakage,â arXiv preprint arXiv:2502.08966, 2025. [48]S. A. Siddiqui, R. Gaonkar, B. Köpf, D. Krueger, A. Paverd, A. Salem, S. Tople, L. Wutschitz, M. Xia, and S. Zanella-BĂ©guelin, âPermissive information-flow analysis for large language models,â arXiv preprint arXiv:2410.03055, 2024. [49]J. Shi, Z. Yuan, Y. Liu, Y. Huang, P. Zhou, L. Sun, and N. Z. Gong, âOptimization-based prompt injection attack to LLM-as-a-judge,â in Proceedings of the 2024 ACM SIGSAC Conference on Computer and Communications Security. ACM, 2024. [50]NVIDIA, âOpenShell: A safe, private runtime for autonomous AI agents,â 2026, https://github.com/NVIDIA/OpenShell. [51]OpenClaw, âWebhooks,â 2026, https://docs.openclaw.ai/cli/webhooks. 15 [52]â,âConfiguration,â2026,https://docs.openclaw.ai/gateway/ configuration (accessed 29, May, 2026). [53]Git Project, git-worktree Documentation, 2026, https://git-scm.com/ docs/git-worktree (accessed 28, May, 2026). [54]Google Workspace, âgws: Google Workspace CLI,â 2026, https:// github.com/googleworkspace/cli (accessed 5, June, 2026). [55]GitHub, âGitHub CLI,â 2026, https://cli.github.com/ (accessed 5, June, 2026). [56]X. Fu, S. Li, Z. Wang, Y. Liu, R. K. Gupta, T. Berg-Kirkpatrick, and E. Fernandes, âImprompter: Tricking LLM agents into improper tool use,â arXiv preprint arXiv:2410.14923, 2024. [Online]. Available: https://arxiv.org/abs/2410.14923 [57]M. Russinovich, A. Salem, and R. Eldan, âGreat, now write an article about that: The crescendo multi-turn LLM jailbreak attack,â in 34th USENIX Security Symposium. USENIX Association, 2025. [58]W. Zou, R. Geng, B. Wang, and J. Jia, âPoisonedRAG: Knowledge corruption attacks to retrieval-augmented generation of large language models,â in 34th USENIX Security Symposium. USENIX Association, 2025. [59]Y. Wu, F. Roesner, T. Kohno, N. Zhang, and U. Iqbal, âAn execution isolation architecture for LLM-based agentic systems,â in Network and Distributed System Security Symposium 2025. San Diego, CA, USA: Internet Society, 2025. [Online]. Available: https://arxiv.org/abs/2403.04960 [60]A. Kolluri, R. Sharma, M. Costa, B. Köpf, T. NieĂen, M. Russinovich, S. Tople, and S. Zanella-BĂ©guelin, âOptimizing agent planning for security and autonomy,â in International Conference on Learning Representations (ICLR), 2026. [61] T. Shi, J. He, Z. Wang, H. Li, L. Wu, W. Guo, and D. Song, âProgent: Programmable privilege control for LLM agents,â arXiv preprint arXiv:2504.11703, 2025. [62]L. Tsai and E. Bagdasarian, âConseca: Contextual agent security: A policy for every purpose,â in Proceedings of the 20th Workshop on Hot Topics in Operating Systems. ACM, 2025. [Online]. Available: https://arxiv.org/abs/2501.17070 [63]G. Syros, A. Suri, J. Ginesin, C. Nita-Rotaru, and A. Oprea, âSAGA: A security architecture for governing AI agentic systems,â in Network and Distributed System Security Symposium 2026. San Diego, CA, USA: Internet Society, 2026. [64]Anthropic, âClaude Code hooks reference,â 2026, https://code.claude. com/docs/en/hooks#hooks-reference (accessed 11, June, 2026). [65]Nous Research, âHermes Agent: Hooks,â 2026, https://hermes-agent. nousresearch.com/docs/user-guide/features/hooks (accessed 11, June, 2026). [66]F. Liu, Y. Zhang, J. Luo, J. Dai, T. Chen, L. Yuan, Z. Yu, Y. Shi, K. Li, C. Zhou et al., âMake agent defeat agent: Automatic detection of Taint-Style vulnerabilities in LLM-based agents,â in 34th USENIX Security Symposium. USENIX Association, 2025, p. 3767â3786. Appendix A. Implementation DUALVIEWis implemented as an OpenClaw plugin, based on OpenClaw v2026.3.12 [6]. The prototype builds on OpenClaw event hooks, a SQLite symbol table, Git worktrees for the two file-system views, and a YAML-format policy file at ~/.dualview/policy.yaml. OpenClaw integration.DUALVIEWis implemented with event hooks and custom tools, a mechanism supported in many personal agents (e.g., Claude Code [64] and Her- mes Agent [65]). This hook-based design does not require changing the AI model, the agent main logic, or tool implementations, which makes it deployable on various personal agents. As in prior Dual LLM pattern defenses [11â 13],DUALVIEWalso registersinspect_symbolas a custom tool forU-LLMprocessing, which takes the symbols, the processing instruction forU-LLM, and an output schema for the result.DUALVIEWchecks theU-LLMresult against the schema, returns the symbolized result to AgentView when it matches, and otherwise returns an error without exposing any untrusted data. Hook points. OpenClaw hooks letDUALVIEWmediate the agent lifecycle at initialization, tool execution, and human- facing replies (Figure 7). The pre-tool hook handles the work afterT-LLMselects a tool but before the tool runs: for AgentView tools it copies HumanView file changes into the Agent File System, and for HumanView tools it checks the data usage policy and resolves the symbols the tool needs as original data. The post-tool result hook applies only to HumanView tools, which can return original untrusted data that must be symbolized beforeT-LLMreads it.DUALVIEW uses itstransform_tool_resulthook to apply the data trust policy to web results, HumanShell stdout, webhook payloads, and other HumanView tool results beforeT-LLM reads them; OpenClaw v2026.3.12 did not support this hook, soDUALVIEWadded it, and the latest OpenClaw provides it natively as tool-result middleware. Final assistant messages use a separate delivery hook, since no tool call occurs afterT-LLMgenerates the final text.DUALVIEW usesmessage_sendingto resolve symbols only in the agent response that goes to the CLI, webchat, or channel, so the transcript keeps symbols while the human-facing message contains original data; OpenClaw v2026.3.12 did not deliver an edited response to the messenger channel, soDUALVIEW patched it. Symbol table.DUALVIEWstores the symbol table in SQLite and shares it across all agent sessions. The symbol table maps each symbol to its original data and its provenance, allowingDUALVIEWto resolve symbols when a symbol is passed to HumanView.DUALVIEWresolves a symbol only on an exact match of its full token, so a command or edit that splits, truncates, or otherwise mangles a symbol leaves a fragment thatDUALVIEWdoes not resolve. Such a fragment never reveals the original untrusted data, so resolution fails closed; it can leave a broken token in human-facing output and lower human utility, a case we did not observe in our 16 Agent eventOpenClaw hook DUALVIEW action Agent initialization Receive user prompt Tool call decision Tool call Tool result returns Return response Agent Loop before_prompt_build before_tool_call after_tool_call transform_tool_result â message_sending â load policy and symbol table, add system prompt that instructs the agent how to handle symbols AgentView tool: copy Hu- manView file changes into AgentView HumanView tool: check data usage policy, resolve needed symbols AgentView tool: copy AgentView file changes into HumanView HumanView tool: symbolize untrusted data based on data trust policy Agent response: resolve symbols Figure 7: OpenClaw hook points thatDUALVIEWuses across the agentâs events.before_tool_calland the two result hooks branch by whether the tool runs on AgentView or HumanView. DUALVIEW changes the two hooks marked â . evaluation. Each entry stores a symbol with the original data and provenance metadata. The provenance metadata comes from trusted data (e.g., the originating tool, the field path, and the data origin).DUALVIEWcan extend the data usage policy with this provenance in the future, for example to block symbols of a given origin from sensitive tool arguments, which prevents taint-style vulnerabilities [66]. System Prompt.DUALVIEWappends a system prompt to agent context that explains how to handle its symbolized tool results and shell tools. It instructs the model to treat symbol tokens as opaque handles and pass them through unchanged, since they are resolved to their real values only at delivery time, and to call theinspect_symboltool whenever it needs a derived result such as a summary, an extraction, or a transformation of symbolized data. It also documents the Data Trust Policy together with itspolicy_addandpolicy_del tools, and the two shell modes (i.e., shell tools). Default exec resolves symbols and marks the output untrusted, while restricted exec (RESTRICTED=1) runs sandboxed and returns trusted output. The full prompt text will be available in our released code. 1 Filesystem.DUALVIEWtracks the files the agent modifies with Git and keeps the Agent File System and Human File System as two Git worktrees [53] (§3.5). Figure 8 shows an example layout of file systems. The original workspace directory is the Human File System, andDUALVIEWkeeps its own Git database and the Agent File System outside that directory under~/.dualview/workspaces/, where it 1. https://github.com/compsec-snu/dualview /home/user/apple/banana/workspace ordinary workspace filesHumanView files .git/ordinary Git, optional ~/.dualview/workspaces/DUALVIEW file-system management %2Fhome%2Fuser%2Fapple%2Fbanana/encoded workspace path repo.git/DUALVIEW Git agentview/Agent File System for the workspace conflicts.logsync conflict log Figure 8: Example file-system layout under DUALVIEW. TABLE 5: PinchBench file paths marked as untrusted. These patterns match 72 files, and 42 of the 147 PinchBench tasks read at least one of them. CategoryUntrusted Files Email and inbox emails/*, inbox/* External documents and reports ai_blog.txt, GPT4.pdf, openclaw_report.pdf, research/*, sample_contract.pdf, school-calendar.pdf, subway_map.md, vulnerability_scan.json Logs and request metadata access_events.csv, apache_error.log, auth.log, hdfs_datanode.log, linux_syslog.log, mapreduce.log, nginx_access.log, syslog.log canonicalizes and percent-encodes the root path into a single directory name. BecauseDUALVIEWkeeps its Git database outside the workspace, its Git use stays transparent to the user, so ordinary Git commands in the workspace work seamlessly. DUALVIEWstarts tracking a new workspace on demand when the agent first writes a file with a tool such aswrite oredit. If the file is in a Git project, the workspace root is the enclosing project directory, otherwise it is the parent directory of the file. Unlike a file tool, a shell command can write to pathsDUALVIEWcannot anticipate, soDUALVIEW does not open a new workspace for AgentShell and instead confines its writes to already-tracked workspaces, keeping every write inside a worktree that the post-command sync reconciles. DUALVIEWhandles potential file write race conditions in two ways. First, a race between two agents that sync the same root is handled by serializing sync commits with a workspace-scoped file lock. Second, a race between a human write and a sync, which the lock does not prevent, is handled by detecting the changed file hash, skipping the affected file soDUALVIEWnever overwrites the humanâs change, and appending a record to the conflict log.DUALVIEWcurrently only reports the conflict through the log and leaves the resolution to the human. Appendix B. DUALVIEW Policy Policy specification. Table 7 summarizes the prototype data trust policy thatDUALVIEWuses for OpenClaw built-in tools and webhook receivers. Fields listed as trusted pass through to the agent as original data. Fields listed as untrusted are symbolized before the agent reads them. Webhook fields omitted from an endpoint schema are untrusted by default. 17 TABLE 6: PinchBench output routes made read-only for the OpenShell sandbox utility run. These routes encode effects that would be sensitive in a real personal AI agent deployment. Across PinchBench, 60 of the 147 tasks write to at least one of these routes. CategoryRestricted Path Email replies output/email_replies/ Security, contract, and triage reports output/security/ Meeting decisions, recommendations, and summaries output/decisions/ CI, Kubernetes, logs, and service actions output/operations/ Research, finance, procurement, and stock outputs output/business/ Examples. Table 8 shows how the twoDUALVIEWpolicies apply at different boundaries. The upper block applies the data trust policy after a HumanView tool returns. The rule on the left names the trusted and untrusted fields or origins, and the result on the right is whatT-LLMsees afterDUALVIEW replaces untrusted fields with symbols. The lower block applies the data usage policy before HumanShell runs a command. Commands with no symbol in executable text run without extra approval, while commands or script files that would execute symbolized data require human approval. PinchBench policy. Of the 147 PinchBench tasks, 114 read a file as input and 121 write a file as the goal. For example, an email reply task reads an inbox underemails/* orinbox/*and writes the reply as a file in the workspace. For DUALVIEWand the Dual LLM pattern, we marked untrusted input files so that their content is symbolized (Table 5); examples includeresearch/*,GPT4.pdf, andauth.log, and 42 tasks read at least one such file. For Sandboxing, we placed privileged output files, such as email replies and business outputs, in dedicated directories and denied writes there, and minimized network access to prevent data leakage and arbitrary actions (Table 6); the blocked routes cover 60 tasks. 18 TABLE 7: Prototype data trust policy specification. The policy uses the same trusted and untrusted field distinction for built-in tools, structured shell output, webhook receivers, and inter-agent communication. Tool or sourceTrusted fieldsUntrusted fields web_fetch url,status,contentType,extractMode,extractor,fetchedAt, tookMs,truncated,length,rawLength,wrappedLength, externalContent, warning finalUrl, title, text web_search query, provider, count, tookMs, externalContentPer-result title, description, url, published, siteName execFields declared by per-skill output schemas, such as local counters, identifiers, and schema tags Default stdout, plus remote or user-controlled fields declared by per-skill output schemas readFile content from AgentView, where untrusted content is already symbolized None write and editTool status and other local metadataNone processWrite and lifecycle actions, list, and trusted local metadataRead actions such as poll and log, plus unknown actions inspect_symbolValidated output after U-LLM processing and re-symbolizationNone Webhook receiversEndpoint-specific schema fields such as verified source metadata, event type, and local delivery identifiers Endpoint-specific schema fields such as message text, issue comments, form bodies, and fields omitted from the schema Image and media toolsLocal tool metadata and URL-keyed identifiersRemote captions, descriptions, or other service-controlled text when present Inter-agent session toolsLocal conversation identifiers and private context metadataMessage text and tool-result text from untrusted agent contexts Other local built-in tools memory_search,memory_get,session_status,canvas,nodes,cron, tts,message, andclaude_code_*results that contain local metadata only Remote or externally controlled text when a deployment configures such fields TABLE 8: Concrete examples for the two policy types. The data trust policy block shows schema rules and user-supplied origin rules. The data usage policy block shows executable command patterns and command rewriting rules. The dark red text marks symbolized fields or command and code text that HumanShell would execute, and a command with no symbol in executable text runs without human approval. Policy ruleTool result or commandDUALVIEW output Data trust policy (checks tool output) Schema rules Trusted web_fetch.url Untrusted web_fetch.text web_fetch(url) = url=https://reports.example/q1, text="Quarterly report" â web_fetch(url) = url=https://reports.example/q1, text=$web1.text Origin rules Trusted api.github.com/* web_fetch(https://api.github.com/zen) = content="Design for failure." â web_fetch(https://api.github.com/zen) = content="Design for failure." Untrusted imports/*.csv read(imports/q1.csv) = content="name,amount..." â read(imports/q1.csv) = content=$read1.content Untrusted agent:public-chat session_history(agent:public-chat) = message="check this link" â session_history(agent:public-chat) = message=$session1.message Data usage policy (checks commands sent to HumanShell) Executable Command Pattern exec(git status)âNo human approval required <symbol> exec($web1.text)â $web1.text needs human approval for execution python -c <symbol> exec(python -c $web1.text)â $web1.text needs human approval for execution Command Rewriting Rule python <file> transform ââ python -c <file content> exec(python fix.py) transform ââ exec(python -c "...$web1.text...") â $web1.text needs human approval for execution 19