sovereign-mcp-gateway

Ein Gateway-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 --config gateway.json

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 Installation.

Was es verhindert

Ein Agent liest ein GitHub-Issue, dessen Text eine Anweisung enthält, die an das Modell gerichtet ist und nicht 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, abzulehnen.

Lesen Sie die Schritt-für-Schritt-Anleitung: Ihr Agent liest ein Issue – oder führen Sie sie aus:

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

Related MCP server: Mavryn

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 zentralen Ort für Richtlinien und eine einzige Audit-Spur über alle Server, die ein Agent erreichen kann, statt einer Pro-Server-Konfiguration, die niemand synchron hält.

Konfiguration

{
  "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 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

Installation

Die Basisinstallation ist ein funktionierendes Gateway, kein Stub:

pip install sovereign-mcp-gateway

Das ergibt policy → frozen-verify → audit, was bereits ein Tool ablehnt, 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 möchten, 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 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 zu installieren glauben.

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 einen Commit und die Datenbank genau die Zeile, die sie enthalten soll – geprüft durch direktes Öffnen, nicht durch Vertrauen auf den eigenen Bericht des Gateways. Elf Audit-Datensätze für zehn Aufrufe; das Bearbeiten 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 einem Tool-Ergebnis zu extrahieren, kanonisiert jede Antwort und vergleicht die SHA-256-Hashes. Übereinstimmung wird per Hash entschieden, nicht per Prosa.

Sie ist standardmäßig deaktiviert, 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 Provider-Typen: 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 der 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 zurück auf den Betrieb ohne die Ebene.

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 sagt Ihnen, 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ückwirft –

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

– passt bei jedem Aufruf nicht, für immer, und das Gateway lehnt alles ab, mit einem Grund, der korrekt „die Modelle waren uneins" lautet. Weil sie es waren.

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 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 namespace (Standard) wird ein Tool als git__git_status bereitgestellt. Zwei Upstreams, die denselben Tool-Namen anbieten, können nicht kollidieren, sich gegenseitig überschatten oder ü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 matcht entweder den bereitgestellten Namen (git__git_reset) oder den Upstream-Tool-Namen (git_reset, auf jedem Upstream, der ihn hat).

• allow_tools, wenn gesetzt, lehnt alles ab, was nicht aufgelistet ist.

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

• fail_closed entscheidet, was passiert, wenn eine Ebene selbst einen Fehler hat. Standard: ablehnen.

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

• entropy_policy standardmäßig warn. Die Entropie-Heuristik des Textfilters sucht nach kodierten Payloads, die in Prosa versteckt sind, aber Tool-Argumente sind routinemäßig strukturiert – Pfade, Identifikatoren, 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 verifiziert Aufrufe gegen eingefrorene Definitionen und prüft Argumente und Ergebnisse. Es liest nicht den Quellcode Ihrer Server, sodass es keine Prüfung sehen kann, die vorhanden ist, aufgerufen wird und stillschweigend nichts tut. Dafür braucht es immer noch jemanden, der die Implementierung liest.

Es kann auch nicht vor einem kompromittierten Upstream schützen, der korrekt aussehende Daten zurückgibt — Layer C consensus in sovereign-mcp geht darauf ein 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 für Entwicklung, Evaluierung und jeden anderen Nicht-Produktionszweck kostenlos 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 festgelegt, 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 konvertiert.

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