pg-guard-mcp

Ein PostgreSQL-MCP-Server, der schreibgeschützten Zugriff auf der Protokoll- und Berechtigungsebene erzwungen — nicht, indem er den Query-String parst und hofft.

Installation

pip install pg-guard-mcp
# or, without installing anything permanently:
uvx pg-guard-mcp

Related MCP server: MCP PostgreSQL Read-Only Server

Warum es das gibt

Das offizielle Paket @modelcontextprotocol/server-postgres wurde mit einem Read-only-Modus ausgeliefert, den ein einzelnes COMMIT; umgehen konnte: Es verpackte die Abfrage des Agenten in BEGIN TRANSACTION READ ONLY und schickte das Ganze als einen String. Postgres akzeptiert in diesem Zustand semikolongetrennte Mehrfachanweisungen, so beendete SELECT 1; COMMIT; DROP SCHEMA public CASCADE; die Read-only-Transaktion frühzeitig und führte das DROP als gewöhnlichen Schreibzugriff aus. Das Paket wurde deshalb als deprecated markiert. (Bericht von Datadog Security Labs)

pg-guard-mcp existiert, weil diese Fehlerklasse – „read-only“, nur durch String-Inspektion erzwungen – im MCP-Ökosystem immer noch verbreitet ist. Es verteidigt auf drei unabhängigen Ebenen, sodass kein einzelner Fehler fatal ist:

1. Protokollebene (die eigentliche Grenze). Jede Anfrage läuft über das erweiterte Anfrageprotokoll von Postgres (Parse/Bind/Execute), niemals über das einfache Anfrageprotokoll. Das erweiterte Protokoll lehnt strukturell mehr als eine Anweisung pro Parse-Nachricht ab – Postgres selbst weist es ab, bevor irgendein Code von uns ausgeführt wird. Deshalb kann der Datadog-Exploit hier nicht funktionieren, egal welcher String übergeben wird.

2. Sitzungsebene. Jede Verbindung setzt default_transaction_read_only = on auf Sitzungsebene, sodass auch eine Abfrage, die tatsächlich als Schreibzugriff in der Datenbank ankommt, von Postgres abgelehnt wird.

3. Preflight-Ebene. Bevor eine Abfrage überhaupt gesendet wird, wird sie auf mehrere Anweisungen und Schlüsselwörter der Transaktionskontrolle (COMMIT, ROLLBACK, BEGIN, SAVEPOINT, ...) geprüft und mit einer klaren Fehlermeldung abgewiesen. Das dient dafür, schnell und laut zu scheitern – nicht als primäre Verteidigung.

Außerdem ist die Verbindung mit einer Datenbankrolle, der Schreibrechte per REVOKE entzogen wurden, die empfohlene (und beim Start überprüfte) Einrichtung – Gürtel und Hosenträger auch auf der Berechtigungsebene.

Werkzeuge

Einrichtung

pip install pg-guard-mcp
export PG_GUARD_DSN="host=127.0.0.1 dbname=mydb user=myapp_readonly password=..."
pg-guard-mcp

Richten Sie Ihren MCP-Client auf den Befehl pg-guard-mcp aus (oder uvx pg-guard-mcp für den Fall einer dauerhaften Installation) mit gesetztem PG_GUARD_DSN in dessen Umgebungskonfiguration.

Siehe .env.example für alle unterstützten Umgebungsvariablen und scripts/setup_dev_db.sh für ein funktionierendes Beispiel, wie man eine richtig eingeschränkte Read-only-Rolle einrichtet (die Konfiguration, gegen die die eigenen Tests dieses Projekts laufen).

Tests

pip install -e ".[dev]"
pytest tests/ -v

tests/test_safety.py ist reines Python und benötigt keine Datenbank. tests/test_db.py und tests/test_server.py laufen gegen eine reale lokale PostgreSQL-Instanz – einschließlich des exakten Exploit-Payloads, der für die Deprecation des offiziellen Postgres-MCP-Servers verantwortlich war – und werden automatisch übersprungen, wenn pgguard_test nicht erreichbar ist. Führen Sie scripts/setup_dev_db.sh einmal aus, um die Datenbank zu erstellen.

Status

v0.1.0, live auf PyPI. 58 erfolgreiche Tests (Unit- und Live-Postgres-Integration, einschließlich des exakten Exploits, der zur Deprecation des offiziellen server-postgres führte, ausgeführt gegen eine frische pip install des veröffentlichten Pakets).

Lizenz

MIT