MCP Gateway: Architektur, Kontrollen und Auswahl
MCP Gateway für Unternehmen bewerten: Zugriffskontrollen, Anfragebindung, Anbietergrenzen und reproduzierbare Tests für Freigabe, Ablehnung und Ausfälle.
Ein MCP Gateway bündelt den Zugang zu MCP-Servern und kann Identitätsprüfung, Werkzeugzugriff, Weiterleitung und Protokollierung zentral durchsetzen. Für folgenreiche Unternehmensaktionen reicht der Zugang zu einem Werkzeug allein nicht aus. Prüfen Sie zusätzlich, ob der konkrete Aufruf mit seinem Ziel, Inhalt, Zweck und Freigabestand zulässig ist. Die richtige Auswahl hängt von diesen Kontrollen und Ihrer Betriebsumgebung ab.
Dieser Leitfaden richtet sich an Plattform- und Sicherheitsteams. Er entspricht dem Architektur- und Evaluierungszweck des englischen MCP-Gateway-Leitfadens. Die folgenden Tests verwenden einen eigenen lokalen Simulator. Sie sind weder ein Vergleich ausgeführter Anbieterinstallationen noch ein MCP-Konformitätstest.
Was ein MCP Gateway kontrollieren sollte
MCP verbindet Clients mit Werkzeugen und Kontextquellen. Ein Gateway liegt zwischen diesen Clients und den angebundenen Servern. In einer Unternehmensarchitektur kann es die gemeinsame Grenze bilden, an der jeder Aufruf geprüft wird. Dafür müssen direkte Umgehungswege, zusätzliche Schlüssel und alternative Netzwerkrouten ebenfalls betrachtet werden.
Agent oder MCP-Client
-> Gateway: Identität und vorgesehenen Empfänger prüfen
-> Werkzeug und konkrete Argumente autorisieren
-> Auftrag, Freigabe und Operationskennung prüfen
-> Freigegebenen Aufruf an MCP-Server weiterleiten
-> Ergebnis beobachten und Nachweis sichern
Die MCP-Autorisierungsspezifikation 2025-11-25 beschreibt Autorisierung für HTTP-basierte Verbindungen. Daraus folgt keine automatische Genehmigung jeder Geschäftshandlung, die ein Werkzeug auslösen kann. Ein Token für den Zugriff auf einen Server und die Erlaubnis, einen bestimmten Datensatz an ein bestimmtes Ziel zu schreiben, beantworten unterschiedliche Fragen.
| Kontrollbereich | Konkrete Frage | Nachweis im Test |
|---|---|---|
| Identität und Empfänger | Ist das Token für diesen Dienst bestimmt? | Falscher Empfänger wird vor Weiterleitung abgelehnt |
| Werkzeugzugriff | Darf diese Identität dieses Werkzeug aufrufen? | Verbotenes Werkzeug erreicht den Server nicht |
| Anfragebindung | Stimmen Ziel und Inhalt mit der Freigabe überein? | Geänderte Argumente entwerten die Freigabe |
| Wiederholung | Ist dies dieselbe Operation oder eine neue? | Gleiche Kennung führt nicht blind zur zweiten Ausführung |
| Ausfallverhalten | Was passiert bei unbekanntem Berechtigungszustand? | Folgenreiche Aktion stoppt ohne bestätigte Freigabe |
| Ergebnisnachweis | Was wurde tatsächlich beobachtet? | Entscheidung, Versand und Ergebnis bleiben unterscheidbar |
Anbieter anhand der eigenen Grenze vergleichen
Beginnen Sie mit Ihrer vorhandenen Infrastruktur. Ein Team mit etabliertem API-Gateway-Betrieb hat andere Integrationskosten als ein Team, das primär Modellzugriffe verwaltet. Prüfen Sie Edition, Version, Betriebsmodell und Lizenzumfang anhand der tatsächlich angebotenen Installation. Eine Produktübersicht belegt keine aktivierte Funktion in Ihrem Vertrag.
Kongs Rezept für einen internen MCP-Gateway nennt mindestens Gateway 3.14, verwendet Konnect und verbindet OAuth-Prüfung mit Werkzeug-ACLs. Dieses konkrete Rezept ist als nicht mit On-Prem kompatibel gekennzeichnet. Übertragen Sie diese Einschränkung weder pauschal auf sämtliche Kong-Produkte noch ignorieren Sie sie bei der Planung einer lokalen Installation.
Portkeys Autorisierungsdokumentation unterscheidet verfügbare Workspace- und Serverkontrollen von angekündigter werkzeugbezogener Autorisierung anhand von Claims. Auch Autorisierungs-Webhooks sind dort als zukünftige Funktion markiert. Werkzeuge bereitzustellen oder auszublenden ist nicht dasselbe wie jeden Aufruf mit dynamischen Benutzerattributen zu autorisieren. Lassen Sie sich die benötigte Funktion in Ihrer Edition zeigen und testen Sie sie selbst.
| Ausgangslage | Evaluierungsrichtung | Vor Entscheidung nachweisen |
|---|---|---|
| Bestehender Kong- und API-Betrieb | MCP in vorhandene Gateway-Verwaltung integrieren | Passende Topologie, Werkzeugregeln und Verhalten bei Ausfall |
| Gemeinsame Verwaltung von Modell- und MCP-Zugriffen | Portkey als Kandidaten prüfen | Unterschied zwischen Bereitstellung, Serverzugriff und dynamischer Werkzeugkontrolle |
| Bereits vorhandene Identitäts- oder Plattformdienste | Bestehende Kontrollpunkte zuerst untersuchen | Vollständigkeit der Durchsetzung und verbleibende Lücken |
| Stark eingeschränkter eigener Prozess | Kleine gezielte Integration erwägen | Wartung, Protokolländerungen, Notstopp und Betrieb dauerhaft verantworten |
Der englische Leitfaden führt weitere Kandidaten wie Cloudflare und MuleSoft auf. Diese Seite vergibt keine Rangliste und behauptet keine gemessenen Leistungsunterschiede. Nutzen Sie die Matrix zuerst für eine belastbare Anforderungsliste. Einen engeren Vergleich bietet der englische Kong-Portkey-Artikel.
Reproduzierbare Tests mit dem Kontrolllabor
Laden Sie das Kontrolllabor 1.0.0 herunter, entpacken Sie es und wechseln Sie in das entpackte Verzeichnis. Erforderlich ist Node.js 20 oder neuer. Es gibt keine zusätzlichen Pakete, keine Netzwerkaufrufe und keine echten Zugangsdaten.
node --test lab.test.mjs
node verify.mjs evidence.json demo-public-key.pem
Die Referenzkonfiguration erlaubt dem Agenten evidence-worker im Testmandanten example-lab ausschließlich das Werkzeug publish_evidence_draft. Die Zieladresse https://records.example.test/drafts ist eine Kennzeichnung im Test; sie wird nicht aufgerufen. Inhalt und Operationskennung fließen in die Anfragebindung ein. Die genehmigende Person ist eine separate vertrauenswürdige Testeingabe.
| Versuch | Erwartetes Ergebnis | Simulierte Versände |
|---|---|---|
| Genehmigter Entwurf | Akzeptiertes Ergebnis mit Referenz | Genau einer |
| Identische Wiederholung | Vorhandenes Ergebnis | Weiterhin einer |
| Geänderter Inhalt nach Freigabe | Ablehnung der Freigabe | Keiner in einem neuen Testfall |
| Fremder Mandant oder falscher Empfänger | Ablehnung | Keiner |
| Policy- oder Reservierungsspeicher ausgefallen | Ablehnung | Keiner |
| Zeitüberschreitung nach Versand | Ergebnis bleibt unklar | Einer, auch nach Wiederholung |
Die Tests sind absichtlich enger als ein produktives Gateway. Identität und Freigabe gelten als bereits vertrauenswürdig; eine OAuth-Prüfung ist nicht enthalten. Der Speicher lebt in einem einzelnen Prozess. Gleichzeitige verteilte Zugriffe, Prozessabstürze und dauerhafte Wiederherstellung müssen in Ihrer tatsächlichen Umgebung gesondert geprüft werden. Ein grüner Testlauf beweist die zugesicherten Eigenschaften des Beispiels, nicht die Sicherheit Ihrer Installation.
Tokens, Werkzeugdaten und Zugangsdaten trennen
Die offizielle MCP-Sicherheitsdokumentation untersagt das dort beschriebene Token-Passthrough-Muster. Ein Server darf nicht beliebige fremde Tokens als eigene Berechtigung akzeptieren und ungeprüft an nachgelagerte Dienste weiterreichen. Prüfen Sie die vorgesehenen Empfänger und gestalten Sie die nachgelagerte Autorisierung separat.
Wiederverwendbare Zugangsdaten gehören nicht in Modellkontext, Werkzeugbeschreibungen oder Ergebnisse. Ein Gateway kann Zugangsdaten verwalten, ist dadurch aber selbst ein besonders schützenswerter Dienst. Begrenzen Sie Betreiberrechte, ausgehende Ziele und Geheimniszugriffe. Prüfen Sie außerdem, ob Protokolle versehentlich Tokens oder vollständige vertrauliche Nutzlasten speichern.
Weitere Angriffsflächen entstehen bei Metadatenabruf, Weiterleitungen und Sitzungen. Eine Zielprüfung nur auf den ursprünglichen Hostnamen genügt nicht, wenn spätere Weiterleitungen interne Dienste erreichen. Solche Netzwerkkontrollen sind nicht Bestandteil des lokalen Kontrolllabors. Der englische MCP-Sicherheitsleitfaden ordnet diese Grenzen gesondert ein.
Wiederholung, Abgleich und sichere Fehlerbehandlung
Eine Zeitüberschreitung nach Versand bedeutet, dass das Ergebnis unbekannt sein kann. Sie beweist weder Erfolg noch Misserfolg. Bewahren Sie Operationskennung, Anfragebindung und Versandstatus auf. Fragen Sie den Zielzustand über einen vorgesehenen Abgleichweg ab, bevor Sie eine erneute Ausführung erlauben.
Unterscheiden Sie dabei einen identischen Wiederholungsversuch von einer neuen Handlung. Ändert sich der Inhalt bei gleichbleibender Operationskennung, sollte ein Konflikt entstehen. Ändert sich der Auftrag bewusst, sind eine neue Kennung, eine neue Bewertung und gegebenenfalls eine neue menschliche Freigabe erforderlich. Eine zufällig neu erzeugte Kennung bei jedem Netzwerkfehler würde diesen Schutz aushebeln.
Definieren Sie vorab, wer einen unklaren Vorgang übernimmt und wann eskaliert wird. Bei einer Zahlungsanweisung kann die Behandlung anders aussehen als bei einem Entwurf. Legen Sie keine allgemeine automatische Wiederholung für alle MCP-Werkzeuge fest. Ihre Wirkung hängt von der Semantik des jeweiligen Zielsystems ab.
Abnahme, Governance und aktueller Stand
Verlangen Sie im Abnahmetest sichtbare Nachweise auf beiden Seiten des Gateways. Eine Fehlermeldung an den Client ist unzureichend, wenn der Aufruf trotzdem beim Zielsystem ankommt. Prüfen Sie Sperren, neue Werkzeugversionen, geänderte Parameter, abgelaufene Freigaben und Ausfälle der Kontrollinfrastruktur. Dokumentieren Sie offene Funktionen als offene Funktionen und ordnen Sie jede Lücke einer verantwortlichen Rolle zu.
Intelliger beschreibt Agent Trust und den Enterprise Agent Gateway als Kontrollarchitektur für folgenreiche Aktionen. OATI ist ein Developer Preview; die lokalen Beispiele dieser Seite sind keine unabhängig geprüfte Produktionsfreigabe. Die Governance-Checkliste hilft, technische Kontrollen mit Zuständigkeiten zu verbinden. Der Unternehmensleitfaden setzt sie in einen begrenzten Prozess ein.
Beginnen Sie mit dem Kontrolllabor und übertragen Sie die erwarteten Ergebnisse anschließend in Ihre eigene Testumgebung. Weitere Themen finden Sie in der Leitfadenübersicht; die Agent-Trust-Seite erläutert Intelligers Ansatz.