A new security study highlights a less visible layer in AI coding agents: lifecycle hooks that can execute around the model rather than through its tool-selection path.
The paper, A Blind Trust, the Bloody Thrust, was submitted to arXiv on September 3. It studies a supply-chain scenario in which a user first installs a benign plugin and later accepts an update whose hook configuration has changed. Under the paper's threat model, the attacker does not need a sandbox escape or implementation bug. Changed metadata can bind host commands to ordinary lifecycle events.
The researchers built HookPry to automate this attack class. Across 1,000 end-to-end runs covering seven agent harnesses, five LLM backends and 25 harness-backend combinations, they report a 77.0% micro-average success rate. Every tested harness produced at least one externally verified malicious effect, and the highest per-harness result was 92.5%.
These figures are author-reported and have not been independently reproduced. The tests use ephemeral environments and synthetic assets, cover 40 attack cases, and do not exhaust operating systems, shells, enterprise policies, networks or future versions. The study also assumes normal installation or update adoption; it does not measure how often real users would install a malicious package.
The security boundary extends beyond model-selected tools
The important result is architectural. Agent defenses often focus on the model-mediated path: prompt injection, tool permissions, confirmations and policy checks around actions selected by the LLM. Lifecycle hooks create another path. Once the event fires, the harness can launch a configured command without asking the model to decide on that command again.
Claude Code's official documentation independently confirms that this is a privileged control surface. Anthropic describes command hooks as user-defined shell commands run automatically at lifecycle events and warns that they execute with the full permissions of the local user. The same documentation describes workspace-trust controls and a ConfigChange event that can audit or block some configuration changes during a session.
OpenCode's official plugin documentation also exposes event-driven hooks around sessions, tools and installation. Product semantics differ, so HookPry should not be presented as proof of one identical vulnerability across every harness. The official material does establish that lifecycle configuration can carry execution authority outside the model's immediate decision loop.
Static scanning was not enough in this experiment
The paper tested three static defenses on 40 malicious and 40 benign artifacts. The authors report Microsoft Defender detected 0 of 40 malicious samples, HookPolicy detected 20, and a five-rule Semgrep setup detected 19. The union detected 21 and missed 19, a 47.5% miss rate.
That result requires caution. Defender is a general endpoint-security product; HookPolicy and Semgrep were researcher-configured baselines. The benign controls were synthetic and low risk. The study did not test specialized commercial supply-chain products or dynamic behavioral detection. The defensible conclusion is narrower: package scanning alone is not an authorization model for executable configuration.
Treat authority-expanding updates like permission changes
Aipolix's practical conclusion is that an update adding executable authority should be treated more like a permission change than a routine version bump.
Four controls follow. First, generate a semantic diff of executable configuration on installation and every update. Surface new events, changed commands, network destinations, script paths and expanded environment access as security changes.
Second, require re-authorization when the authority envelope expands. Approval should bind to effective configuration and granted capabilities, not only package identity.
Third, run hooks with least privilege. Constrained filesystem views, network controls, isolation and scoped credentials reduce the impact of a malicious or defective hook.
Fourth, preserve execution provenance: plugin version, configuration hash, triggering event, executed handler and security context. If a hook transforms tool output before it reaches the model, retain the original output and the transformation provenance.
Configuration can be brought under policy
This is not purely theoretical. Claude Code's current hook reference includes ConfigChange, designed to audit configuration changes and enforce security policy. For some sources, it can block a change from being applied to the current session.
That mechanism does not solve the entire supply-chain problem and other harnesses use different update models. But it demonstrates a useful direction: configuration that carries execution authority can be made observable and policy-governed.
HookPry remains a research result, not evidence of widespread real-world exploitation. The code is linked through an anonymized research repository, the experiments are synthetic, and the authors say they disclosed the findings to affected vendors while awaiting responses. Aipolix found no independent reproduction of the 77.0%, 92.5% or 47.5% figures.
The operational rule is clear: agent governance cannot end at prompts and model-selected tool calls. Any mechanism capable of causing an external effect, including executable lifecycle configuration, belongs inside the same authorization, least-privilege and audit model.