The problem
On May 20, 2026, a malicious VS Code extension compromised over 3,800 GitHub repositories before anyone noticed. The attack vector was not a zero-day. It was a package that developers installed voluntarily, trusted by default, sitting quietly on their laptops.
Supply-chain attacks have shifted. The target is no longer just the CI/CD pipeline or the production build. It is the developer machine itself - the local environment where code is written, where extensions are installed, where AI agent configs live.
This is the surface that most security tools miss.
What Bumblebee is
Perplexity open-sourced Bumblebee on May 22, 2026. It is a read-only endpoint scanner built specifically for developer machines. When a new supply-chain advisory lands, security teams need to know within minutes whether any of their machines are exposed. Bumblebee answers that question.
It covers four surfaces that existing tools tend to split across multiple products:
- Language package managers - npm, pnpm, Yarn, Bun, PyPI, Go modules, RubyGems, Composer
- AI agent configs - MCP server configurations
- Editor extensions - VS Code, Cursor, Windsurf, VSCodium
- Browser extensions - Chrome, Edge, Brave, Arc, Firefox, and Perplexity’s own Comet
One scan, all four surfaces, one report.
Why read-only matters
This is the most important design decision in Bumblebee, and it is easy to overlook.
npm packages can carry postinstall scripts that execute automatically the moment a package
manager touches them. That is exactly how most recent supply-chain worms have propagated.
A scanner that invokes npm to check for a compromised package has already triggered the
attack it was looking for.
Bumblebee never does this. It reads metadata files directly - lockfiles, manifests, installed package metadata - without invoking any package manager, running any install scripts, or reading application source files. The scan itself cannot become the risk.
Three scan profiles
Bumblebee supports three modes depending on the situation:
| Profile | When to use |
|---|---|
| Baseline | Routine scheduled scan via MDM or fleet tooling |
| Project | Targeted scan of a specific repo or workspace |
| Deep | Active incident response sweep |
Each detection is traceable. Every finding shows which catalog entry triggered it, when that entry was added, and the supporting evidence. No black boxes.
How it fits into a workflow
Perplexity’s internal workflow gives a clear picture of how this is meant to be used:
- A threat signal arrives - public disclosure, third-party intel feed, or internal research
- Perplexity Computer drafts a catalog update and opens a GitHub PR with source links
- A human reviews and merges the PR
- Bumblebee runs against endpoints with the updated catalog
- Findings go to the security team
The key step is human review before the catalog update reaches endpoints. Bumblebee is a detection layer, not an autonomous response system. That distinction matters.
What this does not replace
Bumblebee is not an EDR. It does not monitor processes or network traffic. It does not replace SBOM scanners that cover repositories and build artifacts, or endpoint inventory products that track installed applications.
It fills a specific gap: the developer laptop, at the moment a supply-chain advisory lands. SBOM tools cover what was built. Bumblebee covers what is sitting on the machine right now.
Why this matters for security teams
Most organizations have reasonable coverage of their production environment. Far fewer have visibility into the developer endpoint surface - the machines where engineers install packages daily, add extensions on demand, and configure AI tools with broad system access.
MCP configurations in particular are a new and largely unmonitored surface. AI agents running locally can have significant filesystem and network access. A compromised MCP server config is a meaningful foothold. Bumblebee is currently the only open-source tool that explicitly covers this surface.
Bumblebee is available now as an open-source Go project for macOS and Linux. Security teams can run it against their own catalogs and feed results into existing response workflows.
For Windows support, watch the repository. Given the tool’s focus on developer environments, Windows coverage is a likely next step.