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

They report a 95.5% attack success rate on GPT-5.4. That sounds suspect—until you realize the attack doesn't happen in a single prompt. Instead, it is planted like a sleeper cell across multiple files and tool outputs.

As LLM agents evolve into operational tools, they gain access to local workspaces. They can read and write files, call tools, and reuse state across sessions. This creates a massive new attack surface. Current security research focuses on single-turn prompt injections (attempts to influence a single interaction). These aim to stop a malicious instruction from affecting the immediate conversation. However, attackers are moving toward "multi-step trojan attacks." In these, they embed tiny, seemingly benign instructions into a file or a tool output. The agent reads this content and stores it in its workspace. It then executes it as a command later. Because no single step looks malicious, traditional defenses are blind.

The Problem

The status quo in agent security relies on boundary defenses and context inspection. These methods act as gatekeepers. They look at the current input or the immediate action to see if it violates a safety policy. This works for a "smash and grab" attack. That is a single malicious prompt demanding data exfiltration.

But in an agentic harness (a runtime environment wrapping an LLM with local tools and memory), the attack is a slow burn. As shown in, an attacker can spend several steps building trust.

They place "hidden instructions" into local notes or configurations. By the time the agent performs a harmful action, the malicious logic is already part of the trusted workspace state. Existing defenses like MELON or PromptShield often fail here. They lack "provenance"—the ability to trace text back to its original, untrusted source. They might block the final explosion, but they fail to stop the planting of the fuse.

How It Works

The authors propose DASGuard, a dynamic defense. It protects the persistent workspace rather than just the transient conversation. The architecture shifts the focus. It asks: "Did this untrusted content just become a permanent instruction?"

The system operates through three main stages, as illustrated in :

1. Runtime Content Detection: DASGuard maintains a content-source graph ($H_t$). Every piece of content is assigned a label: Trusted, Clean, or Untrusted. The detector identifies "control-bearing spans" (text segments that look like directives). It uses rule matching, embedding similarity, and a history of prior findings.
2. Potential Control Attribution: Once a candidate span is identified, the system attributes it to a source, a destination, and a control role. The destination might be memory or policy files. It calculates an attribution score by checking if the content matches explicit authorizations from the user.
3. Runtime Policy and Sanitization: Instead of just blocking, DASGuard uses a tiered response. For low-risk writes, it can "sanitize" the content. This removes the backdoor while allowing benign parts of the file to be committed. For high-risk operations, such as executing a command, it triggers a hard block.

Crucially, DASGuard carries these findings across steps. If a piece of text was flagged as untrusted in step 2, the system remembers it. If the agent tries to copy that text into a "trusted" configuration file in step 5, the system intervenes.

Numbers

The authors evaluate their work using ClawTrojan. This is a new benchmark featuring 362 samples simulating long-horizon attacks. The results highlight a massive gap between current model capabilities and defense efficacy.

The paper reports that a raw GPT-5.4 model reaches a 95.5% Attack Success Rate (ASR) on ClawTrojan. In contrast, existing single-turn prompt-injection benchmarks like AgentDojo produce near-zero ASR on the same model. This proves that modern LLMs have solved simple injections but remain vulnerable to persistent workspace trojans.

When comparing defenses, most baselines struggle significantly. They maintain high ASRs because they only inspect individual turns. DASGuard drops the step ASR to 15.8%. More importantly, it reduces the Full-Chain ASR (the rate at which an entire multi-step attack succeeds) to just 5.9%. This reduction means the defense successfully breaks the attack chain before completion.

The trade-off involves error rates. Looking at, DASGuard concentrates interventions at low "chain penetration." This means it stops attacks early in the sequence.

However, this comes at a cost to utility. The paper reports a False Positive Rate (FPR) of 13.0% and a clean-task preservation rate (utility) of 87.0% in [Table 5]. This indicates that the defense can be aggressive. It occasionally flags legitimate but complex workspace updates as threats.

What's Missing

The paper is a strong proof-of-concept, but there are gaps.

First, the benchmark is currently synthetic. It is restricted to a sandboxed, OpenClaw-style environment. Real-world agentic workflows may involve much noisier data flows. These could trigger higher false positives than the 13% reported here.

Second, the defense assumes high "instrumentation" in the agent harness. The harness must intercept file writes and track the provenance of every string. It must also manage a shadow workspace for sanitization. If you use a closed-source agent API, implementing this defense becomes a significant engineering undertaking.

Finally, the paper does not explore adaptive attackers. The ablation study in [Table 6] shows that removing source labels destroys the defense. However, it does not address whether an attacker could "launder" untrusted text. They might do this by passing it through multiple benign transformations to bypass detectors.

Should You Prototype This

Depends on your deployment model.

If you are building a local agentic harness with write access to a filesystem, you should prototype the provenance-tracking aspect of DASGuard. The 95.5% ASR on GPT-5.4 is a loud warning. Standard prompt safety is not enough for agents.

However, do not expect a drop-in solution. Implementing the "Detect, Attribute, Sanitize" pipeline requires deep integration into your agent's runtime. Start by instrumenting your file-write and tool-call layers. Track the origin of every piece of content. If you cannot map a string back to its source, you cannot defend against this class of attack.

Code is reportedly available at: https://github.com/RUC-NLPIR/ClawTrojan.

Figures from the paper