From Prompt Injection to Persistent Control: Defending Agentic Harness Against Trojan Backdoors

Image generated by AI

TLDR

• What: Tan et al. (arXiv 2026) introduce ClawTrojan, a benchmark exposing how multi-step trojan attacks persistently compromise agentic workspace files, and DASGuard, a provenance-tracking runtime defense that detects and sanitizes unauthorized control text.
• Who's at risk: IDE-integrated coding assistants (e.g., Cursor, Claude Code), terminal-wrapping local agents (e.g., OpenClaw, Devin), and personal automation workflows that persist state across multiple sessions.
• Key number: Without defense, GPT-5.4 is highly vulnerable, yielding a 95.5% Attack Success Rate (ASR) on ClawTrojan, which DASGuard successfully slashes to 15.8%.

As LLM-powered systems transition from ephemeral web chatbots to autonomous, state-retaining coding agents like Claude Code, Cursor, and OpenClaw, security vulnerabilities are shifting from transient prompt injection to long-lived repository compromise. Tan et al. (arXiv 2026) expose a severe paradigm shift: attackers no longer need to execute an obviously malicious payload in a single turn. Instead, they can split stealthy, natural-looking rules across multiple local files and tool outputs. When the agent reads these files across subsequent turns, it treats them as persistent instructions, allowing attackers to achieve remote, multi-step control over the local workspace.

Threat Model

Background & Problem Setup

Traditional defenses evaluate prompt injections as single-turn, context-window threats. However, modern models have grown highly capable of recognizing and ignoring obvious injection contaminants within a single context window. As a result, older datasets like InjecAgent (Zhan et al., 2024) and AgentDojo (Debenedetti et al., 2024) yield a near-zero attack success rate against modern models like GPT-5.4 in default configurations (see Table 9 of the paper).

By contrast, multi-step trojan attacks target the agent's persistent local workspace state. A benign-looking note added in step 1 is saved to disk; in step 4, a user query prompts the agent to read this note, adopting the malicious rule as a legitimate project policy.

Comparison of Security Benchmarks & Defenses

Methodology

1. The ClawTrojan Benchmark

ClawTrojan comprises 362 samples (339 attack chains and 23 borderline negative controls) spanning 1,672 annotated sandbox steps across coding, research, office, and general scenarios. Each attack chain follows a long-horizon pipeline:

1. Recon Context: Understands the workspace environment.
2. Build Trust: Completes normal tasks to bypass simple guards.
3. Hidden Instruction: Plants a misleading rule in a local file (e.g., a README or test config).
4. Task Pivot: Steers the agent toward the hidden rule.
5. Last-Chance Action: Discloses secrets, falsifies documents, or executes unauthorized terminal tasks.

2. DASGuard Defense Architecture

DASGuard operates at the harness boundary. Instead of asking "Is the current input malicious?", it tracks "Has untrusted text become a future instruction?"

[Agent Proposes File Edit/Action]
             │
             ▼
┌──────────────────────────────┐
│  1. Runtime Content Detection│ ---> Scans edited diffs using rules & embeddings
└────────────┬─────────────────┘
             │
             ▼
┌──────────────────────────────┐
│  2. Potential Control Attr.  │ ---> Evaluates source graph H_t (Track provenance)
└────────────┬─────────────────┘
             │
             ▼
┌──────────────────────────────┐
│  3. Runtime Policy / Sanitize│ ---> Blocks high-risk action OR Sanitizes file before write
└──────────────────────────────┘

A. Content-Source Graph ($H_t$)

DASGuard models the workspace as a directed graph where nodes $v \in V_t$ are text spans (e.g., user inputs, file blocks, tool returns) and edges $E_t$ denote derivations. It assigns each span a source label:

B. Joint Detection Score

For every proposed write, DASGuard evaluates whether a span $s$ acts as control-bearing text using:

Where:

• $R(s)$ is rule matching.
• $E(s)$ is an embedding-space match against known directive styles.
• $M(s)$ matches DASGuard's historical findings.

If $D(s)$ exceeds a safety threshold, DASGuard calculates an attribution score, checks against user authorization facts, and calculates a final risk score:

If the risk is high, DASGuard either blocks the execution outright (for irreversible external side-effects) or sanitizes the payload by stripping the backdoor commands before writing to the actual workspace disk.

Key Results

Tan et al. (arXiv 2026) evaluated standard LLMs and contemporary defenses on the positive split of ClawTrojan. The results demonstrate that classic defenses fail to stop multi-step attacks because they do not track data lineage across turns.

Defense Performance on ClawTrojan (GPT-5.4 Base Agent)

Ablation Study of DASGuard Components

Table 6 demonstrates that omitting source labels (provenance tracking) completely guts the defense, sending ASR back up to 92.7%.

Limitations & Open Questions

1. False Positive Rates: While highly secure, DASGuard incurs a 13.0% False Positive Rate (FPR) on clean/borderline samples (see Table 5), resulting in a 13.0% overblocking/unnecessary sanitization rate. This could cause friction in fast-paced local developer workflows.
2. Harness Integration Dependence: DASGuard assumes that the operating environment can observe every file write, mock tool return, and memory access to construct the content-source graph $H_t$. Closed-source or monolithic agent platforms that mask terminal outputs will require extensive custom instrumentation to support DASGuard.
3. Adaptive Evaders: Extremely clever red-teamers could design "fragmented payloads" where instructions are broken down grammatically across ten separate files. If no single file contains control-like semantics, DASGuard's embedding match $E(s)$ might fail to flag the individual edits.

What Practitioners Should Do

If you are building or deploying local developer agents (e.g., Cursor-style setups or custom AutoGPT instances), implement the following mitigations:

1. Deploy Shadow-Copy Sandboxing: Never allow an LLM agent to write directly to your workspace repository. Intercept all file-writing tool calls, write them to an isolated shadow directory, and diff the changes.
2. Enforce Hard Boundaries on Configuration/Memory Files: Treat files like .cursorrules, task_settings.yaml, .github/workflows/, and local agent databases as highly sensitive. Implement static patterns to block any agent write to these destinations unless explicitly confirmed by a human-in-the-loop (HITL) prompt.
3. Track Content Provenance: For any text block loaded into the prompt context, attach a metadata tag indicating its source (e.g., [Source: Local File (Trusted)] vs. [Source: Web Search (Untrusted)]). Instruct the system prompt to explicitly treat untrusted source blocks as raw data parameters, never as command directives.

The Takeaway

As AI agents assume real-world operations in our local workspaces, we must abandon the assumption that standard context-window sanitization is sufficient. Tan et al. (arXiv 2026) prove that persistent workspace files are the ultimate trojan delivery mechanism. Securing the future of agentic workflows requires treating data strictly as data—enforcing strict provenance boundaries so that external content can never write its own future execution rules.

Den's Take

Let's stop pretending that prompt injection is just a single-turn problem. The real threat to modern enterprise agents isn't a clever adversarial suffix in a chat window; it is persistent, multi-step state poisoning in local workspaces. If you are deploying tools like Claude Code or Cursor on a developer's workstation inside a Fortune 500 company, ClawTrojan's 95.5% attack success rate on GPT-5.4 should terrify you. An attacker doesn't need to break your API firewall if they can drop a stealthy instruction into a README or test file that the agent processes five steps later.

This directly builds on my previous analysis in Hijacking Agent Memory: Stealthy Trojan Attacks Through Conversational Interaction, where I explained how persistent memory acts as a massive, unmonitored attack surface that allows adversaries to bypass traditional single-turn guardrails.

I'm excited about DASGuard's provenance-tracking runtime defense because it targets the actual root cause—the lack of context-origin tracking. We cannot trust LLMs to police their own inputs when those inputs are fetched dynamically from a compromised local environment. If we don't start tracking where an agent's instructions originate, we are essentially giving a $50M corporate repository's keys to whatever random text files happen to be lying around.