We've spent years worrying about compromised maintainers, but the idea that attackers can just register the fake package names that AI models consistently hallucinate and then sit back while AI-driven workflows deliver 30k downloads feels like a fundamentally new class of threat.
It's not exploiting trust in the supply chain, it's exploiting trust in the AI's suggestions.
As a recommendation, I ran this article through Claude Code and had it update my Claude.md to have specific settings to check packages before installing and user gates for myself
We’ve built systems where decisions are being made continuously—by agents, by dependencies, by invisible layers of abstraction—but the reasoning behind those decisions is nowhere to be found.
“Chosen by nobody on your team” is the most dangerous sentence in this piece.
Because it means:
decisions are happening without ownership, without traceability, and without the ability to reconstruct why.
AI didn’t create this.
It just scaled it to the point where the gap is now existential.
The real question isn’t how to secure the supply chain.
It’s whether we’re building systems where judgment itself is captured and governed—or left to emerge as invisible exhaust.
One way to think about this is as Judgment Capital Management (JCM)—treating the reasoning behind decisions as something that needs to be captured and governed, not assumed to exist.
This piece articulates the threat model better than anything else I've read on the topic. The framing around agents creating a structurally different attack surface — not just more of the same, but a different trust model — is exactly right.
I built PatchPilot, an open-source Claude Code pre-execution hook that originally checked npm/pip/brew packages against Google's OSV database before installs ran. When I read this article, I realised my CVE-only approach had the specific gap you named: the Axios attack vector had no CVE, and OSV knew nothing about it.
So I shipped three additional checks after reading your post:
- Version Quarantine (72h): flags recently published versions, suggests previous stable — This piece better explains the threat model than anything else I've read on the topic. The framing around agents creating a structurally different attack surface — not just more of the same, but a different trust model — is exactly right.
I built PatchPilot, an open-source Claude Code pre-execution hook that originally checked npm/pip/brew packages against Google's OSV database before installs ran. When I read this article, I realised my CVE-only approach had the specific gap you mention: the Axios attack vector had no CVE, and OSV knew nothing.
So I shipped three additional checks after reading your post:
- Version Quarantine (72h): flags recently published versions, suggests previous stable — catches the compromised-release pattern
- New Package Detection (7d): flags packages created less than a week ago
- Low Downloads (<100/week): flags packages with no community adoption signal
All three would have caught plain-crypto-js before any agent installed it.
Being honest about what it still doesn't do: postinstall script inspection, transitive dependency auditing, and runtime monitoring. Socket's 6-minute detection time doesn't include the signals PatchPilot has. This is a first gate, not a complete solution.
Thank you for writing this. It drove a concrete response.
catches the compromised-release pattern
- New Package Detection (7d): flags packages created less than a week ago
- Low Downloads (<100/week): flags packages with no community adoption signal
All three would have caught plain-crypto-js before any agent installed it.
Honest about what it still doesn't do: postinstall script inspection, transitive dependency auditing, and runtime monitoring. Socket's 6-minute detection time doesn't include the signals PatchPilot has. This is a first gate, not a complete solution.
The slopsquatting angle is what really got me.
We've spent years worrying about compromised maintainers, but the idea that attackers can just register the fake package names that AI models consistently hallucinate and then sit back while AI-driven workflows deliver 30k downloads feels like a fundamentally new class of threat.
It's not exploiting trust in the supply chain, it's exploiting trust in the AI's suggestions.
As a recommendation, I ran this article through Claude Code and had it update my Claude.md to have specific settings to check packages before installing and user gates for myself
You’ll like this https://dtnadvisory.substack.com/p/your-ai-just-became-someone-elses?r=2gm0eb&utm_medium=ios
Thanks for sharing this. Glad I wasn’t affected by the Axios vulnerability.
Socket's detection with 6 minutes is astounding.
This isn’t really a supply chain problem.
It’s a judgment problem.
We’ve built systems where decisions are being made continuously—by agents, by dependencies, by invisible layers of abstraction—but the reasoning behind those decisions is nowhere to be found.
“Chosen by nobody on your team” is the most dangerous sentence in this piece.
Because it means:
decisions are happening without ownership, without traceability, and without the ability to reconstruct why.
AI didn’t create this.
It just scaled it to the point where the gap is now existential.
The real question isn’t how to secure the supply chain.
It’s whether we’re building systems where judgment itself is captured and governed—or left to emerge as invisible exhaust.
One way to think about this is as Judgment Capital Management (JCM)—treating the reasoning behind decisions as something that needs to be captured and governed, not assumed to exist.
This piece articulates the threat model better than anything else I've read on the topic. The framing around agents creating a structurally different attack surface — not just more of the same, but a different trust model — is exactly right.
I built PatchPilot, an open-source Claude Code pre-execution hook that originally checked npm/pip/brew packages against Google's OSV database before installs ran. When I read this article, I realised my CVE-only approach had the specific gap you named: the Axios attack vector had no CVE, and OSV knew nothing about it.
So I shipped three additional checks after reading your post:
- Version Quarantine (72h): flags recently published versions, suggests previous stable — This piece better explains the threat model than anything else I've read on the topic. The framing around agents creating a structurally different attack surface — not just more of the same, but a different trust model — is exactly right.
I built PatchPilot, an open-source Claude Code pre-execution hook that originally checked npm/pip/brew packages against Google's OSV database before installs ran. When I read this article, I realised my CVE-only approach had the specific gap you mention: the Axios attack vector had no CVE, and OSV knew nothing.
So I shipped three additional checks after reading your post:
- Version Quarantine (72h): flags recently published versions, suggests previous stable — catches the compromised-release pattern
- New Package Detection (7d): flags packages created less than a week ago
- Low Downloads (<100/week): flags packages with no community adoption signal
All three would have caught plain-crypto-js before any agent installed it.
Being honest about what it still doesn't do: postinstall script inspection, transitive dependency auditing, and runtime monitoring. Socket's 6-minute detection time doesn't include the signals PatchPilot has. This is a first gate, not a complete solution.
GitHub: https://github.com/ProduktEntdecker/patchpilot-cli
Thank you for writing this. It drove a concrete response.
catches the compromised-release pattern
- New Package Detection (7d): flags packages created less than a week ago
- Low Downloads (<100/week): flags packages with no community adoption signal
All three would have caught plain-crypto-js before any agent installed it.
Honest about what it still doesn't do: postinstall script inspection, transitive dependency auditing, and runtime monitoring. Socket's 6-minute detection time doesn't include the signals PatchPilot has. This is a first gate, not a complete solution.
GitHub: https://github.com/ProduktEntdecker/patchpilot-cli
Thank you for writing this. It drove a concrete response.