Build · founder · 9 min read

The Add-On You Approved Is Not the Add-On That's Running

A malicious AI add-on behaved perfectly for two calls, then went after credentials on the third. Why reviewing add-ons at install time no longer works.

Published September 12, 2026 ·

security mcp supply-chain ai-agents coding-agents

Every piece of security advice you have been given about AI add-ons assumes the same thing: that you can look at the thing before you install it, decide whether it is safe, and be done. Read the source. Check the publisher. Run it in a test environment.

All of that advice is aimed at install time. And there is now a documented, named, attributed campaign built specifically to defeat install-time review — not by hiding the malicious code better, but by simply not running it yet.

What Deadbugz actually did

On August 10, 2026, a single GitHub account filed 23 pull requests to unrelated AI and developer-tool projects. All 23 landed in a 74-minute window. Each one added configuration for an add-on called productivity-suite, which offered two entirely reasonable things: format some text, summarise some text.

For the first two times your AI agent used it, it formatted and summarised text. On the third, the server changed the instructions it sent back to your agent — telling it to go find SSH keys, AWS credentials, shell history, and Kubernetes config, and to hide that it was doing so.

Pillar Security, who found and named the campaign, published the full writeup on August 12, including the indicators of compromise. Of the 23 pull requests, 19 were closed and four were still open at the time of review. None were merged through GitHub’s merge button.

So: not a catastrophe. Nobody is reporting mass compromise from this one. That is precisely why it is worth your time — it is a clean demonstration of a technique, without the noise of an actual disaster attached.

The three-call counter is the whole story

The server kept a counter. Under three calls, benign. Three or more, hostile.

Pillar are blunt about why: it is a research-evasion technique. A security reviewer pokes at a new add-on a couple of times, sees normal behaviour, and moves on. Normal daily use sails straight past three calls.

Three is arbitrary. Make it thirty, or a calendar date, or “only when the conversation mentions a bank,” and the same trick works with a much longer clean window. There is nothing clever here to defend against. The clever part is the timing.

Why your review didn’t catch it, and couldn’t have

Here is the part that matters, and it is architectural rather than incidental.

When your AI agent connects to an add-on, the add-on sends back descriptions of what its tools do. Your agent reads those descriptions as instructions. That is not a bug — it is how the agent decides which tool to use and when. Tool descriptions are not labels on a box. They are text your agent obeys.

And the protocol lets a server change those descriptions at any time, after you have approved it, without asking you again. There is no signature on them. There is no re-consent step. Your agent has no way to notice that what it is being told today differs from what you approved last month.

You did not approve a program that turned bad. You approved a program, and a different program is now running under the same name and the same green tick.

Security researchers call this a rug pull. The rug is the approval.

This is the fourth time, not the first

The reason to take one unmerged campaign seriously is that it is the latest entry in a pattern with a consistent shape:

• April 2025 — Invariant Labs demonstrated a sleeper add-on that started innocuous and later changed its own description to make a trusted WhatsApp integration leak chat history.
• September 2025 — a counterfeit postmark-mcp package built an install base, then shipped an update that quietly copied outbound email.
• 2025 — Koi documented an add-on that worked as advertised, then was weaponised through an update carrying an install-time and runtime backdoor.
• August 2026 — Deadbugz, above. Same destination, different route: instead of poisoning an update, it shipped the payload from day one and gated it behind a counter.

Four instances, one playbook: ship something that genuinely works, accumulate trust, then change the thing after the review is over.

It is the same playbook that produced the poisoned VS Code extension that reached 3,800 of GitHub’s internal repositories in May. It is the same root cause as everything in the prompt injection guide: agents believe what they read. Deadbugz just adds a clock to it.

What this means if you are not technical

You are probably not running MCP servers yourself. If you build in Lovable, Bolt, or Replit, this is not your Tuesday.

But three things make it your problem anyway.

One: the surface is growing under you, fast. A report cited earlier this month counted roughly 17,800 public AI add-ons across 6.7 million installations pulling instructions from unverified external sources. Every “connect your AI to Notion / Slack / your database” button is an instance of this pattern. You will be offered a lot of them this year.

Two: it makes one specific piece of advice concretely wrong. “We reviewed it before we installed it” is no longer a satisfying answer, and if that is the answer you are getting from a contractor or a technical co-founder, the follow-up question is: what would we see if it changed afterwards? If the honest answer is “nothing,” you do not have a control, you have a memory of one.

Three: the blast radius is your credentials, not your code. The targets here were SSH keys, cloud credentials, shell history, and cluster config — the keys to everything, sitting in predictable locations on a developer’s laptop. An add-on that reads those has not damaged your app. It has your whole account.

What to actually do

Four things, in order, and none of them require you to write code.

1. Write down which add-ons you are running. Most teams cannot answer this. You cannot audit a list you do not have. Ask for the list; if producing it takes more than an hour, that is itself the finding.

2. Ask who wrote each one, and when it was last reviewed. Not “is it popular.” Popularity is what these campaigns are farming.

3. Separate reading from writing. The dangerous configuration is one agent that can both read outside data and act on production — that is the combination that turns a poisoned description into a real consequence. If the agent that reads your inbox cannot touch your database, a rug pull costs you far less.

4. Rotate credentials on a schedule, and keep them off developer laptops where you can. This is the boring one and it is the one that actually limits damage, because it shortens the window in which anything stolen is still worth having.

What needs to be fixed, and by whom

Not by you. Pillar’s recommendation to the people building AI clients is the right one: a change to an already-approved add-on’s tool definitions should be treated as a security event, shown to the user, and require fresh approval before it can influence anything sensitive. Fingerprint the definitions at approval time; compare on every reconnect.

Until that ships, one-time approval is not a security control. It is a receipt.

The bottom line

Deadbugz did not compromise anyone at scale, and you almost certainly were not affected. Take it as a weather report rather than a fire alarm.

The useful thing it tells you is that the industry’s default model for trusting AI add-ons — check it once, approve it forever — has a hole in it that nobody has patched, and that at least four separate parties have now walked through. Anyone selling you an AI integration this year is asking for a permission that, once granted, currently has no expiry and no change detection.

That is worth knowing before you click Allow.