The Security Bouncer

Why the Bouncer exists

Claude Code asks for permission before running every tool — bash commands, file edits, git operations, network calls. Reasonable default. But it breaks long-running work: a 30-minute feature can stall dozens of times on routine approvals, and the human babysitter has to sit in front of the terminal.

The Security Bouncer is a 2-layer, local, auditable tool-approval system that runs next to Claude Code as an MCP server. Safe calls are auto-approved instantly; risky calls are still caught.

Architecture

Claude Code  ──(tool call)──►  Bouncer MCP  ──►  Layer 1: patterns
                                              └──►  Layer 2: Haiku AI
                                              └──►  Layer 3: human (fallback)

Layer 1 — pattern matching

A configurable allow/deny list. Runs in microseconds. Covers common workflows:

• Allow: read files, list git status, run npm test, lint, grep, find.
• Deny: rm -rf /, git push --force to protected branches, curl | sh, raw credential reads.

Patterns live in .mstro/bouncer.json in your project and can be edited by hand or through the Settings UI.

Layer 2 — Haiku AI classifier

Anything that doesn’t match a pattern goes to Claude Haiku with the full tool-call context (command, args, cwd, recent file state). Haiku returnsapprove / deny / needs-human in a few hundred milliseconds. Most ambiguous calls resolve cleanly here.

Layer 3 — human fallback

If Layer 2 flags a call as needs-human, the browser UI shows a Bouncer notification. You approve or deny; your decision is optionally saved back as a pattern.

Audit trail

Every Bouncer decision is logged in .mstro/bouncer.log with timestamp, layer, and rationale — so you can review what an AI agent was allowed to do.

See also

• PM Board — how the Bouncer keeps parallel agents flowing.
• Security & Trust page — the bigger picture.