MCP-Fence Wants to Make MCP Security Testable Before Your Agent Touches Production
MCP security is getting past the blog-post phase and into the part that matters: tests you can run before an agent is allowed anywhere near production. That is the useful signal in mcp-fence, a new local-first scanner for Model Context Protocol servers. It is not famous yet. At research time the repository had 0 stars, 0 forks, and a same-day creation timestamp. Good. The security tools you want usually look boring before they look inevitable.
The project packages a set of checks aimed directly at MCP’s actual failure modes: static scanning of mcp.json and source, live stdio inspection via initialize and tools/list, schema-aware fuzzing, Docker sandbox profile generation, and SARIF/HTML reporting. The README’s sample output is blunt: a plaintext OPENAI_API_KEY finding contributes to a score=7/100 verdict=FAIL. That is the correct tone for a tool that sits between agent enthusiasm and real credentials.
MCP is an API gateway now. Treat it like one.
MCP’s marketing pitch is a standard connection layer between agents and the systems they need. Strip away the launch language and that means an MCP server is a delegated API gateway for model-generated inputs. It may expose files, browsers, issue trackers, databases, Slack, cloud services, local shell commands, or internal tools. It often has credentials. It often runs close to developer machines. It often receives arguments produced from untrusted documents, webpages, tickets, and chat messages.
That combination deserves more than “please do not prompt-inject the assistant.” Prompt injection is real, but the last few MCP security stories have looked much more like ordinary application security with a bigger blast radius: missing authentication, unsafe transport defaults, overbroad credentials, tool schemas that accept anything, and logs or backups that leak secrets. OWASP’s GenAI guidance says the same thing in more formal language: MCP servers operate with delegated permissions, dynamic tools, and chained calls, so they need strong authentication, authorization, validation, session isolation, and hardened deployment.
mcp-fence is interesting because it is shaped around that boundary. Generic SAST can tell you whether a dependency is known-bad. It generally cannot tell you that a tool description contains hidden instructions, that a parameter called url invites SSRF against cloud metadata endpoints, that additionalProperties is missing from a schema, or that a server binding to 0.0.0.0 is unauthenticated. Those are protocol-and-runtime risks, not just package risks.
The useful part is the sequence: scan, inspect, fuzz, sandbox
The feature list reads like the checklist many teams should already have been writing by hand. Static scanning looks for tool poisoning, dangerous startup commands, plaintext secrets, schema gaps, and unauthenticated HTTP transports. Live inspection currently targets stdio servers, discovering what the server actually exposes over MCP rather than what the README claims it exposes. Fuzzing then pushes payload classes through the tool boundary: path traversal, command injection, SSRF, prompt injection, oversize input, and type confusion.
That ordering matters. Static review catches obvious footguns. Runtime inspection reveals the actual interface. Fuzzing asks the uncomfortable question: what happens when the model sends arguments that are malformed, malicious, too large, or semantically dangerous? Agent systems fail at exactly that seam because models are allowed to compose plausible-looking tool calls from hostile context. The control needs to be close to the tool call, not buried in a quarterly security review.
The Docker sandbox generation is another practical touch. The named modes — strict, filesystem-readonly, network-deny, and dev — acknowledge that teams need operating profiles, not just findings. A toy local MCP server and a production connector to internal systems should not get the same filesystem and network privileges. If your server only needs to read repository metadata, it should not be able to write the working tree or reach the public internet.
The reporting choices are also correctly boring. Plain text helps local triage. JSON supports automation. Offline HTML helps humans review the result. SARIF 2.1.0 means findings can land in GitHub code scanning where engineers already handle security work. That last detail is underrated. Security tools die when they require a separate ritual. They survive when they show up in the review loop developers already use.
Do not confuse a scanner with a security model
The limitations are real. Version 0.1 is stdio-first for live inspection and fuzzing; streamable HTTP, SSE, and websocket are static/config-only today. The project has no adoption signal yet. A scanner can flag risky patterns, but it cannot prove business authorization, rotate secrets, enforce runtime identity, or provide full audit trails. It will miss things. It will false-positive things. That is normal for security tooling; pretending otherwise would be the red flag.
Still, mcp-fence points in the right direction for Claude Code teams and anyone wiring MCP into a coding-agent workflow. Before installing or publishing an internal server, run a protocol-aware scan. Fail CI on plaintext secrets, unauthenticated remote transports, dangerous startup commands, and unbounded high-risk params. Fuzz every tool that touches files, URLs, shell commands, credentials, databases, or outbound network calls. Generate SARIF so the findings become reviewable work, not tribal memory.
Then add the missing controls around it: an approved-server registry, owner, version, permissions, credential source, exposed transport, logs retained, and emergency-disable path. Require human approval for destructive or exfiltrating tools. Use least-privilege credentials per connector, not shared developer supertokens. Log authenticated principal, session ID, tool name, arguments hash, and downstream resource. If an MCP server is compromised, you should be able to answer who used it, what it touched, and how to shut it off.
The editorial take is simple: MCP is becoming the USB-C port for agents. That is useful because everything can plug in. It is dangerous for the same reason. Tools like mcp-fence are the cable tester you run before connecting that port to production. The model is not your firewall. Ship the tests.
Sources: mcp-fence repository, OWASP GenAI secure MCP server guide, Model Context Protocol overview, Claude Code MCP docs