The Tool Update Gap: Agents Keep Trusting Tools After the Code Changes
A November 1, 2026 arXiv paper shows that a benign agent tool can turn malicious through a later update, with no prompt manipulation, evading defenses that only watch model-visible content.
What is this?
On November 1, 2026, researchers from Shanghai Jiao Tong University and Inria posted “Beyond Prompt Injection: The Tool Update Gap in LLM Agent Security” (arXiv, cs.CR). The paper argues that agent frameworks establish trust in a tool once, then keep trusting it after the tool’s implementation changes. That gap turns routine software updates into a supply-chain path into the agent.
This is research on a design weakness, not a disclosed flaw in a single product.
How it works
Agents rely on external tools to call services and reach web resources, and those tools evolve through updates. The updated code executes outside the model’s context window. An attack delivered this way therefore never has to touch the prompt: there is no adversarial instruction for a model-focused defense to see.
The authors built a proof-of-concept called ETUDE (Exploiting Tool Updates for Direct Execution). It starts from a benign tool, adds malicious behavior in a later update, and keeps the tool’s legitimate functions working. They evaluated three attack workloads across seven commercial and open-source agent frameworks, including Gemini CLI, Codex CLI, and Claude Code. Reported results: a 97.6% attack success rate while legitimate tasks still completed 95.9% of the time, so the compromised tool looks healthy. They also report that existing defenses offered weak protection.
No attack code or payload details are reproduced here.
Why it matters
Most agent-security work concentrates on what the model reads: prompts, retrieved documents, tool descriptions. This result moves the problem to what the tool does at runtime. It complements earlier work such as MalTool (2026), which found that both traditional malware scanners and agent-specific defenses perform poorly at detecting malicious tool code. Together, they suggest that a one-time review at install time is not a sufficient control for tools that keep changing.
Defenses
The paper’s core recommendation is to re-verify trust whenever a tool’s implementation changes, not only at first integration. In practice:
- Pin versions. Install tools at a fixed version or hash; do not auto-update inside an agent runtime.
- Re-review on change. Treat every tool update as a new approval event, with a diff of code and declared permissions.
- Isolate execution. Run tool code in a sandbox with least-privilege file, network, and credential access, so a changed tool cannot reach what it does not need.
- Monitor behavior. Log tool network calls and file access, and alert on new destinations or unusual data volume after an update.
- Do not rely on prompt-level filters alone. They cannot see code that runs outside the context window.
Status
| Item | Detail |
|---|---|
| Source | arXiv:2611.01976 v1, submitted November 1, 2026 |
| Nature | Academic proof-of-concept across 7 agent frameworks |
| Vendor patch | Not applicable; design-level gap. Update-time verification is the recommended control |