Why Beam is open source: agent safety belongs to everyone

A security tool you cannot read is a security tool you are taking on faith. That is an awkward position for any product, and an untenable one for a product whose entire job is telling you what an AI coding agent did on your machine.

So Beam's core is open source. The @agent-beam/beam CLI is AGPL-3.0-only, and so is the separately distributed beam-mcp. That covers the local collector, the scan heuristics, the hook adapters for every supported agent, and the full Skills collection. You can read the rules that decide whether your agent did something alarming, disagree with them, and change them.

What is open, and what is not

The split is not "basic features free, real features paid." It is a split by who the software serves. Everything a developer needs to watch their own agents is open. What you pay for is the machinery an organization needs once many people are running agents and somebody has to answer for it.

Safety is not a premium tier

The argument for open-sourcing the core is simple: the people most exposed to agent risk are frequently the people least able to buy their way out of it. A solo developer wiring Claude Code into a client's repository has the same credential-exfiltration exposure as a bank — with none of the budget and none of the security team.

If the ability to notice that your coding agent just piped a downloaded script into a shell is gated behind a purchase order, then safety is a function of procurement. That is a bad outcome, and it is avoidable. The detection layer costs us nothing extra to give away, and withholding it would buy revenue at the cost of the thing the product claims to care about.

There is a self-interested version of this argument too, and it is worth stating plainly rather than pretending the motive is pure. Open heuristics get corrected. Every developer who reads a rule and finds the regex too broad, too narrow, or trivially bypassable is doing review work we could not buy at any reasonable price.

What "core" actually means

Concretely, the AGPL-licensed CLI at version 0.2.2 includes:

• The local collector. Binds 127.0.0.1:4319, stores normalized events and scan reports as NDJSON under ~/.beam, retains the most recent 10,000 events, and redacts known credential formats, auth headers, and URL query parameters before persistence.
• The scan heuristics. 13 content rules covering destructive operations, credential access and egress, remote and obfuscated execution, network sweeps, privilege elevation, cloud metadata endpoints, persistence targets, reverse shells, instruction-override attempts, git history rewrites, and disabled TLS verification — plus an MCP version-pin check.
• The hook adapters. beam agent install-all detects the agents actually present on the machine and wires Beam's hook into each one's own config, non-destructively.
• The Skills collection. 31 security workflows and 7 specialist reviewer roles in both Claude Code and Codex formats, shipped inside the npm package and usable with or without the CLI.

None of that is a trial. There is no event ceiling that degrades, no rule held back for paying users, and no telemetry.

Why AGPL and not MIT

AGPL is the deliberate choice, and it is a stricter one than most tools in this category make.

Permissive licensing would let a vendor fork Beam, quietly weaken a detection that made their own product look bad, and run the result as a hosted service with no obligation to show anyone the diff. For most software that is a tolerable trade. For software whose output is a security judgment, it is the exact failure mode worth designing against — a weakened scanner is worse than no scanner, because it produces confident silence instead of an obvious gap.

AGPL's network clause means a modified Beam offered as a service has to make its source available. The practical effect for an ordinary user is nothing at all: running Beam on your laptop, at work, on a commercial codebase, triggers no obligation. The clause exists for the one case where it matters.

What the license text says

The reasoning is not only Beam's. The GNU AGPL v3 preamble explains the gap it was written to close: "The GNU General Public License permits making a modified version and letting the public access it on a server without ever releasing its source code to the public." The AGPL, it says, "is designed specifically to ensure that, in such cases, the modified source code becomes available to the community," and it "requires the operator of a network server to provide the source code of the modified version running there to the users of that server."

Read that against a security tool and the case is plain. A hosted scanner that someone has quietly weakened is a service you use without seeing its rules. Under the AGPL, the operator of a modified, network-facing version has to give its users the source. Whether a given operator complies is a separate matter, and a license is a legal tool, not a technical guarantee. It does mean that a deviation from the published rules can be demanded in the open.

Open source is not a verified binary

Publishing code is where review starts, not where it ends. The xz backdoor is a useful reminder. Andres Freund announced it on the oss-security list on March 29, 2024, after noticing odd symptoms on Debian sid installations, such as slow SSH logins and valgrind errors. He wrote that "the upstream xz repository and the xz tarballs have been backdoored," and that one part of the backdoor was "solely in the distributed tarballs": a line that was not in the upstream source of the build file and was not used by xz in git, but was present in the released tarballs for 5.6.0 and 5.6.1.

The lesson for any open-source security tool, Beam included, is that the code you read and the artifact you run can differ. Three habits close most of that gap:

1. Pin the version you install. Beam's own self-hosting guide installs the CLI with an exact version, npm install -g @agent-beam/[email protected], and its self-hosting README says to "install a reviewed CLI release separately, preserving its AGPL license."
2. Read the rules that matter to you. beam rule list prints the active catalog, grouped by category, including the cross-event sequence rules and any errors loading custom definitions.
3. Treat updates as changes to review. A new release of a security tool changes what it flags. Read the changes before you rely on them, as you would for any dependency.

Open code lets someone check these things. It does not mean anyone has.

What the open core does with your data

"Open" and "local" are separate claims, and it is worth stating where the boundary sits. Beam's data and redaction documentation describes it this way: the collector listens on loopback, stores normalized records in a local data directory, and redacts known credential formats, assignments, authorization headers, URL query strings and private keys before persistence. The docs add that pattern-based redaction "is not a complete classification of all confidential information," so arbitrary sensitive prose or proprietary code may remain in records.

A plain beam scan or extraction preview stays offline. Saving a scan, importing locally or using Studio contacts the loopback collector. If a collector is enrolled in a workspace, it can forward events, saved scans and review changes to that workspace, and the docs note that forwarding is best-effort and not a durable retry queue.

There is also an optional integration, Jev action judging, that is disabled by default. When enabled, eligible pre-tool checks send selected action fields to a third-party HTTPS API and can incur charges. Our post on Jev action judging covers what it sends. This is why the FAQ answer below says the open-source version does not phone home by default: the default path has no remote calls, and each remote path is something you turn on or enroll in.

What you can change

An open rule set is useful in a practical way. The rules documentation describes a local file, ~/.beam/rules.json, that holds a JSON array of custom patterns, each with an id, a regular expression pattern, a severity, a category, a title and an explanation. Patterns are evaluated case-insensitively, and the docs advise keeping them narrow and testing both expected matches and benign examples. A custom rule adds findings. It does not become a blocking workspace policy on its own.

That is the right division for a heuristic tool. The built-in catalog is a starting point that you can read. Your own hostnames, internal tools and project conventions are things only you know, so the rules that cover them should be yours.

Where the platform starts

The commercial line sits at the point where the question stops being "what did my agent do" and becomes "what did our agents do, and can we prove it."

That is a genuinely different product. It needs identity, roles, retention decisions, and an administrative record that stands up to somebody reviewing it later. Per the distribution notice, Beam's self-hosting package is proprietary and requires an executed self-hosting agreement plus a Beam-issued license file recording installation, customer, seats, and expiry.

What the platform adds:

• Accountable access. Ownership, administration, security operations, audit, billing, and ordinary membership as separate roles, reviewable and revocable from one workspace.
• A record of administration. Invitations, role changes, policy updates, device enrollment, revocation, and risk reviews — filterable and exportable for internal review.
• A managed device fleet. Enrolled machines and their last activity, revocable device credentials, and shared workspace policies.
• Deliberate rollout controls. Seat allocation, invitation domain restrictions, and a choice about whether to retain full event payloads alongside summaries and findings.

Notice that none of those are detections. They are the organizational apparatus around detections. An auditor does not need a better regex; they need to know who approved a policy change in March and whether the record can be trusted. That is what a control plane is for, and building one is ongoing work that a licence funds.

The honest limitations

The same standard applies to the open-source part as to everything else Beam publishes:

• Beam's deny is hook- and extension-based. Workspace enforce denies matching Claude Code and Codex tool calls; Sentinel can pause or block high-risk browser sends. The open collector still records, redacts, and flags. It is not a kernel sandbox.

• The scanner is heuristic, not semantic. 13 patterns and a version-pin check will miss a sufficiently novel payload. It is a first pass, not a malware analysis engine.

• Open source is not a security audit. Publishing the code makes review possible; it does not mean the review has happened. Read the rules before you trust them.

• A license is not a promise about behaviour. The AGPL obliges operators of modified network versions to share source. It does not make Beam's detections complete, and it says nothing about whether a given build matches a given commit. That is why version pinning and reading the rules come first.

If any of that changes, it changes in public, in a repository you can watch.

How to try the open core

If you want to judge the argument by running the thing, the shortest route is the local-first introduction and the vibe coding setup walkthrough. For the concept behind it, what AI agent monitoring is explains the difference between watching an agent and constraining it. Pick one agent, run the scan on one skill or MCP configuration, and read the findings against the rule that produced them. If the rule is wrong for your setup, you now know how to change it.

Related reading

• Introducing Beam: a local-first security console for your AI coding agents — the architecture the open-source CLI implements
• Use Beam security skills with Claude Code and Codex sub-agents — installing the Skills collection described above
• AI agent guardrails: monitoring vs. blocking — how laptop policy differs from kernel sandboxes
• AI agent security platforms: how to evaluate one — what to ask of any tool in this category, including this one
• AI compliance and regulation for agent activity — the auditor-facing requirements the platform tier answers
• Enterprise and self-hosting — the commercially licensed deployment

Version numbers, licence terms, and capability descriptions reflect @agent-beam/beam v0.2.2 and the Beam self-hosting distribution notice as of September 14, 2026. Beam remains an early product; the open-source core is the part you can verify for yourself.