For years, supply-chain security tooling has watched the wrong place. SBOMs and vulnerability scanners cover build artifacts and repositories. EDR products track what ran and what touched the network. But the machine that actually gets popped is the one under your desk — the laptop with dozens of packages, a pile of editor extensions, a few browser add-ons, and now a growing stack of MCP configs pointing at AI agents.
When a new advisory drops, your security team faces one blunt question: which developer machines are exposed right now? Perplexity built an internal tool to answer it, and in May 2026 they open-sourced it. It is called Bumblebee, and its design is refreshingly opinionated.
What Bumblebee is
Bumblebee is a read-only inventory collector for macOS and Linux developer endpoints. It is written entirely in Go, carries zero non-stdlib dependencies, and ships under Apache 2.0. Perplexity already runs it internally to protect the developer systems behind its search product, the Comet browser, and its Computer agent.
The whole tool is a single Go binary. Install it with:
go install github.com/perplexityai/bumblebee/cmd/bumblebee@latest
It requires Go 1.25 or later, and the current release is v0.1.1. After installing, run bumblebee selftest to verify the binary works against its embedded fixtures.
The gap it fills
The problem Bumblebee targets is specific. Existing tools do not check local developer state — lockfiles, package metadata, extension manifests, and AI-tool configs scattered across a laptop's filesystem. When an advisory names a package, extension, or version, Bumblebee answers which machines show a match in their on-disk metadata right now.
The ecosystem coverage was chosen deliberately. It maps to recent real supply-chain campaigns — including the Mini Shai-Hulud series, which hit npm, PyPI, RubyGems, Go modules, and Composer packages across companies including TanStack, SAP, and Zapier. Bumblebee scans exactly where those attacks landed.
What it scans
Bumblebee covers four surface areas that most tools handle separately:
- Language package managers — npm, pnpm, Yarn, Bun, PyPI, Go modules, RubyGems, and Composer. It reads lockfiles and installed metadata directly:
package-lock.json,pnpm-lock.yaml,go.sum,*.dist-info/METADATA, and more. - AI agent configs — MCP JSON host files like
mcp.json,.mcp.json,claude_desktop_config.json,mcp_settings.json,cline_mcp_settings.json, and~/.gemini/settings.jsonfor the Gemini CLI. It inventories the servers but deliberately does not emit values or key names fromenvblocks. - Editor extensions — manifests from VS Code, Cursor, Windsurf, and VSCodium.
- Browser extensions — the Chromium family (Chrome, Comet, Edge, Brave, Arc) plus Firefox.
There are honest gaps in v0.1. bun.lockb, Bun's binary lockfile, is not parsed — only the text bun.lock format is. Non-JSON MCP configs such as Codex's config.toml and Continue's YAML are skipped too. Knowing the blind spots is part of using the tool responsibly.
Why read-only is the entire point
Here is the design decision that makes Bumblebee smart rather than just convenient. npm packages can carry postinstall scripts that execute automatically on npm install. A scanner that shells out to npm to check exposure has already triggered the very attack it was hunting for.
Bumblebee refuses to play that game. It never runs install scripts or lifecycle hooks, never invokes npm, pnpm, bun, or pip, never reads application source, and does no process or network monitoring. It is not an EDR, and it does not pretend to be. Every scan reads files and exits.
That constraint is what lets you run it during an active incident on a machine you already suspect is compromised, without making things worse.
How you actually run it
Bumblebee is a one-shot scanner. Each invocation performs a single scan and exits — cadence is your responsibility, via cron, launchd, systemd, or MDM fleet tooling. Output is NDJSON, one record per line, with diagnostics sent to stderr so you can pipe results straight into a log pipeline.
It ships three scan profiles for different jobs:
| Profile | Scope | When to use |
|---|---|---|
baseline |
Global/user package roots, toolchains, editor and browser extensions, MCP configs | Routine fleet inventory |
project |
Configured dev directories like ~/code or ~/src |
Per-repo exposure checks |
deep |
Operator-supplied roots, typically a bare home directory | Active incident response |
Each package record carries the hostname, OS, architecture, ecosystem, package name, version, source file, and a confidence field — high when identity and version came from canonical metadata, medium when the version or source is partial, and low when only a config path or spec reference is found. That confidence signal keeps you from paging an engineer at 2 a.m. over a fuzzy match.
From advisory to answer
Findings come from your own exposure catalogs — simple JSON files specifying ecosystem, package name, and affected versions. When Bumblebee matches one, it emits a finding with severity, catalog ID, and evidence, fully traceable back to the entry that triggered it. The repo also ships a threat_intel/ directory with maintained catalogs built from public supply-chain campaign reporting, so you are not starting from a blank file.
Perplexity's internal loop is worth copying: a threat signal arrives from public disclosures or intel feeds; their Computer agent drafts a catalog entry with ecosystem, package, and version, and opens a GitHub PR with source links; a human reviews and merges; Bumblebee runs across endpoints with the updated catalog; findings go to the security team. It is a tight, auditable pipeline from "an advisory exists" to "these three laptops are affected."
The Bottom Line
Bumblebee is a small tool with a sharp thesis: the developer endpoint is an under-instrumented attack surface, and the safest way to inspect it is to touch nothing you could trigger. By staying read-only, staying dependency-free, and covering the exact ecosystems that recent campaigns actually hit — including the MCP configs that most scanners ignore entirely — it fills a real gap between SBOMs and EDR. It is v0.1.1 with known blind spots, but the design is right, the license is permissive, and the problem is not going away.
