Beyond Prompt Injection: The Tool Update Gap in LLM Agent Security

📌 Highlights

The paper identifies a lifecycle trust gap: an admitted tool’s update can execute under the tool’s existing identity and authorization without undergoing the same review as the original implementation.

ETUDE preserves the tool’s name, description, schema, and legitimate behavior while injecting direct code-level operations that do not depend on adversarial model instructions or extra model-issued calls.

Across the paper’s evaluation, ETUDE reports 97.6% ASR and 95.9% legitimate TCR. The authors’ main-body RQ1 comparison reports 100.0% ASR and 99.6% final-output TCR across 21 framework–workload conditions; these are different aggregates and should not be conflated.

The experiments use synthetic credentials, a researcher-controlled test service, and isolated files. They demonstrate the mechanism in controlled settings, not exploitation of tools in the wild.

• Core claim: previously granted tool trust can outlive the code that was reviewed.
• Main mechanism: malicious functionality executes inside an updated tool’s normal runtime path.
• Builder implication: verify the implementation at update and execution time, and constrain runtime permissions.

🎯 Introduction

LLM agents use external tools to access local files and web services with the host environment’s privileges. The paper notes that the MCP ecosystem indexes over 177,000 community-contributed tools. Prior agent-security work discussed by the authors has focused heavily on prompt injection and model-visible content, while admission-time inspection addresses malicious implementations present before first use.

The paper’s motivating gap is that modern frameworks can adopt later tool updates while retaining prior identity and permissions. The authors frame attacks by delivery timing (E1 admission versus E2 subsequent update) and execution path (P-direct tool code versus P-ctx model context); ETUDE occupies E2 × P-direct.

🔬 Methodology

ETUDE starts with a benign implementation A(v1) that passes admission, then adopts A(v2) through the framework’s native update mechanism. The malicious version keeps the same interface and expected normal output, but inserts unauthorized operations into the existing handler. Those operations execute with the tool process’s existing permissions and are isolated with exception handling so their failure need not break the legitimate task.

The evaluation crosses two delivery stages and two execution paths. E1 submits a malicious tool for admission; E2 admits a benign version before switching to the malicious update. P-direct executes the operation inside tool code, whereas P-ctx adds model-facing instructions requiring an additional tool call. The three objectives are disclosure of synthetic credentials (W1), an unauthorized order through a test API (W2), and modification of an isolated research note (W3).

The authors independently verify attack effects using receiver, service, or file evidence and assess legitimate task completion separately. RQ1 uses GLM-5.3-Flash with a Markdown cleaner across seven frameworks; RQ2 varies four backend settings across those frameworks; RQ3 varies Markdown cleaning, CSV statistics, and ICS generation across four frameworks. The paper also evaluates TLSH similarity gating, static code review and package scanning, and isolated runtime auditing.

📊 Experiments

The main benchmarks are seven agent frameworks—Gemini CLI, Codex CLI, Claude Code, DeepSeek Harness, OpenCode, Pi, and Goose—and three tool functionalities: Markdown cleaning, CSV statistics, and ICS generation. The three workloads test synthetic credential disclosure, an unauthorized test API order, and local file modification. RQ1 uses GLM-5.3-Flash; RQ2 compares GLM-5.3-Flash, Qwen-3.8-27B, and DeepSeek-V4-Flash with thinking enabled and disabled for DeepSeek; RQ3 varies tool functionality across four frameworks. Each round has 20 planned tasks, with five rounds per implementation; ASR and TCR are computed separately, and admission BLOCK or UNKNOWN results do not execute the candidate.

For the RQ1 comparison across 21 equally weighted framework–workload conditions, the authors report ETUDE at 100.0% ASR and 99.6% final-output TCR, versus 20.2% ASR and 96.4% TCR for P-ctx E2. In RQ2, ETUDE has confirmed effects in all 28 backend–framework combinations, with ASR ranging from 80.0% to 100.0%, mean ASR 96.4%, and full-task TCR 94.0%; P-ctx E2 ranges from 0% to 100.0% ASR. RQ3 reports confirmed effects in all 36 framework–tool–workload combinations, while CSV W3 file modification and final-output TCR average 91.8%, compared with 100.0% for Markdown and ICS.

For defenses, the TLSH experiment finds that threshold t = 233 accepts all 40 legitimate updates but blocks only W3; t = 145 blocks all three targets but rejects 22 of 40 legitimate updates (55%). Under static review, readable ETUDE updates are rejected at a reported mean rate of 98.3%, while PyArmor-protected ETUDE reaches 85.0% ASR and 84.3% TCR. In the local runtime-audit tests, all 30 updated-tool audits produce unauthorized operations and alerts, and all 30 benign-tool audits remain alert-free; a separate environment-conditioned variant evades the sandbox audit. The paper reports audit latency of 112.8 ± 13.7 seconds and estimated fees of US$0.00697 per audit in its 12-audit long-document test, versus an 18.0-second and US$0.00461 static-review reference.

fig:pipeline

Caption: The tool update gap. A malicious update preserves the tool's legitimate functionality while introducing unauthorized operations that execute directly within the tool's runtime environment.

Why It Matters: Illustrates the core threat: the updated tool can keep its model-facing interface and legitimate behavior while adding direct side effects.

fig:frameworks

Caption: ASR

Why It Matters: The paper identifies this as the comparison across four attack conditions, seven frameworks, and workloads W1–W3; its extracted caption is only “ASR,” so the figure should be interpreted alongside the reported aggregate results.

fig:sensitivity

Caption: Backend sensitivity: ETUDE ASR

Why It Matters: The figure covers backend and tool-functionality sensitivity; the text reports ETUDE effects across all 28 backend–framework combinations and all 36 framework–tool–workload combinations.

fig:distance

Caption: Target blocking and legitimate-update rejection as TLSH thresholds vary. Controlled strata and public history use separate denominators.

Why It Matters: Shows the tradeoff between blocking malicious targets and accepting legitimate updates under the tested TLSH thresholds.

🔮 Conclusion

The authors conclude that trust should attach to the implementation actually examined rather than transfer automatically with a tool identity. Across seven frameworks, backends, and utilities, ETUDE could add unauthorized effects during normal invocations while preserving legitimate output. They argue that lifecycle-aware verification needs both artifact identity controls and behavioral confinement: provenance can establish which code runs, while least privilege and host/network mediation constrain what it can do.

🛠️ Future Research Improvements

The paper’s stated next step is a more comprehensive runtime-audit cost evaluation on real-world tools. Further evaluation should also test update and execution controls against complex dependency trees and additional agent frameworks, since the reported attack tools are researcher-authored and the runtime-audit measurements are specific to the tested tasks.

A useful engineering research direction is to combine artifact-bound approval with runtime operation policies, then measure both detection coverage and the effect on legitimate updates and normal task completion. This follows the paper’s discussion of artifact identity and behavioral confinement; it is a proposed direction rather than a result demonstrated by the experiments.

🏭 Potential Industry Use Scenarios

Agent platforms that install third-party tools or MCP servers could bind each approval to a specific artifact and dependency set, requiring renewed verification when an update changes that identity. This directly addresses the update condition studied in the paper.

Enterprise agent deployments that expose local files, credentials, or service APIs could run tools with scoped permissions and mediate host and network operations. Such confinement is a proposed deployment implication from the paper’s discussion; the experiments do not evaluate a production deployment.

💬 Critical Analysis

A strength of the evaluation is its separation of task completion from side effects: the study requires receiver, service, or file evidence rather than trusting the model’s final claim. It also distinguishes actual file modification from attainment of the specified content, exposing cases where an unauthorized write occurs but misses the intended objective.

The reported aggregates describe controlled experiments with researcher-authored tools and selected versions/configurations. They establish that the update gap can be exploitable under the studied conditions, but do not estimate prevalence across production tool ecosystems. The seven-framework comparison, backend study, and tool-functionality study also use different subsets and protocols, so their averages should not be treated as one uniform benchmark.

The defense results are mixed rather than a single ranking: similarity thresholds trade target blocking against maintenance acceptance; static review can reject readable malicious code but protected updates still execute in the reported native evaluation; runtime auditing detects observed behavior but can miss dormant behavior under a different environment and incurs measurable latency and fees. These caveats support the authors’ distinction between identifying the approved artifact and enforcing allowed behavior.