Is that plugin you installed actually safe?

A run of stories this past week all pointed at the same soft spot. A coding-agent plugin that quietly uploaded a repo's entire git history the moment it was installed. Zero-click flaws that let a malicious server run code across several popular agent add-ons. A planted, fake bug report that talked an agent into running the attacker's code as if it were a fix. None of these was an exotic exploit. Each one was a tool somebody installed because it was popular and it worked, and it did exactly one more thing than they signed up for.

So here is the short version, the thing I would tell any vibe coder before they install the next shiny skill: a plugin, a skill, an MCP server, an editor extension is untrusted third-party code that runs with your credentials and your repo already in scope. Vet it like a dependency and gate what it can reach. "It is popular" and "it works" tell you nothing about safety. Those are surface signals, and a surface signal only proposes. What disposes is an independent look at what the thing can actually do, and a boundary it cannot argue its way past.

Is a popular plugin a safe plugin?

No, and it is worth being blunt about why, because almost everyone gets this backwards first. Popularity, a high star count, a wall of good reviews, a slick landing page, those are all measurements of how many people liked the surface. Safety is a question about behavior: what does this code do when it runs, and what can it reach while it does. Those are two different questions, and the first one cannot answer the second. A compromised package works perfectly right up until the trigger you never hit in testing. That is the whole trap. The tool that exfiltrated git history did not look broken. It looked great, right up to the part nobody watched.

The numbers back up the instinct. A recent scan of nearly four thousand published agent skills found more than a third carried at least one security flaw, and about one in eight carried a critical one. Most of those were never vetted by anyone, because there is no real vetting layer between a marketplace and your machine yet. When a widely used package got tampered with earlier this year, it kept running clean on thousands of developer machines while it was compromised, because working and safe are not the same property. If your confidence lives in "lots of people use it," it evaporates the first time one of those people is the attacker.

What does it mean to vet a plugin like a dependency?

It means you stop treating an install as a convenience and start treating it as an addition to your supply chain, because that is what it is. A lot of the speed in vibe coding comes from bolting on other people's tools, which means your supply chain quietly grows every time you install one, whether you are tracking it or not. This is the same confused-deputy shape as an over-scoped agent, just one altitude up: instead of the agent you drive acting out of bounds, it is the third-party tool you bolted on. I wrote about the agent-you-drive version of this in don't hand your agent the keys. The supply-chain version has its own moves.

Inventory every skill, plugin, and MCP server you have installed. If you cannot list them, that is the first finding. Pin the version and read the source, or at least skim what it asks for and where it phones home; "I did not look" is not a security posture. Give each tool its own least-privilege credentials, scoped to exactly what it needs, so a token it steals is a token that cannot do much. Do not let anything that a public input can trigger read a private repo, because that is the path that turns a stray comment into an exfiltration. And keep a human gate on any action a tool can take that is public or irreversible, a push, a post, a deploy. One thing that makes this altitude nastier than a normal dependency: a tool's own description is text your model reads, and a malicious server can hide instructions inside that description that the model then follows. The tool does not have to run to attack you. It just has to be described to your agent.

The boundary the tool can't argue with

Here is the move that actually catches this, and it is the same one I use everywhere else in a vibe coded build: separate the signal that proposes from the check that disposes. "It is popular, it installed clean, it did the demo" are surface signals. They propose that a tool is fine. The thing that disposes is a reachability boundary, a limit built into a layer the tool cannot renegotiate, no matter what its description says or how convincingly it behaves. A least-privilege token is a boundary. An egress rule that says this tool cannot reach the open internet is a boundary. A human approval on a public write is a boundary. A trust setting inside the tool's own config is not, because the untrusted thing is the one being asked to respect it.

That is the surface-versus-semantic principle applied to your supply chain. I do not trust an installed tool because it is well reviewed, the same way I do not trust AI-generated code because the build went green. I trust it because it is boxed into something it cannot escape, and I checked the box myself. The reviews are an input. They were never the verdict. If you want the general version of what a real boundary looks like versus a setting that only feels like one, I wrote that up in what real guardrails look like, and the code-trust cousin of this idea lives in how I trust code I didn't write.

If you have bolted a stack of skills, plugins, and MCP servers onto your agent and you want a second set of eyes on what they can actually reach, that is a real thing to look at before something reaches it for you. If you want someone to think through that inventory and the boundaries with you, /work-with-us.

Questions that keep coming up

Is a "verified" or signed badge enough? It is a surface signal, a good one, but still a proposal. It tells you the publisher is who they say and the bytes were not swapped in transit. It does not tell you the publisher's code is benign, and it does nothing about a description-level attack. Treat it as one input, not the verdict.

Do I really have to read the source of every tool? Read it where the blast radius is real: anything you give write access, a token, or private-repo reach. For a read-only formatter with no network, a skim and a version pin is proportionate. Match the depth of the check to what the tool can touch, not to how much time you have that day.

What about MCP servers specifically? Same shape, sharper edges, because an MCP server both runs code and hands your model tool descriptions it will act on. Scope its credentials hard, keep it off anything you would not want a stranger to reach, and remember that the description it advertises is an input to your agent, not just documentation for you.

The wave of stories was not really about any one bad plugin. It was about the habit of installing on popularity and calling it safe. Popularity is the surface. The boundary you build is the trust.