Auditing MCP Servers for Supply-Chain Risk with Bumblebee

If you’ve installed more than a handful of MCP servers over the past few months, ask yourself honestly: do you actually know what any of them are doing under the hood? Most of us don’t. We npm install or go install something a Discord thread recommended, grant it filesystem or terminal access, and move on. That gap — install first, audit never — is exactly what Bumblebee, a new open-source CLI from Perplexity, is built to close.

What Bumblebee actually does

Bumblebee is a read-only scanner written in Go with zero external dependencies, which matters more than it sounds — a security tool that itself pulls in twenty transitive dependencies is a supply-chain risk pretending to solve one. It checks four surfaces most developers never think to audit together:

• Package manifests across npm, PyPI, Go modules, RubyGems, and Composer
• Installed MCP servers against known-malicious and suspicious registries
• VS Code extensions currently installed on your machine
• Browser extensions in your inventory

It makes no changes to your system. It reads, compares against threat registries, and reports. That’s the whole job, and honestly, that’s the right scope for a tool like this — you don’t want your security scanner also being the thing with write access to your environment.

How it fits alongside tools you already run

If you’re already running npm audit, Dependabot, or Snyk, you might reasonably ask why you’d add another scanner. The honest answer: those tools do their job well for package manifests, but none of them touch MCP servers, editor extensions, or browser extensions — and that’s not a small gap anymore given how much access a typical MCP server gets granted.

Think of it less as a replacement and more as filling in the blind spots:

• npm audit / Dependabot — best for continuous, automated dependency-vulnerability tracking inside a specific package ecosystem, usually wired into CI.
• Snyk — broader vulnerability database and often better remediation guidance, but it’s a paid product for anything beyond basic use, and it also doesn’t cover MCP servers as of this writing.
• Bumblebee — narrower in scope (it won’t tell you how to fix a flagged package), but it’s the only one of the three checking your installed MCP servers and editor/browser extensions against threat data, and it’s free with zero setup beyond a Go install.

Realistically, most teams end up running more than one of these. Bumblebee’s value is specifically in the surfaces the others ignore, not in replacing your existing dependency-scanning pipeline.

Who actually needs this right now

This isn’t equally urgent for everyone:

• Solo developers experimenting with MCP servers from GitHub/Discord recommendations — highest priority. You’re the audience with the least existing tooling covering this gap.
• Teams on shared dev machines or shared CI runners — a compromised MCP server on a shared machine is a lateral-movement risk, not just a personal one. Worth adding to onboarding checklists.
• Anyone running MCP servers with filesystem or terminal-execution permissions — the access level here is exactly what makes a compromised server dangerous, so this is the profile Bumblebee is most directly built for.
• Teams already enforcing strict extension allowlists via MDM/policy — lower urgency, since you likely already have a vetting process; Bumblebee still adds value as a second check, but it’s not filling as large a gap.

Why this matters more for MCP specifically

Package auditing for npm and PyPI isn’t new — tools like npm audit and Snyk have covered that ground for years. What’s actually novel here is the MCP server check. MCP adoption moved fast in 2025-2026, and the ecosystem around it looks a lot like early npm did in 2015: lots of small, independently-maintained servers, minimal vetting, and users granting them broad permissions (filesystem access, terminal execution, API keys) without a second thought. A malicious or compromised MCP server isn’t a theoretical risk — it’s a server with the same access level as a plugin that can read your entire codebase and send data wherever it wants.

Running it: step-by-step

1. Install (requires Go 1.25+):

go install github.com/perplexityai/bumblebee@latest

2. Run a full scan:

bumblebee scan

This walks your package manifests, installed MCP server registry, and extension inventories in one pass. On a machine with a moderate number of installed tools, expect the scan to take anywhere from a few seconds to a couple of minutes depending on how many manifests it has to parse.

3. Review the output. Bumblebee flags matches against known-malicious or suspicious entries, and — this is the part worth paying attention to — also flags anything it can’t classify with confidence. Don’t treat an “unknown” result the same as a “clean” result. Unknown means unverified, not safe. Read the flagged-entry details rather than just the summary count — a scan showing “0 malicious” can still be surfacing several “unknown/unverified” entries worth a manual look.

4. Re-run it on a schedule, not just once. A one-time scan tells you about your environment today. Threat registries update; new malicious packages get identified after the fact, sometimes weeks after they were pulled by unsuspecting developers. Running this as a weekly cron job or a pre-commit hook on a shared dev machine gets you much more value than a single manual run.

5. Consider wiring it into CI, with realistic expectations. Since Bumblebee is read-only and exits with a status you can check, it can slot into a pipeline step alongside your existing dependency scans. The caveat: it’s still a young project (v0.1.1 as of this writing), so treat a CI integration as advisory at first — flag failures for review rather than hard-blocking merges — until you’ve run it long enough to trust its signal-to-noise ratio on your specific stack.

Trade-offs, edge cases, and what it won’t catch

No scanner is a complete answer, and it’s worth being direct about the limits here:

• It’s signature/registry-based, not behavioral. Bumblebee checks against known-bad entries. A brand-new malicious MCP server that hasn’t been reported yet won’t be flagged on day one. This is detection-after-disclosure, not zero-day protection.
• Read-only means no remediation. It tells you what’s risky; it doesn’t remove or sandbox anything for you. You still need a manual process (or a separate tool) for what happens after a flag.
• Coverage depends on registry completeness for MCP specifically, since MCP threat-intel is much younger and thinner than, say, npm’s. Treat an MCP “clean” result with more skepticism than a package-manager “clean” result, at least for the next year or two while that data matures.
• Go 1.25+ requirement may be a blocker on older CI images — worth checking your build environment before adding this to a pipeline.
• Early-stage project maturity. At v0.1.1, expect CLI flags, output format, and registry coverage to change. Pin a specific version in any CI setup rather than always pulling @latest, so an upstream change doesn’t silently break your pipeline.

None of this makes it not worth running. It just means it belongs in a layered approach — one signal among several, not a single source of truth.

Common questions before you install it

Does it phone home or send data anywhere? Based on its stated read-only, zero-dependency design, it’s built to run entirely local-first against its threat registries. Verify this directly against the current source/docs before deploying it on anything handling sensitive data — don’t take a tool’s stated scope as verified fact without checking.

Will it slow down my CI pipeline noticeably? For a typical project’s manifest size, scan time is usually seconds to low minutes. It scales with how many manifests and extensions it has to parse, so a monorepo with dozens of packages will take longer than a single small repo.

What happens if it flags something that’s actually safe (a false positive)? As a young, registry-based tool, false positives are expected occasionally, especially on newer or less-common packages. Treat flags as “worth a manual look,” not an automatic verdict — this is exactly why an advisory CI integration (flag, don’t block) makes more sense early on than a hard gate.

What a real run actually looks like

An independent hands-on review tested the official v0.1.1 Linux release running under WSL: the published checksum verified correctly, the built-in self-test completed in 4 milliseconds and returned 3 findings, and a synthetic npm exposure test correctly flagged a known-vulnerable package version while correctly ignoring a deliberately different version of the same package — no false positive on the clean case. The same review is direct about the tool’s real boundary at this version: it only matches exact package names and versions, it doesn’t evaluate version ranges, and it doesn’t prove malicious code actually executed — it’s an exposure check, not a forensic tool.

For real-world motivation: the Mastra supply-chain attack compromised over 140 npm packages in under 90 minutes earlier this year — exactly the kind of fast-moving incident where a quick, safe, read-only sweep across a fleet of developer machines matters more than a slower, more thorough tool would.

An easier install path if Go 1.25+ is a blocker

The official install method above needs a genuinely recent Go version most systems won’t have by default. A third-party wrapper called bumblebee-cli packages the official binary behind a friendlier interface, installable without wrestling with a Go toolchain at all:

pip install bumblebee-cli

This gives you a bee command with an interactive guided menu (bee), a one-step installer for the underlying Perplexity binary (bee install), and scan profiles like bee scan . --profile strict --findings-only. It’s a community wrapper, not the official Perplexity tool itself — treat it as a convenience layer over the same underlying scanner, not a separate security review — but for anyone who just wants a fast answer without an install-version fight, it’s the more practical starting point.

Practical takeaway

If you manage more than a couple of MCP servers or work on a shared dev machine, install Bumblebee today and run one scan before you do anything else with it — that first scan is where you’ll actually learn something. Then decide whether a weekly scheduled run or a pre-commit hook fits your workflow better. Either way, “I’ll audit it eventually” is exactly the gap this tool exists to close, and eventually is doing a lot of work in that sentence for most of us.

Official reference: Bumblebee’s GitHub repository (github.com/perplexityai/bumblebee), the independent hands-on review at OpenAIToolsHub, and the bumblebee-cli package documentation on PyPI, all current as of this writing.