The Bitwarden CLI Hack Should Terrify Every Dev Using AI Agents
The Checkmarx supply chain campaign that hit Bitwarden’s CLI this week is the kind of story that makes me stop and stare at my own setup for a few uncomfortable minutes. If you haven’t read it yet: malicious packages impersonating @bitwarden/sdk-secrets were published to npm, and developers pulling those packages into their pipelines got compromised. Clean, surgical, and quiet until it wasn’t.
I run four AI agents locally on this Mac — Tony, Tim, Tomer, and Theo — and all of them can execute code, install packages, and interact with local tooling. Talia, my chief of staff agent, orchestrates the whole thing. When I read about a compromised CLI package inside an active supply chain campaign, I’m not thinking abstractly. I’m thinking about what happens the first time one of my agents installs a dependency without me watching closely enough.
The Attack Surface Nobody Is Talking About
Most of the conversation around AI agents right now is capability-focused. Can they reason better? Can they write cleaner code? Can they handle multi-step workflows? That’s all valid. But the conversation about what happens when an agent autonomously resolves a dependency and pulls in something malicious is still pretty thin.
Traditional supply chain attacks required a human to run npm install. A human might pause, check the package name, notice the typo, look at the download count. Agents don’t do that by default. If I tell Tony to scaffold a new integration and he decides he needs a secrets management library, he is not going to squint at the npm registry and feel suspicious. He’s going to install the thing that looks right and move on. The attack surface just got faster, more automated, and harder to audit.
The Bitwarden target is also not random. Secrets management is exactly the category of tooling that gets wired into automated pipelines. If you’re going to poison a well that agents drink from, you pick the well that touches credentials.
What I’m Actually Doing About It
After reading this I went back and looked at how I’ve constrained the T4 agents around package installation. Honest answer: not tightly enough. I have them sandboxed in terms of network egress for certain tasks, but I don’t have a hard allowlist for npm packages they can resolve without a confirmation step. That’s changing this week.
The practical fix I’m implementing is a simple approval gate in Talia’s workflow: any agent that wants to install a new package that isn’t already in the project’s lockfile has to surface that to me before executing. It adds maybe thirty seconds to a workflow and it closes a real hole. I’m also pinning package versions more aggressively and running npm audit as a post-install hook rather than something I remember to do eventually.
None of this is exotic security engineering. It’s just basic hygiene that becomes urgent when you have autonomous processes running on your machine with access to your environment variables and your credential stores.
The broader point is that every team building agentic workflows right now is essentially running a new category of software that the security tooling hasn’t fully caught up to. Checkmarx found this campaign, documented it, and published it — that’s the good news. The bad news is the detection happened after the damage was done for some users, and the next campaign will probably be more targeted.
If you’re running local agents or any kind of automated dev pipeline: when did you last audit what your agents are actually allowed to install, and who approved those permissions in the first place?
