I built an open-source MCP server for pfSense — and tried very hard not to give the AI unrestricted firewall write access
I've been working on pfsense-mcp-server, an open-source MCP server that lets AI assistants interact with pfSense.
The easy part was exposing the pfSense API to an LLM.
The part I cared much more about was making sure an AI agent couldn't simply turn a tool call into unrestricted firewall changes.
The current v0.4.2 release has:
- 42 MCP tools
- 0 WRITE capabilities reachable by default
- explicit operator opt-in before WRITE is enabled
- a dedicated least-privilege pfSense identity
- separate signed authorization and confirmation boundaries
- plan/intent binding so an approval can't silently authorize a different mutation
- expiring, one-time authorization
- RecoveryContracts and a state machine around mutations
- deterministic post-WRITE read-back instead of treating HTTP success as proof
- reconciliation/fail-closed handling for uncertain outcomes
- TPM-backed anti-rollback witness support
For the first live WRITE acceptance test I used a disposable firewall alias on a LAB pfSense system.
The complete path was exercised end-to-end, including the scoped pfSense account, authorization/confirmation ceremony, real PATCH, authoritative read-back, RecoveryContract audit trail and TPM witness advancement.
The alias was subsequently restored through the same controlled path.
The project deliberately still starts READ-only. Installing it does not automatically expose WRITE tools.
I'm particularly interested in hostile review from people who know pfSense well.
Things I'd love people to challenge:
- Is the pfSense REST API privilege set actually minimal?
- Are there HA/CARP or config-apply edge cases I've missed?
- Can authorization/confirmation be replayed or confused across operations?
- Are there state-machine paths that could permit a blind retry after an uncertain WRITE?
- Are the RecoveryContract/reconciliation assumptions sound?
- Is there any realistic path from the default READ posture to WRITE without the intended operator decisions?
This is not affiliated with or endorsed by Netgate.
Current release: v0.4.2
GitHub: https://github.com/night4me/pfsense-mcp-server
PyPI: https://pypi.org/project/pfsense-mcp-server/
I'd genuinely prefer someone finds a security flaw now rather than after people start relying on it.