Skip to main content
BEEKEEPERv1.0.0

Introducing Beekeeper

What Beekeeper actually stops, told as a story: malicious package installs caught by a corroborated, always-fresh catalog; npm steered to hardened package managers; editor-extension exfiltration met with real-time quarantine; then the behavioral, cross-platform, and AI layers. Plus what is proven versus what is still only designed.

The Beekeeper project. Launch announcement for v1.0.0.

Modern coding agents are good, and they rarely go rogue. The scary "hijacked agent" is not where real incidents come from. The real risk is quieter and far more common: an agent faithfully does what you asked, and on the way pulls in a compromised package or a trojanized editor extension. The agent is not the attacker. The supply chain is. And the agent now runs that supply chain on your machine, at machine speed, often while you are looking at something else.

Beekeeper v1.0.0 sits between the agent and the operating system and stops the specific things that actually go wrong. This is the story of what it stops, told in the order the pieces connect.

When an agent installs a package

Your agent decides it needs a dependency and runs npm install some-pkg. Before that command executes, Beekeeper's check hook evaluates it.

The decision comes from a corroboration engine, not a single blocklist. A package flagged by one trusted source is a warning; flagged by two independent sources, it is blocked; by three, it is blocked and recommended for quarantine. A single compromised or poisoned feed can make noise, but it cannot force a block on its own. It is two-factor authentication for threat intelligence.

That only holds if the intelligence is current, so Beekeeper keeps it current for you. An unprivileged, per-user sync daemon refreshes the catalogs on a schedule (every 2 hours by default, using conditional requests so an unchanged feed is nearly free), and a repository you have cloned cannot quietly turn that sync off or slow it down. The catalog draws on Bumblebee's threat-intel feed, the same project that inventories the packages already sitting on a machine. Bumblebee tells you what is on the machine. Beekeeper stops the bad thing from getting onto it in the first place.

When an agent reaches for npm

Even a clean package is safer installed through a package manager that actually defends the supply chain. So when an agent reaches for npm or yarn, Beekeeper does not just watch, it steers.

This is the nudge. By default it advises. Once you install the hook it switches to blocking npm and yarn installs and pointing the agent at pnpm or bun instead, which ship structural defenses npm does not: minimum-release-age gating, so a package published an hour ago cannot be pulled straight into your build; stricter lifecycle-script handling, so a postinstall script cannot run unannounced; and a content-addressed store. You can dial this from block back down to advisory with a single config key, and the block is enforced independently of detection, so it does not quietly fail open if a probe times out.

It is the same hook and the same fail-closed posture as the corroboration check: two different supply-chain protections riding one evaluation point.

When the threat is an extension, not a package

The most expensive recent incident was not a package. In May 2026 a trojanized VS Code extension in the Nx Console supply chain exfiltrated thousands of internal repositories before anyone noticed. The extension never broke out of anything. It simply read files and reached the network while the editor trusted it.

Beekeeper watches the editor extension directories in real time. An agent-initiated --install-extension call is intercepted before the extension lands, and a newly appearing extension is scanned against the same catalog and release-age policy. The reaction is first-class, not just a log line: a flagged extension can be quarantined on the spot, pulled out of the active set, with restore and purge controls if you disagree. This is the part that turns Beekeeper from "noticed something" into "stopped something."

One caveat, because this is a security tool: we have validated that this path is wired correctly and its design is sound, but we have not yet fired a live, purpose-built exploit at it to watch it catch one. The structure is proven; the red-team kill is not yet.

When the catalog freshens

The catalog sync does more than refresh a blocklist. Every time the background sync produces new entries, Beekeeper runs a read-only cross-reference of the packages already sitting on your machine against the updated index. A match is audited as a scan hit. The cross-reference never removes, disables, or edits a package on its own.

When a scan hit reaches the corroboration threshold (two independent sources by default), Beekeeper can optionally move the artifact to a reversible quarantine directory. This is opt-in and starts in dry-run mode, so a fresh install quarantines nothing automatically. When it does move something, the move is a reversible directory rename with a restore manifest, not a delete. The permanent purge is always human-gated: the TUI surfaces the incident with a [P] purge option and a [R] restore option, and the purge command requires a y/N confirmation.

A corroborated hit does one more quiet thing: it tells the Sentry daemon (below) to watch that package's processes more closely, lowering its credential-access thresholds on that subtree. That tightening is detection-only, and it means even a dry-run quarantine still sharpens the behavioral layer. A single-source warn does not trigger it; the same two-source bar as the quarantine move applies.

The structure of this path is proven; a live exploit test against it is still outstanding.

The deeper watch: the Sentry daemon

Some exfiltration does not show up at install time. It shows up as behavior: a burst of credential-file reads, a first outbound connection, a write to a persistence location.

For that, Beekeeper has an optional, privileged Sentry daemon that correlates process, file, and network events into a small set of exfiltration-pattern rules, SENTRY-001 through SENTRY-008, on Linux, macOS, and Windows. It is scoped to the processes that matter, the descendants of editors and agent CLIs rather than your whole system, and it is detection-only by design: it writes the evidence while containment stays in the watch-and-quarantine layer above it. It already ingests file-write and DNS-query events; turning the DNS stream into a tunneling rule is still future work.

The Sentry is opt-in through beekeeper protect install. The unprivileged tool is fully useful without it. The Sentry is the deeper tier for people who want behavioral coverage.

Making it yours: the dashboard and policy editor

All of this stays legible. beekeeper dashboard is a terminal UI showing live activity, alerts, catalog freshness, scans, active policies, and quarantine, with an admin mode and a built-in policy editor that validates a change before it is written, so you can tune what is allowed without hand-editing JSON and hoping. Policy is declarative and version-controllable, and Beekeeper protects its own configuration from the very agents it is policing: the agent cannot read or rewrite Beekeeper's state, overwrite its binary, or remove its own hook.

Cross-platform inventory: Bumblebee and Pollen

The scan-and-inventory side leans on Bumblebee, which is the upstream tool on macOS and Linux. Bumblebee has no native Windows build, so on Windows Beekeeper resolves to Pollen, a Windows-focused fork of Bumblebee, as the local scanner. The threat intelligence arrives over HTTP the same way on every platform; only the on-machine scanner differs, so no operating system is left without coverage.

The optional AI layer: LlamaFirewall

For teams that want a model in the loop, Beekeeper can run an optional LlamaFirewall sidecar that scores tool output for prompt injection and agent-written code for unsafe patterns, entirely on your machine, with no API key and no third-party cloud. It is off by default and fails closed if it cannot run.

Because its model is gated, turning it on is a deliberate, per-operator step rather than something Beekeeper can do once for everyone. You accept Meta's Llama license, log in with a Hugging Face token (which stays on your machine; Beekeeper never sees it or sends it), and run beekeeper llamafirewall install to bootstrap a local, CPU-only environment and pull the gated model. The full sidecar runs on Linux and macOS; native Windows is unsupported because one of its dependencies has no Windows build.

What is proven, and what we ask you to verify

A security tool that asks for trust has the threat model backwards. So Beekeeper publishes its gaps next to its posture, and it makes validation auditable instead of asserted. What can be tested locally is held at full coverage by a gate that fails closed if someone tries to weaken it. What is platform-bound runs in a cross-platform CI matrix with a blocking fuzz gate. What cannot be automated, a real live block on each non-Claude-Code harness, lives in a signed manual register with a sign-off line per row. And the frontier, a live exploit fired at the quarantine and Sentry paths to watch them catch it, is named as outstanding.

Beekeeper is also the first thing it watches: reproducible builds, keyless signing, SLSA Level 3 provenance, a software bill of materials, and a separately-keyed self-compromise feed so it can refuse to run a tampered build of itself.

Try it

When the release is published, setup runs in five steps. Each command is its own copyable card on purpose: the steps are sequential and each depends on the one before it, so you run and confirm them one at a time rather than pasting them as a block.

1. Install the binary.

go install github.com/home-beekeeper/beekeeper/cmd/beekeeper@latest

2. Create the state directory and detect installed editors.

beekeeper init

3. Sync the threat catalog and build the on-disk index.

beekeeper catalogs sync

4. Install the background sync so the catalog stays fresh on its own.

beekeeper catalogs daemon install

5. Install the hook for your agent (here, Claude Code).

beekeeper hooks install --target claude-code

The install path and signed release artifacts above resolve today. For the full picture, read the design, the security posture and its known gaps, and the verification commands:

Beekeeper is Apache 2.0. It is built to be read, audited, and distrusted until it earns the opposite. That is the point.