I made a tiny ai bug hunting harness (<4MB) that has everything (except the model obviously). It was designed for pentesting purposes where the tiny size matters to make it more portable between environments.
The intended purpose is not to be used as a worm but it does not take a genius to figure out that with small modifications such a thing could work relatively well - especially if it uses AI keys from compromised targets. Making the agent self-modifiable is relatively straightforward task and in fact I already did that in another project.
Every Windows computer has a small rwkv model on it. Wouldn't be hard at all to get decent cpu performance from a tiny malicious harness, especially one that used the self-evolving skills features and open source models.
Malware is going to be crazy, people aren't ready for the revelation of how insecure and broken things are. Everything is held together by bubblegum, duct tape, and panicked engineers putting out fires.
The reason these tools exist is not because of non-professional developers, but quite the opposite.
A lot more professionals are now working on more projects simultaneously- something that was not practical just a year ago.
Though, while this is nice, considering that all of the action is happening on the same device, I am worried this is going to increase supply chain risks. Before, a developer would work on clearly designated projects for practical reasons. Now, the same developer can work across many projects that are quite different - for example, the marketing site and the backend - and because of an obscure and unimportant component on the marketing site, there can be an impact on backend systems.
If I'm interpreting this correctly, GitHub will use their existing actions infrastructure to run versions of the code in isolated worktrees. I think this could be a very beneficial process.
What I've done on my end is created a project where I have a remote Linux workstation. I can create multiple worktrees for each repo in that workstation, and then my agent can push PRs to GitHub and use the actions infrastructure to see if the integration tests that it writes for itself are successful without needing to run those integration tests on the local environment. It's expensive in terms of runner hours, but the automaticity of it is incredible.
There is full support for GitHub sandboxes today, and in the near future the remote session experience will improve, so your laptop (or your phone, or the web) can be the control plane.
Why blame on NPM? Would you blame GitLab if an opensource maintainer was hacked and as a result the repo contains malicious changes?
All of these recent incidents is just developers doing stupid things ... like using their compromised devices for making production changes, which is basically a big red flag to begin with.
In fact, the entire situation has been exacerbated by coding agents because now practically everything happens on a single device that touches hundreds of different production systems with full production credentials.
Days since last malicious packages in NPM: 0 (evergreen)
Days since last malicious packages in PyPI: 30
Days since last malicious packages in Maven: 120
I'm sure this isn't 100% accurate, and there are probably better metrics (average number of malicious packages per year, average number of developers affected per year, etc) but they aren't as easy as a quick Google News search.
Thanks for the link. However, a 7x size differential does not fully explain a 100x security incident differential -- although I'm sure it's part of it. Some of the root causes are very hard to address (e.g. a very limited standard library which encourages dependency explosions), some are just hard (e.g. established cultural norms around version pinning and upgrades, well-established reliance on install scripts) and some are easier (e.g. small tool improvements like min-release-age). I'm personally not going to touch npm with a ten foot pole in the next year or two, but I'd love to see significant improvement, so that I have that option again in 2 or 3 years. Stay safe!
The npm cli has bad defaults which you can turn off but they are there I presume for legacy reasons. The secure option is pnpm. The registry is fine.
Also on our comment about size differential ... it absolutely can.
If I jump from 2 meters hight it will be mildly uncomfortable. Jumping from 12 meters will result in severe injurious and possibly death. None of these things go linearly in real world conditions.
At cbk.ai we dynamically load MCPs into the context when the LLM needs them and unload them when finished. The cost for doing this is negligible and it scales well.
The good think about MCP is the authentication story. It is almost perfect. Compare this with CLIs which mostly piggy back on quirky browser authentication, env files and other bad practices. It is a security nightmare. It is certifiably insane.
So to compare MCPs to CLIs purely on token cost is missing the entire point that at the end of the day these agents need to operate safely and OAuth is the defacto standard where this can be done in somewhat consistent way across different vendors.
reply