I built mcp-fence — a proxy that sits between client and server, scanning both directions. Then I tried to break it. 6 rounds of adversarial audits:
* Characters that look identical to humans but are different to computers bypassed every detection pattern
* Invisible characters inserted into keywords defeated all checks
* A specially crafted input made the security scanner itself freeze up
All fixed before release. 1,426 tests, 630 designed specifically to bypass the tool. Also tested against 44 known MCP vulnerabilities (13 CVEs, 86 attack scenarios) — 86% detection rate (remaining are server-side flaws no proxy can catch). OWASP MCP Top 10: 9/10 covered.
Detection is regex-based — a deliberate tradeoff. Regex runs in microseconds, which matters when you're a proxy in the hot path. ML-based semantic detection is planned for v1.x.
npx mcp-fence start -- npx @modelcontextprotocol/server-filesystem /tmp
One line, no changes to your existing server. Default is monitor mode — logs only, nothing breaks. See what's passing through first, then switch to enforcement when you're ready.Background: 9 years in mobile security. Built this after discovering the gap while making nworks (NAVER WORKS MCP server). MIT license.
globalchatads•1d ago
Curious about the regex approach at scale. With agents connecting to dozens of MCP servers simultaneously, how does latency overhead look in practice? The microsecond claim for individual checks makes sense, but the pattern set must grow fast as you add coverage for new attack vectors. At what point would you need to batch or cache pattern compilations?
The monitor mode default is smart for adoption. Did you find that teams who started in monitor mode actually switched to enforcement? In my experience with security proxies, monitor mode tends to become permanent.