An agent may faithfully reject malicious instructions that appear in natural-language tool descriptions and still be compromised through a different channel: the executable bytes supplied by a tool upgrade. ETUDE tests malicious updates of tools and packages installed within agent harnesses. The authors report 97.6% adversarial success while benign task…
Inspect the ClaimsCase · DiggingBeagle record
Tool updates can execute a malicious side effect before an agent reads a prompt
ETUDE shows why prompt scanning does not cover executable package updates: the tool-update boundary can carry code outside model context.
Agent package lifecycle scripts can persistently rewrite tool and memory authoritySemantic tool scope versus process filesystem authorityAgent-enabled software supply-chain attack
Public disclosure: Nov 2, 2026
Scope
Researcher-controlled tool-update scenarios; no evidence that particular legitimate marketplace releases were hijacked.
Assessment profile
Assessment method- Setting
- evaluation
- Exploitation
- demonstrated
- Evidence
- Grade B
- Remediation
- mitigation available
- AI role
- AGAINST AI
Basis and provenance
The controlled work uses multiple native reload paths, separately measured malicious effects and task completion, and confirmed file or service effects. It does not establish an infected public marketplace or a verified production incident. A version-bound tool trust decision is an architectural mitigation, not a proven comprehensive patch.. Impact is ungraded because no independently measured production-target impact or victim scope is established by this record.
Assessed Nov 4, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-NOV04-ETUDE-TOOL-UPDATE-1 · CLM-NOV04-ETUDE-TOOL-UPDATE-2 · CLM-NOV04-ETUDE-TOOL-UPDATE-3 · ETUDE: malicious agent tool updates can run before model-level inspection
At a glance
Agent security must cover the bootstrap/update path with artifact pinning, least privilege and process telemetry. A content safety monitor that reads prompts alone has no view of an executable update that runs first.
Read the implicationsEfficacy against independently packaged and signed real ecosystem updates remains to be evaluated. Reported success does not establish compromise of any specific public tool registry.
Limits and uncertaintyFull account
An agent may faithfully reject malicious instructions that appear in natural-language tool descriptions and still be compromised through a different channel: the executable bytes supplied by a tool upgrade. ETUDE tests malicious updates of tools and packages installed within agent harnesses. The authors report 97.6% adversarial success while benign task completion remained 95.9% across the evaluated systems. These are controlled test rates, not observed infections across the broader ecosystem.
The mechanism takes place before model-visible text could be classified as dangerous. A tool package imported or executed by the harness can perform side effects under the runner account regardless of whether the assistant ever decides to call a dangerous function. Consequently, tool-package origin and runtime permissions must be tested separately from prompt-injection defenses. Study.
The important transition in ETUDE is from an admitted tool implementation to a newer implementation that inherits the same tool name and earlier permission setting. The researchers exercised native reload or reconnection paths across seven agent frameworks. Where the harness asked for approval of a particular invocation, the test supplied that approval without re-reviewing the updated code. In the W3 file-modification experiment, the malicious update achieved its specified content goal in 700 of 700 planned tasks, while 698 still delivered the normal core task body. These results demonstrate a package-lifecycle gap and explain why checking the model response after tool loading can be too late. Native update paths and W3 results. Unlike archive preprocessing, the dependency already carries executable tool code and an inherited authorization.
Mechanism and trust boundary
- 01
Publish an adversarial tool update
The attacker distributes changed executable tool bytes into an update path the harness may accept as a routine dependency refresh.
Boundary: Tool supply chain to agent execution environment
- 02
Load updated code outside prompt review
The runner imports or executes package content, initiating malicious behavior without needing the model to read a command or approve it.
Boundary: Package installation and loading to operating-system authority
- 03
Complete the original agent task
The study reports that many legitimate tasks still complete, so normal-looking model output cannot prove no malicious update code ran.
Boundary: User-visible task success versus hidden process effects
Claims & evidence
CLM-NOV04-ETUDE-TOOL-UPDATE-1ETUDE reports a 97.6% successful malicious-tool-update rate across its selected experimental configurations.supported
Basis: reported finding
- supportsETUDE: malicious agent tool updates can run before model-level inspectionprimary disclosure
Evaluation, attack success rates
CLM-NOV04-ETUDE-TOOL-UPDATE-2In the same evaluation, benign task completion remained 95.9%, indicating malicious side effects need not visibly interrupt user tasks.supported
Basis: reported finding
- supportsETUDE: malicious agent tool updates can run before model-level inspectionprimary disclosure
Evaluation, benign task utility
CLM-NOV04-ETUDE-TOOL-UPDATE-3In the W3 evaluation, the updated tool attained the specified malicious file content in 700 of 700 tasks, while the ordinary core task body was delivered in 698 of 700.supported
Basis: reported finding
- supportsETUDE: malicious agent tool updates can run before model-level inspectionprimary disclosure
Section 5.2, Table 3 and Appendix B, W3 research-note modification
Implications
Agent security must cover the bootstrap/update path with artifact pinning, least privilege and process telemetry. A content safety monitor that reads prompts alone has no view of an executable update that runs first.
Controls and mitigations
- Pin hashes and verified origins for executable tools, plugins and update hooks.
- Run tool loads with restricted files, network and credentials, including before the model begins.
- Revalidate package and runtime provenance on every update, then audit process-level side effects.
- Bind an approval for executable tools to the exact package digest and restart the authorization decision after a tool update or reload, not merely when a new tool name appears.
Unknowns and contradictions
- Efficacy against independently packaged and signed real ecosystem updates remains to be evaluated.
- Reported success does not establish compromise of any specific public tool registry.
Sources and citation
Material revision history
- Nov 4, 2026 · Published version · first publication · revision 217