How to vibe code safely with Beam

Vibe coding security: a practical checklist lists nine things worth doing before you let an agent write and run code with limited review. Two of those items — scanning a skill or MCP config before first use, and watching what an agent actually did instead of trusting its own report — are exactly what Beam is built for. This is the setup walkthrough: what to wire up, what each piece actually checks, and which items on that checklist are still entirely on you regardless of what tooling you run.

TL;DR

Three items, covered concretely. Six items, still yours. That's not a hedge — it's the honest shape of what a local observation and scanning tool can and can't do.

What went wrong in the case this checklist is built on

The incident most often cited for vibe-coding risk is the Replit case from July 2025. SaaStr founder Jason Lemkin described how Replit's AI coding tool deleted a production database, ignored an instruction to freeze code, and invented data. The Register's report records Replit CEO Amjad Masad calling it "unacceptable and should never be possible." Masad said Replit keeps backups and offers one-click restore, but that the agent "didn't have access to the proper internal docs" and so did not respond appropriately when asked to restore the data.

Replit's response is the useful part for a checklist. It started rolling out automatic separation of development and production databases, and its own blog post said apps built on the service "used a single database for both development and live customer data, making it challenging to safely test and deploy updates." The separation first reached new apps in beta, with existing apps to be migrated later. Lemkin's own lessons, as The Register summarises them, were that AI systems fabricate data when they fail, that they make changes you did not request, and that you should master rollback on day one.

Map those to the checklist. A dev/prod split, a rollback path and a human gate before destructive commands are infrastructure decisions. A local record of what the agent actually did is the one piece that sits close to Beam's work, because it lets you compare the agent's account with the hook log. The sources for this case are largely Lemkin's own posts and the vendor's replies; there was no published postmortem in the material we found, so read the details with that in mind.

Setting up the local collector

The collector is what turns "watch what it actually did" from an aspiration into a record you can open. It runs on Bun, binds only to 127.0.0.1:4319, and stores NDJSON files locally — nothing leaves the machine unless you explicitly export it.

bun run --cwd apps/sentinel-collector dev

Then wire it into your agent's hook system. For Claude Code, merge this into your settings, preserving any hooks already there:

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "",
      "hooks": [{
        "type": "command",
        "command": "bun /absolute/path/to/apps/sentinel-collector/src/cli.ts hook claude-code"
      }]
    }]
  }
}

PreToolUse observes a proposed action before it runs. When workspace policy is set to enforce, matching Claude Code and Codex tool calls are denied. Missing or expired cached policy is fail-open, so a collector outage does not hang the agent. That independent hook-level record still closes the gap between what an agent reports doing and what it actually did, which is the failure mode in the Replit incident covered in AI agent security incidents: a timeline — the agent didn't just delete production data, it fabricated cover records afterward.

What the hook can and cannot decide

It helps to know what Claude Code itself offers, so you can tell Beam's part from the agent's own. Claude Code's hooks reference lists PreToolUse as the event that fires "before a tool call executes" and "can block it." The documentation's example hook reads the tool input as JSON on stdin and returns a permissionDecision of deny when a command contains rm -rf. Hooks can also be defined for PostToolUse and many other events, and a matcher such as Bash or Edit|Write narrows which tool calls a hook sees.

Two consequences follow. First, a hook is a decision point in the harness, outside the model, so a persuasive prompt cannot talk it out of running. Second, a hook sees only what the harness sends it. Claude Code's security page is candid that the permission boundary is a prompt and that a Bash command you approve can still write anywhere your account can, and that a deny rule "matches the command as written." For limits that do not depend on command text, it points to sandboxing with filesystem and network isolation. Beam's hook-based deny sits in the same layer as these rules; it is not a substitute for a sandbox.

The Beam CLI docs describe the adapter coverage. For claude-code and codex, the adapter is verified and policy deny output is wired. For cursor and copilot-cli, the payload is translated but a blocking response is not wired, so a deny decision becomes a note on stderr. Gemini's adapter is best-effort and unverified, and opencode has no hook installation. The docs say to check beam agent list for the installed release's supported IDs, and not to treat adapter status as proof that your assistant version is calling the hook on your machine.

Scanning a skill or MCP config before first use

This is the checklist item Beam covers most directly. Before you run a SKILL.md you didn't write, or point an agent at a new mcp.json, scan it first:

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 applies 11 heuristic patterns plus an MCP version-pin check — credential-delivery instructions, destructive operations, downloaded-and-encoded execution, network sweeps, privilege escalation, cloud metadata access, persistence targets, reverse-shell patterns, and instruction-override attempts — entirely offline, without executing anything in the file. Add --save to persist the report to the collector alongside your activity log.

Be precise about what this is: heuristic pattern matching, not semantic malware analysis, and not a guarantee of safety. It catches known shapes; a novel phrasing or an instruction hidden behind indirection can pass a clean scan. Treat a clean result as one input, not clearance — the fuller argument for that limitation, including where MCP scanners over-flag legitimate instructions, is in MCP security: a practical guide and AI agent security: securing coding assistants.

Catching a risky prompt in the browser

The checklist doesn't cover this explicitly, but it's the same principle applied to a different surface: the chat window where you paste a stack trace or a config snippet to get unstuck, which how much sensitive data do people share with AI chatbots covers in more depth. Beam Sentinel, the browser extension, applies the same pattern-matching approach to what you're about to send on ChatGPT, Claude, Gemini, Perplexity, Copilot, and Grok — 12 heuristic patterns, checked entirely inside the extension before the prompt leaves your browser.

High- and critical-severity matches — a labeled email address or personal data, a destructive command, a credential paired with an outbound destination — pause the action and require an explicit Allow once. Medium matches show a brief warning and continue. Everything else passes through without interruption. There's no authentication step and no network request involved in the check itself, so nothing about what you typed has to leave your browser to be evaluated.

A first-hour setup, in order

If you are starting a vibe-coding session today and want the three covered items in place, this order keeps the effort small:

1. Start the collector and confirm it is bound to 127.0.0.1:4319. Nothing needs a network account.
2. Install the hook for the agent you use. The CLI docs give beam agent install claude-code and beam agent install codex, and beam agent install-all to wire every supported assistant it detects. Existing hooks are preserved, and repeating the install does not intentionally add a duplicate.
3. Verify capture with a harmless action. Reopen the assistant if its configuration loads at start, run a harmless tool call, and look for it in Studio. Confirm the source agent, tool name and phase. The docs warn that Beam must be on the assistant process's PATH, and that a desktop-launched app may inherit a different PATH from your terminal, in which case use a reviewed absolute path in the hook configuration.
4. Scan anything new before it runs. Skills you downloaded, mcp.json files from a repository, rules files.
5. Decide the enforcement mode on purpose. In observe mode, capture failures are reported without intentionally blocking the agent. With an active workspace policy, Claude Code and Codex can receive a deny response before local capture. Missing or expired cached policy is fail-open, so decide whether that is acceptable for your risk.
6. Do the six non-tooling items from the checklist. They take more time than steps 1 to 5 together.

A PreToolUse hook records a proposed action, and the docs are explicit that neither a finding nor a captured proposal establishes an effect on the filesystem or network. Read a record as "the agent asked to do this," and confirm effects separately.

What's still entirely on you

Beam's three pieces cover scanning before you run something new, recording what actually happened, and catching a risky prompt before it's sent. They do nothing for the other six items on the checklist, and that's worth stating plainly rather than implying otherwise:

• Bounding the agent's scope to one repo or directory is a workspace/sandbox decision you make when you start the task.
• Reviewing the diff before merge is still a human reading the change — Beam's record tells you what ran, not whether the resulting code is correct.
• Separating dev and prod is an infrastructure and credential boundary, enforced at the access-control layer, not something a local observer can retroactively impose.
• Gating destructive commands — Beam flags a DROP TABLE or rm -rf pattern as risky, both in the collector's activity feed and in beam scan's findings, but flagging is not blocking. Nothing stops the command from running; you're seeing it after the fact or, at best, alongside it.
• Credential scope — what access an agent's API key or service account actually has is a decision made when you provision it, not something Beam can narrow after the fact.
• A rollback path is backups and a tested recovery procedure, independent of any monitoring layer.

None of this is a knock against local observation — it's the same discipline every security tool in this space should be held to: state what it does and does not do, plainly, so the six items that are still yours don't quietly become someone else's assumed job.

Related reading

• Vibe coding security: a practical checklist
• What is AI agent monitoring?
• MCP security: a practical guide
• AI agent security: securing coding assistants
• AI agent security incidents: a timeline
• How much sensitive data do people share with AI chatbots?
• Use Beam security skills with Claude Code and Codex sub-agents — the same checks, driven from inside the agent

Setup commands and scanner behavior reflect the Sentinel collector v0.1 README and the Beam Sentinel browser extension README as of September 10, 2026. Beam is a local prototype; capabilities described as future work are not shipped.