sovereign-mcp-gateway

Ein vorgeschalteter Proxy für Model Context Protocol-Server. Richten Sie Ihren MCP-Client auf das Gateway aus, statt auf Ihre Server. Es verbindet sich mit jedem von Ihnen aufgeführten Upstream, führt deren Tool-Kataloge zu einem zusammen und leitet jeden Aufruf durch eine Verifikationskette, bevor er den Server erreicht, der ihn ausführen würde.

pip install sovereign-mcp-gateway
sovereign-mcp-gateway --init          # writes gateway.json from the servers you already run
sovereign-mcp-gateway --config gateway.json --check

--init liest die MCP-Konfiguration, die Sie bereits haben (Claude Desktop, Claude Code, Cursor, VS Code oder Windsurf) und schreibt eine gateway.json, die genau diese Server proxyt, sodass der erste Lauf eine funktionierende Konfiguration erzeugt statt eines Konfigurationsfehlers. Der eigene Eintrag des Gateways wird nicht importiert, weil es sich sonst selbst proxyn würde.

Das Gateway ist selbst ein MCP-Server, sodass jeder Client, der MCP spricht, ohne Änderungen funktioniert.

Diese Basisinstallation ist ein funktionierendes Gateway. Vier optionale Extras fügen weitere Ebenen hinzu – siehe Installieren.

Was es verhindert

Ein Agent liest ein GitHub-Issue, dessen Text eine Anweisung enthält, die an das Modell gerichtet ist statt an Sie. Er lässt sich überzeugen und ruft git_commit auf.

Gleiches Tool, gleiche Argumente, gleicher Server. Der Unterschied ist, ob etwas in der Lage war, sich zu verweigern.

Lesen Sie den Walkthrough: Ihr Agent liest ein Issue – oder führen Sie ihn aus:

pip install "sovereign-mcp-gateway[all]" mcp-server-git
python examples/poisoned_issue.py

Related MCP server: Agentrim MCP

Warum ein Proxy und keine Bibliothek

Eine Bibliothek muss von demjenigen übernommen werden, der den Server geschrieben hat. Ein Proxy schützt Server, die Sie nicht ändern können – und das sind die meisten, denn die nützlichen MCP-Server sind veröffentlichte Pakete, die jemand anderes pflegt.

Außerdem haben Sie so einen einzigen Ort für Richtlinien und eine einzige Audit-Spur über alle Server hinweg, die ein Agent erreichen kann – statt einer Pro-Server-Konfiguration, die niemand synchron hält.

Konfigurieren

Beginnen Sie mit dem, was Sie bereits ausführen

$ sovereign-mcp-gateway --init

Wrote gateway.json

  imported 3 servers from Claude Desktop
    /Users/you/Library/Application Support/Claude/claude_desktop_config.json
  imported 1 server from VS Code (project)

  upstreams: fetch, git, sqlite, time

  skipped:
    sovereign - this gateway - importing it would proxy itself
    notion    - no command, probably a remote/SSE server
    git       - already imported from another client

Vier Dinge tut es nicht: sich selbst importieren, einen entfernten Server importieren, den es nicht als Unterprozess starten kann, eine vorhandene Datei ohne --force überschreiben oder eine deny_tools-Liste schreiben, die Sie nicht gewählt haben. Es schreibt die Datei, teilt Ihnen mit, was es übernommen und was es ausgelassen hat, und stoppt.

Geben Sie --config PATH zusammen mit --init an, um woanders als nach ./gateway.json zu schreiben.

Ersetzen Sie nach dem Ausführen diese Server in Ihrem Client durch einen einzigen Eintrag für das Gateway. Wenn beides bleibt, spricht Ihr Agent sowohl direkt mit ihnen als auch über den Proxy, und die Audit-Spur zeigt nur die Hälfte des Datenverkehrs.

{
  "servers": {
    "git":    {"command": "mcp-server-git",    "args": ["--repository", "/repo"]},
    "sqlite": {"command": "mcp-server-sqlite", "args": ["--db-path", "/data.db"]}
  },
  "policy": {"deny_tools": ["git__git_reset"], "pii_policy": "warn"},
  "audit":  {"path": "gateway-audit.jsonl"}
}

Prüfen Sie die Verkabelung, bevor ein Client sie je zu sehen bekommt:

sovereign-mcp-gateway --config gateway.json --check

SOVEREIGN GATEWAY - configuration check
upstreams: 2
layers:   policy -> intent -> text-filter -> frozen-verify -> audit

EXPOSED AS                             UPSTREAM TOOL
git__git_status                        git.git_status
git__git_reset                         git.git_reset          [DENIED]
sqlite__read_query                     sqlite.read_query
...
18 tools exposed.

Die Kette

policy → intent → text-filter → frozen-verify → [ call executes ] → output-verify → logic-rules → audit

Installieren

Die Basisinstallation ist ein funktionierendes Gateway, kein Stub:

pip install sovereign-mcp-gateway

Das ergibt policy → frozen-verify → audit, was bereits ein Tool verweigert, das kein Upstream bereitstellt, ein Argument mit falschem Typ, einen nicht deklarierten Parameter, ein Tool auf Ihrer Deny-Liste und Prompt-Injektion in einem Argument. Sonst ist nichts nötig.

Jedes Extra fügt eine Ebene hinzu:

Kombinieren Sie, was Sie wollen, oder nehmen Sie alles:

pip install "sovereign-mcp-gateway[text]"             # one extra
pip install "sovereign-mcp-gateway[text,intent]"      # several
pip install "sovereign-mcp-gateway[all]"              # every layer

Alle vier Extras sind kleine reine Python-Pakete – [all] fügt keine kompilierten Abhängigkeiten und keinen Dienst hinzu, der ausgeführt werden muss.

Eine Teilinstallation verschlechtert sich sichtbar. Das Gateway gibt seine aktiven Ebenen beim Start aus, sodass Sie immer sehen können, was tatsächlich läuft:

layers:   policy -> frozen-verify -> audit                                  # base
layers:   policy -> intent -> text-filter -> frozen-verify -> audit         # [all]

Wenn eine Ebene nicht in dieser Zeile steht, läuft sie nicht – egal, was Sie glauben installiert zu haben.

Ende-zu-Ende verifiziert

Gegen mcp-server-git und mcp-server-sqlite, die als echte Upstreams laufen, gesteuert von einem echten MCP-Client:

Danach enthält das Repository immer noch genau einen Commit und die Datenbank genau die Zeile, die sie enthalten sollte – geprüft durch direktes Öffnen, nicht durch Vertrauen auf den eigenen Bericht des Gateways. Elf Audit-Datensätze für zehn Aufrufe; das Ändern eines einzigen bricht die Kette.

Diese Fälle sind die Testsuite, kein Screenshot: pytest tests/ -v.

Ebene C: N-Modell-Konsens

Jede andere Ebene ist deterministisch und lokal. Ebene C ist die Ausnahme: Sie fragt mehrere unabhängige Modelle, dasselbe strukturierte Dokument aus dem Ergebnis eines Tools zu extrahieren, kanonisiert jede Antwort und vergleicht die SHA-256-Hashes. Übereinstimmung wird per Hash entschieden, nicht per Prosa.

Sie ist standardmäßig aus, weil sie die einzige Ebene ist, die pro Aufruf Geld und Latenz kostet, und die einzige, die Tool-Ausgaben an ein Modell sendet.

{
  "servers": { "...": {} },
  "consensus": {
    "providers": [
      {"type": "local", "model": "llama3.1:8b"},
      {"type": "local", "model": "qwen2.5:7b", "base_url": "http://localhost:11434/v1"},
      {"type": "openrouter", "model": "anthropic/claude-3.5-sonnet",
       "api_key_env": "OPENROUTER_API_KEY"}
    ]
  }
}

Zwei Providertypen: local (jeder OpenAI-kompatible Endpunkt – Ollama, vLLM, LM Studio; base_url standardmäßig http://localhost:11434/v1) und openrouter (der Schlüssel wird aus der benannten Umgebungsvariable gelesen, nie in die Konfiguration geschrieben).

Drei Regeln, die das Gateway beim Start durchsetzt, statt sie zur Laufzeit zu entdecken:

• Mindestens zwei Provider. Ein Modell kann nicht mit sich selbst uneins sein; ein Konsens aus einem meldet bei jedem Aufruf Übereinstimmung, was schlimmer ist als keine Ebene, weil es wie Verifikation aussieht.

• Keine doppelten Modelle. Zwei Instanzen desselben Modells, die übereinstimmen, sind keine unabhängige Verifikation.

• Ein fehlender API-Schlüssel verweigert den Start. Es fällt nicht auf einen Lauf ohne die Ebene zurück.

Alle Provider laufen mit temperature = 0, im Konstruktor erzwungen.

Prüfen Sie, dass Ihre Modelle übereinstimmen, bevor Sie der Ebene vertrauen

--check führt einen echten Konsens-Aufruf gegen Ihre konfigurierten Modelle aus und teilt Ihnen mit, was passiert ist. Das ist wichtiger, als es klingt:

LAYER C  - probing the configured models with one real call
--------------------------------------------------------------
  OK. The configured models produced identical documents.
  Layer C will pass ordinary output rather than refusing it.

Konsens vergleicht kanonische Hashes, sodass zwei Modelle, die beide semantisch richtig, aber strukturell unterschiedlich sind, nie übereinstimmen. Ein schwächeres Modell, das das Schema zurückspiegelt –

{"branch": {"type": "string", "value": "main"}}   instead of   {"branch": "main"}

– weicht bei jedem Aufruf ab, für immer, und das Gateway verweigert alles mit einer Begründung, die korrekt lautet „die Modelle waren uneins". Denn das waren sie.

Die Sonde unterscheidet die drei Ergebnisse:

Installieren Sie sovereign-mcp-gateway[consensus] oder [all] – die HTTP-Provider benötigen requests, von dem die Kernbibliothek bewusst nicht abhängt.

--check listet auch die aktiven Ebenen auf, sodass Sie es auf einen Blick bestätigen können:

layers:   policy -> intent -> text-filter -> frozen-verify -> consensus -> audit

Wenn consensus in dieser Zeile fehlt, läuft es nicht, egal was die Konfiguration sagt.

Namensräume

Mit aktiviertem namespace (Standard) wird ein Tool als git__git_status bereitgestellt. Zwei Upstreams, die denselben Tool-Namen anbieten, können nicht kollidieren, sich nicht gegenseitig überschatten und nicht über den falschen Namensraum erreicht werden. Schalten Sie es nur aus, wenn Sie einen einzigen Upstream haben.

Richtlinie

"policy": {
  "deny_tools":  ["git__git_reset", "write_query"],
  "allow_tools": null,
  "pii_policy":  "warn",
  "fail_closed": true,
  "rate_limit_interval": 0
}

• deny_tools passt entweder auf den exponierten Namen (git__git_reset) oder den Upstream-Toolnamen (git_reset, auf jedem Upstream, der ihn hat).

• allow_tools verweigert, wenn gesetzt, alles, was nicht aufgeführt ist.

• pii_policy ist standardmäßig auf warn gesetzt, nicht auf block. Echte Tools geben personenbezogene Daten als normale Ausgabe zurück – jeder git log-Eintrag enthält eine Autoren-E-Mail – und das Blockieren dieser Daten macht das Gateway unbrauchbar. Setzen Sie block, wenn Ihre Tools niemals PII ausgeben sollen.

• fail_closed entscheidet, was passiert, wenn eine Ebene selbst einen Fehler verursacht. Standard: verweigern.

• rate_limit_interval ist 0, was die eigene Interaktionsverzögerung der Verhaltensuntergrenze deaktiviert. Diese Verzögerung ist richtig für einen Agenten, der bewusste Schritte unternimmt, und falsch für einen Proxy, wo ein Schwall von Tool-Aufrufen normaler Verkehr ist.

• entropy_policy ist standardmäßig auf warn gesetzt. Die Entropie-Heuristik des Textfilters sucht nach kodierten Nutzlasten, die in Prosa versteckt sind, aber Tool-Argumente sind routinemäßig strukturiert – Pfade, Bezeichner, Hashes – wo hohe Entropie normal ist. Ein temporärer Verzeichnispfad allein reichte aus, um einen legitimen Aufruf abzulehnen. Setzen Sie block, wenn Ihre Argumente wirklich Prosa sind.

Was dies nicht tut

Es überprüft Aufrufe gegen eingefrorene Definitionen und inspiziert Argumente und Ergebnisse. Es liest nicht den Quellcode Ihrer Server, daher kann es keine Prüfung erkennen, die vorhanden ist, aufgerufen wird und stillschweigend nichts tut. Dafür ist immer noch jemand nötig, der die Implementierung liest.

Es kann auch nicht vor einem kompromittierten Upstream schützen, der korrekt aussehende Daten zurückgibt – der Layer-C-Konsens in sovereign-mcp befasst sich damit und erfordert Modellanbieter, die Sie selbst konfigurieren.

Lizenz

Business Source License 1.1 – siehe LICENSE.

Der Quellcode ist öffentlich. Sie dürfen ihn lesen, modifizieren, abgeleitete Werke erstellen und ihn kostenlos für Entwicklung, Evaluierung und jeden anderen Nicht-Produktionszweck verwenden.

Die Produktionsnutzung ist ebenfalls kostenlos für eine Einzelperson oder eine Organisation mit vier oder weniger Personen – das ist in der Lizenz als Additional Use Grant festgeschrieben, nicht nur hier erwähnt. Größere Organisationen benötigen eine kommerzielle Lizenz.

Jede Version wird an ihrem Change Date, vier Jahre nach Veröffentlichung, zu Apache 2.0.

Um es für die Produktion zu lizenzieren oder zu fragen, ob Ihre Nutzung eine benötigt: contact@sovereign-shield.net