MCP Firewall

What behrensd/mcp-firewall MCP server does

The behrensd/mcp-firewall MCP server acts as a policy enforcement layer for MCP connections. It runs between an MCP client such as Claude Code, Cursor, or Windsurf and one or more downstream servers. Requests and responses pass through the proxy over stdio.

Inbound rules can restrict access to sensitive paths such as SSH directories, environment files, credentials, and browser data. They can also reject command patterns such as recursive deletion, pipe-to-shell behavior, or other configured matches. Tool arguments can be checked for secrets using configured regular expressions and entropy thresholds.

Outbound rules inspect server responses before they reach the client. A matching response can be forwarded, replaced with a blocked message, logged without modification, or selectively redacted. This also supports checks for prompt-injection text and responses larger than a configured byte limit.

How it works

For each JSON-RPC request, the proxy identifies tools/call messages, extracts the tool name and arguments, and evaluates rules from top to bottom. The first matching rule determines the result. An allowed request is sent to the real MCP server; a denied request produces a JSON-RPC error, is logged, and is not forwarded.

Responses follow the same first-match-wins model through a separate outbound rule set. Secret matches can be replaced with [REDACTED BY MCPWALL], while denied responses are replaced with a blocked message. The implementation uses fixed rules rather than model-based decisions, and it records activity as JSON Lines audit data.

Setup and configuration

Install the npm package globally with npm install -g mcpwall, or invoke it with npx. To protect an existing server, place mcpwall -- before that server's command in the MCP client configuration. The init command can discover servers in Claude Code, Cursor, Windsurf, and VS Code configuration files and wrap them. A Docker MCP Toolkit gateway can likewise be placed behind the proxy.

Configuration is written in YAML. The global file is ~/.mcpwall/config.yml; a project-level .mcpwall.yml can override it. If neither file exists, built-in defaults are used. Settings include the log directory, log level, default action, and an optional per-tool rate limit. Rules support regular expressions, glob patterns, path checks with not_under, and secret scanning. Environment substitutions documented by the project include ${HOME} and ${PROJECT_DIR}.

Tools and capabilities

The behrensd/mcp-firewall MCP server provides these command-line workflows:

• Run as a transparent stdio proxy around another MCP server.
• Use init to wrap discovered MCP configurations.
• Use wrap to wrap a named server.
• Use check to test a tool call against the configured rules without starting the proxy.
• Apply inbound allow or deny policies to tool calls.
• Apply outbound allow, deny, redact, or log-only policies to responses.
• Write JSON Lines audit logs for tool calls and responses.

Limitations and notes

The proxy does not provide an interactive approval action; policies must explicitly choose allow or deny. Default behavior can be changed with default_action, including a deny-by-default configuration. Secret detection depends on the configured patterns and entropy settings, so deployments should review and maintain their YAML rules. The material describes stdio proxy operation rather than a hosted endpoint, API authentication, or cloud service.