What happens when a piece of malware can rewrite itself on every attack, use your own development credentials to spread, and hide inside the AI tools your team already trusts?
Christine Lemmer-Webber, a capability security advocate associated with the Spritely project, argues in a detailed March 5 post that a self-replicating AI agent worm is not a theoretical risk - it's an engineering inevitability that could surface within months.
The Attack Surface Already Exists
The argument isn't abstract. Lemmer-Webber points to real incidents. The "cline" package (a popular VS Code AI coding extension) was recently compromised to silently install malicious software on approximately 4,000 developer machines before anyone noticed. Title injection attacks against automated PR review agents have already been demonstrated in the wild. These aren't hypothetical proof-of-concept papers - they're actual attacks that worked.
The predicted worm would target open-source projects that use automated code review or generation tools. It would use locally stored credentials (API keys, SSH keys, GitHub tokens) to submit code to other projects, spreading itself through the normal development workflow. Because AI agents are nondeterministic - they vary their output each time - the malicious code would look different in every repository, making signature-based detection nearly useless.
The "Confused Deputy" Problem
The core vulnerability Lemmer-Webber identifies is what security researchers call the "confused deputy" problem. AI agents operate with whatever permissions their host environment has. When you give a coding agent access to your terminal, your git credentials, and your file system, you're trusting it to only use those permissions for legitimate purposes. But the agent itself has no concept of authority boundaries - it simply executes whatever instructions it processes, whether those come from your prompt or from malicious content injected into a repository it's analyzing.
Sandboxing helps, but agents are specifically designed to take actions in the real world. An agent that can't push code, run tests, or access APIs isn't very useful. That tension between capability and containment is exactly what makes this threat plausible.
For anyone using AI coding agents in their daily workflow, the practical takeaway is unglamorous but important: audit what credentials your agent tools can access, treat AI-generated pull requests with the same suspicion you'd give a contribution from an unknown developer, and don't grant agents broader system access than they strictly need.