cyrenei/mcp-proxy-firewall
Lightweight proxy that sits between AI agents and MCP, enforcing deny-by-default authorization, session budgets, drift detection, and structured auditing on every tool call. Reduces tool-call attack surface, but does not reduce semantic risk.
Platform-specific configuration:
{
"mcpServers": {
"mcp-proxy-firewall": {
"command": "npx",
"args": [
"-y",
"mcp-proxy-firewall"
]
}
}
}Add the config above to .claude/settings.json under the mcpServers key.
[](https://github.com/cyrenei/arbiter-mcp-firewall/actions/workflows/ci.yml) [](LICENSE) [](https://github.com/sponsors/cyrenei)
A lightweight proxy that sits between AI agents and MCP (Model Context Protocol) servers, enforcing deny-by-default authorization, session budgets, drift detection, and structured auditing on every tool call.
AI agents act autonomously at machine speed. A single misconfigured agent can run DDL on production databases, export customer data, or escalate privileges, with nobody in the loop to stop it.
Applications like Claude Code let us define permissions. But that requires us to place trust in Claude Code. It should go without saying: do not trust the dispensary guy to tell you what to take for back pain; ask him to help you take an edge off.
Arbiter is agnostic of development tooling and enforces:
types diverge from session scope)
See Why MCP Tool Calls Need a Firewall for the full argument, or the QuantumBank case study for a worked example showing 2 allowed and 4 blocked tool categories.
Arbiter governs what agents are allowed to do. It does not govern what agents might try to do. It protects the platform by reducing the tool-call attack surface that agentic applications typically leave open, or require. This is valuable. But a clever-enough hacker with sinister-enough inten
Loading reviews...