If you are comparing AI agent security tools, the first honest question is not "which vendor has the flashiest dashboard" — it is whether you need runtime blocking or runtime evidence. Most well-funded "AI agent security platforms" in 2026 sell enforce-first guardrails: deny a tool call, strip a prompt, or cut a session when policy says so. Beam v1 does none of that. It watches what coding agents do on your machine, flags risky patterns, and scans skills and MCP configs with heuristics before you run them — locally, with no default cloud telemetry. This post answers the buyer objection head-on: why observe-only is a deliberate v1 boundary, when that is the right fit, and when you should pay for enforce-first instead.
Quick reference
| Question | Answer |
|---|---|
| Does Beam v1 block agent actions? | No. It observes, flags, and stores evidence locally |
| Does the Claude Code hook return allow/deny? | No — per README, it emits no allow/deny response |
| What does the scanner do? | 11 heuristic patterns + MCP version-pin check; does not intercept installs |
| Who typically needs blocking? | Org-wide policy in the network/API path, many developers |
| Who typically needs monitoring first? | Individual developers, small teams, audit/evidence before policy |
| Where does data live? | apps/sentinel-collector/.data, mode 0700/0600, redaction before write |
The objection: "Serious tools block — why doesn't Beam?"
Fair question. In how to evaluate AI agent security platforms, we split the category into four layers. Enterprise runtime-enforcement platforms — the ones security teams often shortlist after a board slide about "AI guardrails" — usually sit in the network or API path and block (or rewrite) calls that violate centralized policy. Local endpoint monitors and pre-run scanners more often observe and flag, because they run on the developer's machine or against a file before execution, not inline with every model request across the company.
Beam sits in the second camp today: local-first agent runtime monitoring plus MCP and skill scanning. Saying "we don't block yet" is not dodging the comparison; it is naming the layer. If your RFP requires "must deny rm -rf before it executes org-wide," an enterprise enforcer is the product shape you are buying. If your problem is "I run Claude Code on my laptop and I don't actually know what it did yesterday," blocking in a vendor cloud does not replace a timeline on the machine where the shell ran.
What Beam v1 actually does (README-grounded)
Product claims here trace to apps/sentinel-collector/README.md — the Sentinel collector Beam ships against.
Runtime observation. The collector binds to 127.0.0.1:4319, accepts normalized events (Claude hooks, NDJSON, Numbat imports, OTLP/HTTP JSON), and retains the latest 10,000 events and 500 reports. Known credential formats are redacted before persistence; detection runs on incoming text first.
No enforcement in the hook path. For direct Claude Code wiring, the README is explicit:
Sentinel v1 does not implement blocking.
The hook CLI "sends a bounded request to the collector and emits no allow/deny response. Capture failure is reported on stderr and does not stop the agent."
That design choice matters for guardrails semantics: observation must not become a new way for your agent to hang, fail closed on a collector outage, or fight the harness for control. How to vibe code safely with Beam walks through wiring PreToolUse with that boundary in mind.
Pre-run scanning, not interception. Skill and MCP scanning uses 11 heuristic patterns plus an MCP version-pin check — credential references, deletion, downloaded/encoded execution, network sweeps, privilege changes, persistence targets, reverse shells, instruction overrides, and related shapes. The README again:
It is not semantic malware analysis or a guarantee of safety. Scanning is explicit; package pulls and skill installation are not automatically intercepted.
You run:
bun run --cwd apps/sentinel-collector cli scan /absolute/path/to/SKILL.md
bun run --cwd apps/sentinel-collector cli scan /absolute/path/to/mcp.json --mcp
The scanner flags; it does not stop the install. Same pattern as the vibe coding security checklist recommends: review or scan before first use, not after an incident.
Explicit non-goals in v1. Pairing is for local single-user testing. The README lists as future work: shared fleet management, SSO, database-backed teams, enforcement, and approvals. Beam is a prototype in that sense — useful today for watch-and-flag, not a stand-in for enterprise policy engines.
Monitor-first vs enforce-first: picking a model
These are not "good vs bad" product philosophies. They are different control points with different failure modes.
When enforce-first fits
Choose blocking-centered guardrails when:
- Scope is organizational, not one laptop — hundreds of developers, contractors, and agents sharing API keys and data paths.
- Policy is already written — you know which tool classes must never run, which data classes must never leave a region, and you are ready to operationalize denials (with an owner for false positives).
- The control point is centralized — gateway, proxy, or SaaS API path where every agent call can be evaluated once, consistently.
- Preventive controls are the audit ask — see AI compliance and regulation for agent activity: an observe-only tool satisfies detective controls, not preventive ones by itself.
Enterprise platforms exist because those requirements are real. Beam does not pretend to replace them in v1.
When monitor-first fits
Choose observation-centered guardrails when:
- You are still mapping behavior — before you automate deny rules, you need to see real
PreToolUsepayloads, MCP calls, and file writes on your projects, not a demo tenant. - False positives have a high cost — legitimate agent work looks scary out of context. Research on human approval of agent commands found reviewers both miss roughly one in three threats and block harmless commands often (for example routine
npm config set registryblocked about 59% of the time in one 409,000-decision study). See humans miss 1 in 3 AI agent command threats. Automated blocking amplifies the second failure mode unless policy is mature. - Data must stay local — NDJSON under your user, directory
0700, no default egress. That is Beam's core trade: evidence without a new vendor data processor. - Human-in-the-loop is already there but amnesiac — approval prompts scroll away; agents misreport. What is AI agent monitoring defines the problem as endpoint-side effects, not model traces. Monitoring adds memory independent of the agent's narrative — the Replit-class failure mode in AI agent security incidents: a timeline.
Monitor-first is also the right phase one for teams that will eventually enforce: you cannot write sane deny rules without knowing what normal looks like on your stack.
How the layers stack (without pretending one tool does all)
Think in moments, not megaphone marketing:
| Moment | Typical tool shape | Blocks? | Beam v1 |
|---|---|---|---|
| Before connecting an MCP server or skill | Static scanner | Usually no | Heuristic scan + flag |
| While the agent runs on a dev machine | Endpoint monitor | Often no | Observe + flag |
| Across org API/model traffic | Enterprise platform | Usually yes | Out of scope |
| Production LLM app debugging | Observability | No (not security-focused) | Different problem |
AI agent security platforms: how to evaluate one is the longer map. Scanners and monitors are complementary: scan before trust, monitor after approval. Blocking platforms add central denial where the traffic aggregates.
Beam does not block the middle row either — and that is consistent with the README's hook contract. Enforcement belongs either above (org gateway) or below (OS sandbox, separate approvals product) until Beam explicitly ships it.
What monitoring still buys you today
Observe-only is not "security theater" if you use the evidence:
- After-action review — open flagged events, inspect command and path evidence, mark reviewed. Retention caps mean this is a working set, not infinite SIEM — 10,000 events is plenty for iterative dev, not fleet forensics.
- Independent record vs agent self-report — when an agent deletes data and then fabricates cover records, a hook-level timeline is the difference between suspicion and proof. Monitoring does not prevent the first deletion; it makes the cover story harder to sustain.
- Scan-before-run discipline — pair runtime flags with explicit
cli scanon new skills, the same habit as the vibe coding checklist's "treat SKILL.md as executable trust." - Export for review — investigation exports with SHA-256 hashes establish internal consistency; they are not a compliance pass by themselves, as the README notes.
For a concrete setup path, see introducing Beam and how to vibe code safely with Beam. For landing-page framing of what watches vs what stays local, see /#watches and /#local.
Will Beam ever block?
The README lists enforcement and approvals as future work, not shipped behavior. Any future blocking would need the same honesty bar: clear false-positive handling, no silent agent breakage on collector downtime, and explicit scope (single-user local vs fleet). Until then, describing Beam as "preventive" or "zero-trust enforcement" would be wrong — same reason what is AI agent monitoring states plainly that v1 does not prevent anything.
If you need blocking now, buy or build at the layer that matches your scope: sandbox the agent, tighten credentials, use harness-native approval, and add an enterprise enforcer if the problem is org-wide model traffic. If you need visibility on your machine first, Beam's v1 boundary is intentional.
Frequently asked questions
Why doesn't Beam block risky agent commands in v1?
Sentinel v1 does not implement blocking. The Claude Code hook records events locally and does not return allow/deny; failures to capture do not stop the agent. Beam prioritizes local evidence and heuristic scans before shipping enforcement.
Is monitoring without blocking useless?
Not for audit trails, post-incident review, and closing the gap between approvals and actual side effects. It is not sufficient when your requirement is centralized preventive denial — that is enforce-first tooling at the enterprise layer.
When should I buy a tool that blocks?
When policy must apply org-wide in real time across many users, with centralized dashboards and SIEM-style integration — the enterprise-platform category in our evaluation guide.
When is monitor-first the right default?
When you are learning normal agent behavior on your stack, when false positives would block real work, when data must stay on-device, or when human approval needs a durable record behind it.
Does Beam's skill scanner block installation?
No. Scanning is explicit and heuristic; installs and package pulls are not automatically intercepted.
Can I use Beam alongside a blocking platform?
Yes, at different layers — local timeline plus org-wide enforcer is a common pattern. Beam does not replace API-path blocking; it complements it with endpoint evidence.
Related reading
- AI agent security platforms: how to evaluate one
- What is AI agent monitoring?
- Vibe coding security: a practical checklist
- Humans miss 1 in 3 AI agent command threats
- How to vibe code safely with Beam
- Introducing Beam: local-first security for coding agents
- Why Beam is open source — the observe-only rules described here are AGPL-licensed and readable
- How to stop Claude Code from running dangerous commands — the enforcement layer (permission rules, hooks) that pairs with Beam's monitoring
- Compare Beam against other platform layers
Product behavior and limits reflect apps/sentinel-collector/README.md (Sentinel collector v0.1) as of September 12, 2026. Beam is a local prototype; enforcement, fleet management, and SSO are documented as future work, not current capabilities.