You used to be able to spot a developer. They had the black and green terminal, the editor with seventeen files open, and uncanny ability to exit vim (esc :q! if you didn’t know). Writing software had a high bar, and that bar kept most people out.
Open something like Claude Cowork, type "build me a tool that cleans up this spreadsheet and emails me a summary every Monday," and walk away. Minutes later, there's a working thing. Behind the chat window, an agent spun up a virtual machine, wrote real code, pulled in whatever libraries it decided it needed, ran it, hit an error, fixed it, and handed you the result. You described an outcome, while a machine did the engineering.
Congrats! You're now a developer, one who never saw a single line of what got built.
The dependency you didn't choose #
To fix your problem, your friendly neighborhood agent reaches out to a public library of magical packages and downloads strangers' code onto a machine. That's how modern software works, and developers do it constantly. The difference is that these developers at least know npm install is running and the risks involved. You might not. You asked for a spreadsheet cleaner.
And that library is under active attack. This month, an attacker republished 141 packages in the popular @mastra AI-agent ecosystem in a 45-minute overnight burst, slipping a malicious dependency into every one. The poisoned package, a look-alike of a common date library, ran a script at install time that pulled down a second payload, launched it as an invisible background process, then deleted itself to hide the evidence. The payload hunted through 160+ browser crypto wallets and dug in for persistence across Mac, Windows, and Linux. One affected core package gets nearly a million downloads a week.
When a developer adds a dependency, there's usually some judgment in the mix. If they aren't already familiar with the popular or trusted tools in the space, they might glance at the download numbers, the last commit, and who maintains it. Then the decision goes in a pull request where someone else can question and review the package before it merges. The ways that an AI reaches for a package is unclear. Sometimes it's just whatever is most common, or sometimes it's real obscure. But AIs also hallucinate packages that sound real but aren't. When the latter happens, in the best case the package the AI made up doesn't exist. In the worst, an attacker guessed what an AI might invent and stuck nasty malware at that package name. This is called slopsquatting, and it's something anyone using AI to code needs to watch out for.
This isn't a "don't use the tools" argument #
The tools are transformative, and they're not going back in the box. Sandboxing helps, an isolated VM contains some blast radius, and that's real. But the code in the sandboxes gets shipped to real repos and real credentials the moment they're useful, and isolation doesn't fix the part where you never reviewed the dependencies.
LLMs handed the keyboard to everyone, which is wonderful. But in doing it, we moved the most dangerous decision in software (what code do I trust enough to run?) to somewhere no human is looking. The answer isn't to read every diff again. That ship sailed. Instead, we need to push the trust check down to where the install happens. Block known-malicious packages before they hit the machine, make install scripts opt-in instead of automatic, and treat "the agent handled it" as a sentence that should make you slightly nervous.
Everyone's a developer now. The bike has no training wheels, and most of the new riders have both hands off the bars.
Look, Mom, no guardrails! The good news is you can add them back without slowing anyone down. Aikido Device Protection catches the bad package at the one moment that matters, before it installs, so "the agent handled it" stops being a sentence that should scare you.
If you want to figure out how to secure your vibe-coded apps, check out our Vibe Coding Checklist for Security.