Introducing Beekeeper

The Beekeeper project. Launch announcement for v1.0.0.

Update, June 2026. Beekeeper v1.1.0 has since shipped, formalizing install posture and adding a read-only posture view to the TUI. It is also where the first-responder loop and the corpus flywheel, both already part of this v1.0.0 release, finally get a proper writeup. See Beekeeper v1.1.0.

Modern coding agents are good, and they rarely go rogue. The 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, while you look 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. The thresholds are explicit:

• One trusted source flags a package: warn.
• Two independent sources flag it: block.
• Three sources flag it: block and recommend for quarantine.

A single compromised or poisoned feed can make noise, but it cannot force a block on its own. This 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. 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 a package manager

Even a clean package can carry structural risk in how it is installed. So when an agent reaches for any package manager, Beekeeper checks the install against a default posture at the hook.

This is install posture. Three rules evaluate every package install an agent runs:

• Release age. A package first published less than 24 hours ago warns.
• Lifecycle scripts. An install that would run a pre or post-install script warns.
• Git or remote-URL dependencies. A dependency pulled from a git ref or arbitrary URL instead of a registry warns.

All three warn by default and fail soft. An unknown answer, such as a registry timeout or a missing publish timestamp, warns rather than blocks, so a slow or offline check never stops an agent. The checks are tool agnostic: the same posture applies whichever package manager the agent reaches for.

npm v12 blocks install lifecycle scripts by default, so the old steer-to-pnpm-or-Bun nudge that earlier versions shipped is no longer the headline win. Install posture is the tool-agnostic successor: it applies the same structural checks to every package manager, at the hook. You opt an individual rule up to block, or grant a scoped, audited exception, with beekeeper posture.

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

When the threat is an extension, not a package

The most expensive recent incident came from an extension, 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 read files and reached the network while the editor trusted it.

Beekeeper watches the editor extension directories in real time. It intercepts an agent-initiated --install-extension call before the extension lands, and scans a newly appearing extension against the same catalog and release-age policy. The reaction is first-class, not just a log line: Beekeeper can quarantine a flagged extension on the spot, pull it out of the active set, and give you 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 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 runs 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 scopes 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. It ships with an admin mode and a built-in policy editor that validates a change before it is written, so you 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, 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 every operating system gets 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 does once for everyone. Three steps bring it online:

1. Accept Meta's Llama license.
2. Log in with a Hugging Face token, which stays on your machine. Beekeeper never sees it or sends it.
3. 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. Validation runs in four tiers:

• Local. What can be tested locally is held at full coverage by a gate that fails closed if someone tries to weaken it.
• Platform-bound. What runs on a specific operating system runs in a cross-platform CI matrix with a blocking fuzz gate.
• Manual. 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.
• 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. We dogfood every release through its own defenses:

• reproducible builds,
• keyless signing,
• SLSA Level 3 provenance,
• a software bill of materials,
• and a separately-keyed self-compromise feed, so Beekeeper refuses 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@v1.2.0

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:

• Getting started
• Security posture and known gaps
• v1.0.0 release notes

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