Hi HN — I built this after noticing how little access control exists around MCP (the protocol behind how Claude and similar agents call out to tools like databases, GitHub, internal APIs).

Some numbers that pushed me to actually build it rather than just worry about it: recent research on MCP deployments reports that only around 18% scope tool permissions at all, roughly half expose credentials as hardcoded values in config files, and most orgs are granting their AI agents more access than they'd give a human employee.

mcp-guardrail is a small proxy you insert between your MCP client and the real server. It reads every tool call, checks it against a policy file you write (allow/deny by tool name, glob patterns supported), and blocks anything not explicitly permitted — the real server never even sees a denied call. Every decision gets written to a local audit log, and there's a separate secret scanner for catching hardcoded credentials in MCP config files before they ship.

It's a CLI, MIT-licensed, no account or hosted component — you run it yourself. 20 tests, and I've run it end-to-end against the official MCP SDK's real client and server to confirm the behavior, not just isolated unit tests.

This is a first release and deliberately narrow — no dashboard, no team features yet. I'd rather find out what's wrong with the core approach now than after someone's depending on it. Genuinely looking for feedback, especially from anyone who's already running MCP servers in something resembling production.