Nobody checks the developer’s laptop. That’s been an unspoken rule of enterprise security for years. You audit the production server. You scan the container. You review the CI pipeline. But the machine where the code gets written, the one loaded with npm packages, VS Code extensions, Docker images, AI tool configs, and half-built projects, that sits quietly outside your threat model.
Until something goes wrong. And then everyone wonders why nobody was watching.
Introduction
On May 22, 2026, Perplexity released Bumblebee, an open-source, read-only scanner built to answer a question that turns out to be surprisingly hard to answer: which developer machines in your org have a risky package, extension, or AI config sitting on disk right now?
The tool didn’t emerge from a security startup or a government research lab. It came from Perplexity’s own internal security team, built to protect the developer systems behind Perplexity Search, the Comet browser, and their Computer agent. They used it quietly internally. Then they open-sourced it.
That decision, to share the internal playbook, says as much about where software supply chain security is headed as the tool itself.
How Bumblebee Works
The modern developer workstation is, by any honest assessment, a mess, thousands of packages from dozens of ecosystems. Extensions installed months ago and forgotten. AI tool configuration files that connect to external services. Git repos cloned for quick reference. Environment variables stored in dotfiles. And underneath all of it, a quiet accumulation of decisions nobody fully remembers making.
Traditional security tools largely ignore all of this. Software Bill of Materials (SBOM) scanners document what ships to production. EDR (Endpoint Detection and Response) tools watch running processes and network behaviour. Neither reads the on-disk developer state, lockfiles, extension manifests, or package manager caches. They’re looking at different floors of the same building and calling it a complete inspection.
Bumblebee lives in that gap.
The Architecture: One Binary, No Dependencies
Written entirely in Go 1.25+ with zero external dependencies, Bumblebee runs as a single static binary. No runtime to manage. No package manager to invoke. No code is executed from the projects it scans. It reads metadata only, inspecting lockfiles, manifests, and configuration files, and outputs structured NDJSON (Newline Delimited JSON) records: one line per discovered package, extension, or finding.
The binary is small enough to push silently via Mobile Device Management (MDM) without a deployment ceremony. That matters more than it sounds. Most security tools fail not because they don’t work, but because deploying and maintaining them is painful enough that teams route around them. A single static binary with no dependencies changes that calculus entirely.
What It Scans: Packages, Extensions, and AI Configs
Bumblebee covers eight package ecosystems: npm, pnpm, Yarn, Bun, PyPI, Go modules, RubyGems, and Composer, a fairly complete map of where modern dependency risk lives. It reads lockfiles and manifests directly, without invoking the package manager. No install scripts triggered. No network calls made.
Beyond packages, it reads browser extension manifests, capturing the version details that make cross-fleet comparison actionable. A compromised extension update can persist on a machine for months without surfacing anywhere else. Bumblebee finds it.
Then there’s the part that’s genuinely forward-looking: Model Context Protocol (MCP) server configurations. These files define which external services an AI coding assistant is connected to. With MCP adoption accelerating sharply through 2025 and 2026, a misconfigured or compromised MCP server is exactly the kind of risk no traditional scanner was built to catch. Bumblebee was.
The Threat Intelligence Catalogue: Precision Over Noise
The catalogue is what ties everything together. Maintained directly in the repository, it holds structured records of known compromised packages, affected versions, ecosystems, and severity ratings. When a supply-chain incident surfaces, a catalogue entry gets added via pull request. The community contributes. The catalogue evolves.
Bumblebee checks every scan against it using exact version matching, not fuzzy heuristics, not broad ranges. If the advisory names version 1.2.3, Bumblebee flags 1.2.3 and only 1.2.3. That precision is deliberate. False positives erode trust faster than almost anything else in security tooling, and teams learn to ignore noisy scanners quickly.
The result: within minutes of a new advisory dropping, you know exactly which machines in your organisation are carrying the risk.
What This Looks Like in Reality
Here’s how a security team uses it during an incident. A new compromise is reported, a backdoored version of a popular npm package. The security team updates the Bumblebee threat catalogue with the affected version. They push the updated binary via MDM (Jamf, Intune, or similar). Bumblebee runs silently across the fleet, writing NDJSON to stdout. The results flow into a SIEM or a simple grep script. Within minutes, they know exactly which machines are exposed. No agent to maintain. No permissions to escalate. No code executed on the endpoint. The scan runs, the data surfaces, and the response begins.
For security teams, this matters enormously. The bottleneck during supply-chain incidents has never been detection at the source; it’s been knowing which internal machines are carrying the risk. Bumblebee collapses that window.
Two Scan Profiles
Bumblebee offers two modes. The project profile scans lockfiles and manifests in code repositories, fast, surgical, targeted. The deep profile crawls the full filesystem for every installed package, extension config, and developer tool artefact it can locate. Deep scans produce dramatically larger inventories, the kind that reveal shadow IT, forgotten dependencies, and configurations nobody remembers setting up.
NDJSON as a Feature
The output format is a deliberate architectural choice. Newline Delimited JSON streams naturally into pipelines. Each record is self-contained. You can pipe it to jq, load it into Splunk or Elastic, process it with a Python script, or drop it into an incident response workflow without transformation. The schema is documented and versioned.
What Bumblebee Actually Represents
Bumblebee isn’t just a useful scanner. It’s evidence of a security posture shift that’s been building since XZ Utils in 2024 and accelerated through the PyTorch supply chain compromise and repeated npm malware campaigns of 2025.
The attack surface has moved. Adversaries realised something important: production systems are hardened. CI pipelines have controls. Build artefacts get scanned. But developer workstations? Often a completely different story. Hit the developer machine, and you might reach production before the binary is ever scanned.
There’s a second dimension here, too. The explosion of AI development tooling, MCP servers, AI coding assistants, and local model configs has created an entirely new category of developer endpoint risk that traditional scanners weren’t designed for. Bumblebee reads MCP configuration files explicitly. That’s not a coincidence. It’s recognition that the attack surface now includes the tools developers use to talk to AI systems.
And the decision to open-source it changes the economics of the space. Enterprise security teams can adopt, customise, and integrate Bumblebee without a vendor negotiation, a license fee, or a deployment contract. The community can contribute threat catalogue updates. The tool evolves with the threat landscape.
Key Takeaways
- Perplexity open-sourced Bumblebee after using it internally to secure the developer systems behind Perplexity Search, Comet, and its Computer agent.
- Bumblebee is a read-only developer endpoint scanner written in Go and distributed as a single static binary with zero external dependencies.
- The tool scans eight package ecosystems, browser extensions, AI tool configurations, and MCP server configurations without executing any project code.
- Bumblebee fills a visibility gap between SBOM scanners and EDR tools by inventorying the actual state of developer workstations.
- Its threat intelligence catalog uses exact version matching to identify known compromised packages while minimizing false positives.
- Two scan modes, project and deep, allow teams to perform targeted repository scans or comprehensive filesystem-wide inventories.
- More broadly, Bumblebee reflects a growing security shift: developer laptops, AI tooling, and local development environments are becoming critical software supply-chain attack surfaces.
Conclusion
There’s a quiet irony in the fact that a company known for a generative search engine is the one teaching the security industry to look where nobody was looking. Perplexity builds products that find information others overlook. Apparently, that instinct extends to the security team.
Bumblebee is a small tool in the best sense of that phrase. It does one thing, developer endpoint inventory, and it does it with enough precision, speed, and simplicity that it actually gets used. That’s rarer than it sounds in enterprise security tooling.
The harder question it raises: if Perplexity needed to build this tool to protect their own developer machines, and most organisations haven’t built anything equivalent, what’s sitting quietly on the laptops in your engineering org right now?
