"Put a security gateway in front of any MCP server in 5 minutes"

A developer has released mcp-guard, an open-source security gateway that sits between AI agents and MCP servers to enforce authentication, rate limiting, audit logging, and spending controls. The tool, installable via pip, can wrap any MCP server in 30 seconds and includes features like approval queues for expensive tool calls and CI/CD scanning via a GitHub Action.

If you're shipping an AI agent, you've probably wired it up to one or more MCP servers — for filesystem, GitHub, web search, payments. But here's the uncomfortable truth: most MCP setups today have zero auth, no rate limit, no audit log, and no spending control . Anyone who can hit your MCP URL can drain your wallet, exfiltrate your files, or run up a bill on a paid API. There's no firewall. There's no if amount $5, ask me first . There's nothing. I just shipped mcp-guard , a tiny open-source gateway that sits between your agent and any MCP server. It's one pip install and one config file away from being useful. pip install bonanza-mcp-guard mcp-guard scan check your existing config for holes mcp-guard serve wrap any MCP server in 30 seconds Here's what it does, why I built it, and how to wire it into your stack today. When I started shipping agents that talk to paid APIs Stripe, OpenAI, Anthropic, Twilio, weather APIs , I wanted five things that MCP didn't give me out of the box: wallet pay to the value of $50 should require my approval. Always.MCP itself is great. It's a clean protocol. It doesn't try to be a security layer — and that's the right call for a protocol spec. But somebody has to build the security layer. So I did. mcp-guard is a transparent proxy . You put it in front of any MCP server stdio or HTTP and it enforces: 30 req/min , configurable per-agent or globally require approval above: 5.0 → tool calls ≥ $5 get held in the approval queue -32004 approval pending with an approval id . Human runs mcp-guard approvals approve <id . Done. deny: "filesystem.delete", "wallet pay" per server GET /metrics on the HTTP gateway, drop-in for Grafana docker run mcp-guard serve --config /etc/mcp-guard.yaml wallet pay → bonanza, read file → filesystem, default → search.The whole thing is zero required dependencies pyyaml only if you want YAML configs and ~2,900 lines of Python . You can read the whole codebase in an afternoon. pip install "bonanza-mcp-guard yaml " mcp-guard scan This walks your Claude Desktop config ~/Library/Application Support/Claude/ , Cursor config ~/.cursor/mcp.json , and any local mcp.json files. It flags: It doesn't fix anything — just shows you the holes. Create a config file: mcp-guard.yaml auth: mode: api key keys: - ${AGENT API KEY} rate limit: requests per minute: 30 policies: spend cap usd: 100.0 require approval above: 5.0 deny: - filesystem.delete file - wallet pay.bulk transfer audit log: ./audit.jsonl servers: filesystem: command: npx args: "-y", "@modelcontextprotocol/server-filesystem", "/data" Run it: export AGENT API KEY=$ openssl rand -hex 32 mcp-guard serve --config mcp-guard.yaml Your agent now hits mcp-guard instead of the bare MCP server. Everything works the same — but every call is now authenticated, rate-limited, audited, and if it's expensive held for approval. When the agent calls wallet pay with $amount: 10 , it gets back: { "jsonrpc": "2.0", "id": 42, "error": { "code": -32004, "message": "Tool call held for approval", "data": { "approval id": "appr 7f3a9c", "tool": "wallet pay", "amount usd": 10.0, "expires at": 1719336000 } } } You see this in your audit log, your Slack, your phone. You run: mcp-guard approvals list mcp-guard approvals approve appr 7f3a9c The agent retries, the call goes through, the audit log records your decision. State is persistent SQLite , so approvals survive restarts. And require approval above is per-tool, per-amount — $4.99 goes through, $5.01 waits. mcp-guard ships with a GitHub Action that scans your MCP configs on every PR: .github/workflows/mcp-scan.yml name: mcp-scan on: pull request jobs: scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: c6zks4gssn-droid/mcp-guard/.github/workflows/mcp-scan.yml@main I tested it on mcp-guard itself with a .mcp.json fixture — it posted a live comment on the PR with 6 warnings, then merged clean. See the test PR https://github.com/c6zks4gssn-droid/mcp-guard/pull/1 for the actual output. A few things that surprised me: 1. The approval queue is the killer feature. I expected auth and rate limiting to be the headlines. Nope — the moment I shipped the approval queue, every single person who tested it said "oh, this is what I needed." When an agent wants to spend money, you want a human in the loop. That turns out to be the entire pitch. 2. JSON-RPC error codes are your API surface. -32004 approval pending is now a stable contract that tools and dashboards can build against. Pick your extension codes carefully — they're forever. 3. PKCE without a JWT library is easier than I thought. mcp-guard's OAuth2 provider does HMAC-SHA256 signed access tokens with PKCE S256. Zero JWT deps, ~150 lines of code, RFC-compliant. 4. Docker is the secret weapon for stdio MCP. The HTTP transport mcp-guard serve-http is great, but the killer app is wrapping a stdio server in Docker, exposing it as HTTP, and putting a real auth layer in front. Suddenly every MCP server in the world is reachable from a browser tab. I want to be upfront about what's missing: If any of those block you, open an issue. I ship fast when someone files a real bug. pip install bonanza-mcp-guard docker pull ghcr.io/c6zks4gssn-droid/mcp-guard:v0.1.4 If you're shipping agents that talk to MCP servers, give it 5 minutes. Scan your config, wrap one server, send one expensive tool call through it. If it doesn't immediately make sense why you need this, I'm happy to refund your time. About me: I run Bonanza Labs https://bonanza-labs.com — we ship security and tooling for the agent economy. mcp-guard is one of a dozen open-source packages we maintain. Follow me on X @myopenclaw https://x.com/myopenclaw if you want to see what we're working on next.