Bumblebee: Why Perplexity Opened Its Internal Security Playbook (And Why Your Laptop Matters More Than Your Server)
Let me start with the detail that reframes the entire tool. When a supply-chain worm hits the npm registry, the malicious payload almost never fires when you download the package: it fires on npm install, through a postinstall script that runs automatically. Which means any scanner that calls the package manager to check if you’re exposed has just executed exactly the code it was looking for. You go out hunting the worm, and the worm runs.
That single observation is the design thesis behind Bumblebee, the read-only endpoint scanner that Perplexity open-sourced on May 22 under Apache 2.0. It’s a ~10MB Go binary, pure stdlib, zero non-stdlib dependencies, and it’s already at 4,400 stars on GitHub. But the star count isn’t the story. The story is that a top-tier AI lab decided to open its internal endpoint security playbook — and that playbook answers a question your current tooling, quietly, cannot.
The Question Your Security Stack Won’t Answer
Imagine the moment an advisory drops naming a compromised package. Your CISO asks one thing: what development machines have this installed right now?
You’d think you could answer that. You can’t, cleanly. SBOMs document what went into a build artifact. EDR watches what processes run and what touches the network. Neither one looks at the raw on-disk state of a dev’s laptop — the lockfiles, the manifests, the editor extensions, the browser add-ons, the package manager caches scattered across the entire home directory. That local mess is exactly where the exposure lives, and it’s the blind spot between your two most expensive security tools.
This stopped being abstract on May 11, when the group Google tracks as UNC6780 injected malicious code into packages used by TanStack, SAP, and Zapier, among others. One of the affected packages was pulling 12 million downloads per week. The compromise propagated the instant devs ran install — postinstall scripts doing their job before anyone noticed. Organizations running Bumblebee detected exposed machines in minutes, according to reports; teams relying on manual review or weekly scans took days just to size the blast radius. In an active incident, the difference between minutes and days is the difference between a contained event and a breach.
Read-Only as Deliberate Constraint
Bumblebee reads metadata directly — lockfiles, manifests, records of installed packages — and never invokes npm, pnpm, pip, or any package manager. That’s not a performance optimization. It’s the entire point. Reading on-disk state cannot fire the payload, so the scanner stays inert no matter what’s hanging in your dependency tree.
It covers four surfaces that normally require four separate tools: language package ecosystems (npm, pnpm, Yarn, Bun, PyPI, Go modules, RubyGems, Composer), VS Code family editor extensions, browser extensions in Chromium and Firefox, and — the one that matters most here — MCP server configs.
The Fourth Surface: Why MCP Configs Are the Interesting Part
This is where I’d direct a senior reader’s attention. Bumblebee inventories the local JSON files that tell AI assistants which external services they’re allowed to reach — mcp.json, .mcp.json, claude_desktop_config.json, ~/.claude.json, ~/.gemini/settings.json, and the equivalents for Cline and Cursor. (For the record: non-JSON configs like Codex’s config.toml or Continue’s YAML aren’t parsed yet in v0.1.)
Think about what those configs effectively grant. An MCP server gives an AI agent access to mail, calendars, databases, code repositories. A poisoned connector slipped into one of those files doesn’t just compromise your environment — it turns your AI assistant into something that can leak credentials or run commands on your behalf, without making a sound. And most people setting up MCP have no real sense of that exposure. Almost nothing in the current security ecosystem audits these files. Bumblebee does, and that’s the gap that makes it worth your attention instead of just another scanner.
How It Works, Concretely
Three profiles, mapped to three real situations:
- baseline — a daily inventory sweep across package roots, toolchains, editor and browser extensions, and MCP configs. The one you wire into cron, launchd, or your MDM.
- project — a targeted sweep of specific development directories like
~/codeor~/src, to audit a particular environment. - deep — incident response. Sweeps roots provided by the operator against an exposure catalog. Built for the moment “we just found out about a hit — who’s exposed?”.
Output is NDJSON, so it feeds straight into whatever you already use for fleet inventory. Requires Go 1.25+, and you supply the threat catalogs — which means the tool isn’t locked to Perplexity’s view of what counts as a threat. macOS and Linux for now.
The Decision Criteria
A couple of honest limitations, framed as what should inform rather than as warnings. v0.1 is JSON-config only on the MCP side, so if your team standardizes on Codex or Continue, this doesn’t cover that surface yet — keep that in mind when evaluating whether it fits your stack today. And it’s an inventory collector, not a remediation tool: it tells you who’s exposed, fast, but acting on that is still your pipeline’s job. For most teams that’s the right division of labor — the hard part in an incident was never the fix, it was knowing where to apply it.
What really strikes me is the posture. A company known for a search engine chose to publish its internal endpoint security tooling, as a binary you can read line by line, while npm worms keep falling. It’s a bet that the supply-chain problem is already ugly enough that shared defensive tooling beats proprietary advantage. Given that attacks on development machines have been rising hard this year, by reports — and that your laptop, with its live credentials and permanent access, is arguably a juicier target than your production servers — it’s hard to argue with the bet.
Are you already scanning your MCP configs, or is it a blind spot in your security stack?