Perplexity is turning one of its internal security tools loose in the wild – and that says a lot about where software and AI security are heading right now.

If you spend your days living in terminals, editors, and browsers, Bumblebee is aimed squarely at the world you actually work in: developer laptops, messy project folders, suspicious extensions, and the long tail of tooling that traditional security products usually gloss over.

At a high level, Bumblebee is a read-only scanner Perplexity built to answer a deceptively simple question: “When a new supply-chain vulnerability drops, which of our developers are actually exposed?” Instead of staring at advisories and praying your SBOM or CI scanner catches everything, Bumblebee goes straight to the source – the machines where code is written, tools are installed, and AI agents quietly run in the background.

Why Perplexity is releasing an internal tool

Perplexity frames Bumblebee as part of its broader effort to secure the systems behind products like Perplexity, Comet, and Computer, not just the infrastructure that serves end users. That distinction matters: the industry has spent years obsessing over production environments while attackers increasingly go after the engineers and ecosystems that feed into them.

Supply-chain attacks against ecosystems like npm have become a recurring nightmare: compromised maintainer accounts, malicious updates, and postinstall scripts that silently execute the moment a package is installed. In late 2025, for example, a self-replicating worm dubbed “Shai-Hulud” spread through the npm registry by abusing lifecycle scripts and harvesting developer credentials, then using those secrets to infect more packages. That kind of cascade is exactly the scenario Bumblebee is designed to respond to: a new advisory lands, security teams scramble, and they need a fast way to see which developer endpoints have specific risky packages, versions, or extensions installed.

By open-sourcing Bumblebee as a Go project for macOS and Linux, Perplexity is effectively saying: we built a layer that helped us, and we think the rest of the ecosystem should have it too. It also aligns neatly with the company’s Secure Intelligence Institute push, which focuses on the security and trustworthiness of cutting-edge AI systems and workflows.

What Bumblebee actually does on a laptop

Bumblebee’s job is not to be yet another general-purpose scanner; it tries to fill the gap between SBOM tools, SCA services, and endpoint inventory products. SBOMs and SCA give you an ingredients list of software components in your code and builds, while EDR agents watch for runtime anomalies on endpoints. Bumblebee sits in between: it crawls the local developer environment and tells you, in a structured way, whether a laptop has specific packages, versions, editor extensions, browser add-ons, or AI agent configs that match a catalog of known-bad entries.

Perplexity emphasizes that Bumblebee is read-only by design. Instead of invoking package managers like npm or pip, it reads metadata: lockfiles, manifests, and installed package metadata across languages like npm, pnpm, Yarn, Bun, PyPI, Go modules, RubyGems, and Composer. It does not execute code, run lifecycle hooks, or inspect application source files, which is crucial in a world where the exploit vector is often hidden inside install-time scripts.

Bumblebee also extends its reach beyond packages into the growing sprawl of developer-facing surfaces that have become threat vectors in their own right. It scans:

• Language package managers such as npm, pnpm, Yarn, Bun, PyPI, Go modules, RubyGems, and Composer
• AI agent configurations, specifically MCP-based setups
• Editor extensions for VS Code and VS Code-like editors such as Cursor, Windsurf, and VSCodium
• Browser extensions across Chromium-based browsers (Chrome, Comet, Edge, Brave, Arc) and Firefox

If you think about how people actually work today – AI coding companions, custom extensions, browser-based dev tools – those surfaces are increasingly where malicious code or data exfiltration can slip in, often outside the view of traditional code scanning and server-side controls.

How Bumblebee fits into a security workflow

Perplexity’s own workflow around Bumblebee is fairly structured, and it reveals the intended use case for security teams. When a new threat signal appears – whether from public disclosures, third-party intel feeds, or internal research – Perplexity’s Computer system drafts a catalog entry describing the ecosystem, package name, version, and supporting links.

That catalog change flows through a GitHub pull request, gets human review, and once merged, becomes part of the reference set Bumblebee uses on endpoints. With an updated catalog, Bumblebee runs on developer machines under one of three scan profiles:

• A baseline profile for routine, scheduled scans across standard laptop locations
• A project profile that zeroes in on specific repositories or workspaces
• A deep profile intended for incident response sweeps where you want broad coverage quickly

Each detection is traceable back to the catalog entry that triggered it, including when it was added and what evidence was found on the endpoint. That traceability makes it much easier to explain to engineers why they are being asked to rotate a dependency, remove an extension, or adjust an AI tooling configuration.

Because Bumblebee is read-only and works off metadata, it avoids the classic trap of scanners that actually execute the very tooling they are supposed to inspect. With npm, for example, postinstall scripts are a known avenue for worms and supply-chain malware. A scanner that shells out to npm just to “check” dependencies could inadvertently trigger malicious lifecycle scripts; Bumblebee’s design deliberately steers clear of that by not invoking package managers at all.

Why developer endpoints are becoming ground zero

The philosophy behind Bumblebee comes down to a simple observation: security “starting in production” is now too late. Attackers are increasingly pursuing developers themselves, their machines, and the ecosystems those machines rely on.

We have seen malware families that specifically target developer environments, harvesting credentials, SSH keys, and cloud access tokens, then pivoting into broader infrastructure. At the same time, the tooling landscape for developers has exploded – not only in terms of libraries and frameworks but also in AI-powered editors, browser-based tools, and autonomous agents that can read and write code. Each of those layers introduces configuration files, extension manifests, and network permissions that can be misused if they are not monitored.

Traditional SBOM and SCA tooling solves an important part of the problem by giving you lists of components in your applications and surfacing CVEs tied to those components. But they tend to operate in build pipelines or repository analysis, not on the living, breathing mess of a developer laptop with multiple projects, global package installs, and experimental extensions.

Bumblebee is trying to close that gap by treating the developer machine itself as a first-class security surface. It doesn’t replace SBOMs, SCA, or EDR; instead, it gives security teams a way to run targeted, catalog-driven checks across endpoints when a new supply-chain advisory hits or when they want to audit a particular category of tooling, like AI agents or editor extensions.

Open-sourcing Bumblebee: what this unlocks

By releasing Bumblebee as an open source Go project, Perplexity is giving security teams something they can pick apart, customize, and integrate into whatever fleet management or response workflows they already have. Teams can bring their own threat catalogs, connect Bumblebee’s findings to internal ticketing or SOAR systems, and adapt scan profiles to their particular stack and developer culture.

Open-sourcing also invites scrutiny, which matters in security tooling. Being able to review how Bumblebee reads metadata, how it avoids code execution, and what it chooses to inspect builds trust that the scanner itself is not introducing new attack surface. For developers who are understandably wary of new agents on their machines, a transparent, read-only design is easier to justify than yet another opaque binary that claims to be “for your safety.”

It also signals a broader shift in how AI-native companies think about security. Perplexity has been vocal about wanting to study and defend AI systems through initiatives like the Secure Intelligence Institute, and Bumblebee is a concrete artifact of that mindset applied to day-to-day engineering practices. In an era where AI agents can autonomously install packages, modify configs, and interact with sensitive code, having a tool that keeps an eye on what actually ends up on laptops feels less like a nice-to-have and more like table stakes.

The reality is that no single scanner or framework is going to make software supply chains “safe” in any absolute sense. But tools that focus on where developers actually live – their laptops, their editors, their browsers, and their AI assistants – are a necessary step forward. With Bumblebee, Perplexity is betting that bringing that layer into the open will encourage more teams to treat developer endpoints not as afterthoughts, but as the front line.