Developers are rapidly connecting autonomous AI coding assistants (Cursor, Claude Desktop, Windsurf, Zed, or custom LLM frameworks) directly to local systems via the Model Context Protocol (MCP).
While giving AI access to terminal execution, filesystem tools, and databases dramatically accelerates software development, it introduces a severe, unmonitored security vulnerability: AI tools execute locally as opaque black boxes.
A single hallucinated command like rm -rf / or DROP TABLE users;, or sensitive production credentials leaked in outgoing tool arguments via prompt injection, can corrupt entire codebases or compromise critical infrastructure in seconds.
To solve this foundational security blindspot, I built and open-sourced MCPBouncer — a zero-dependency, local-first desktop action firewall and live packet inspector for MCP.
🛑 The Core Problem: Autonomous AI Agents Have Too Much Local Power
When AI assistants interact with local developer environments via standard MCP servers (filesystem, terminal, postgres), there is zero visibility into what packets are flowing across stdio streams:
-
Secret Exfiltration & Credential Leaks: An agent reading a
.envfile, AWS config, or private SSH key can inadvertently (or via indirect prompt injection) leak those tokens inside tool call arguments sent to secondary tools. - Destructive Local Accidents: Autonomous agents executing commands without explicit human-in-the-loop authorization can wipe databases, format drives, or delete critical system directories before the developer notices.
- Indirect Prompt Injection & Steganography: Reading untrusted web pages or malicious files can hijack the agent's instructions, using zero-width Unicode characters or hidden Markdown image exfiltration to steal data silently.
- Zero Auditing & Visibility: Traditional developer tools provide no unified, real-time packet inspection for AI tool calls.
🛡️ Introducing MCPBouncer: The Desktop Firewall for MCP
MCPBouncer acts as an inline, zero-trust security proxy between your AI client and downstream MCP servers, backed by a real-time web/desktop security center.
✨ Key Enterprise Features:
-
🔍 Wireshark-Style Live Inspector: A high-performance local dashboard (
http://127.0.0.1:4114) displaying every JSON-RPC 2.0 tool call, parameter, execution duration, and response in real time. - 🚨 Human-in-the-Loop Interception: High-risk destructive commands (SQL drops, recursive shell deletions, disk operations) are automatically paused, popping up an instant [ALLOW / BLOCK] desktop confirmation banner.
- 🔒 Automated Outbound DLP (Data Loss Prevention): A sub-millisecond ReDoS-bounded regex engine automatically detects and sanitizes API keys (OpenAI, Anthropic, AWS, GitHub, Stripe, Slack) before they can leak.
- 🦁 Steganography & Injection Shield: Identifies instruction overrides, jailbreak personas, and hidden zero-width Unicode smuggling.
- 📜 Cryptographic Audit Trail: Every tool execution generates an immutable SHA-256 action receipt stored in a local tamper-evident ledger for SOC2/ISO compliance.
- 🌐 100% Offline & Private: Zero cloud telemetry, zero remote tracking. Everything runs completely locally on your hardware.
🚀 Getting Started in 30 Seconds
MCPBouncer requires zero complex setup. You can scan and protect your existing AI IDEs using the CLI:
bash
# 1. Scan your registered Cursor and Claude Desktop MCP servers
npx mcpbouncer scan
# 2. Automatically wrap and shield all detected servers
npx mcpbouncer protect --all
# 3. Launch the local real-time security dashboard
npx mcpbouncer dashboard
Open http://127.0.0.1:4114 in your browser to observe packets, approve pending actions, and inspect payloads in real time.
📦 Open-Source & Community
MCPBouncer is completely open-source under the Apache-2.0 License.
GitHub Repository: https://github.com/mcpbouncer/mcpbouncer
Tech Stack: TypeScript, Node.js, React 19, Tailwind CSS, Vite.
I would love to get your feedback: What dangerous permissions or edge cases do you worry about most when letting AI agents run autonomously on your machine?
Top comments (2)
@cipher_sanchez, placing an inline policy boundary between the client and MCP server is the right architectural seam; the model cannot argue with an external allow/block decision. The action receipt is most useful if it binds the normalized request, policy version, decision, and downstream result—not only the tool call. Does MCPBouncer distinguish an execution failure from an ambiguous outcome where the side effect may have happened after the proxy forwarded it?
aa