Open Source MCP Gateways: Eine evidenzbasierte Bewertungsmethode
Bewerten Sie ein Open-Source-MCP-Gateway mit reproduzierbaren Protokoll-, Isolations-, Autorisierungs-, Bypass-, Fehler- und Beweistests anstelle einer Feature-Checkliste.
Bewerten Sie ein Open-Source-MCP-Gateway, indem Sie es gegen Ihre geschützten Aktionen und Fehlerfälle ausführen Repository-Aktivitäten, unterstützte Transporte und eine lange Integrationsliste sind wichtig, aber sie zeigen nicht, ob das Gateway ein Falschaudience-Token ablehnt, Mieter isoliert, eine direkte Route blockiert oder die Genehmigung an genaue Tool-Argumente bindet.
Beginnen Sie mit dem Besitzer MCP Gateway GuideVerwenden Sie dann diese Methode, um ein Überprüfungsartefakt zu erstellen, das ein anderer Ingenieur reproduzieren kann.
Definieren Sie die Kriterien, bevor Sie Produkte auswählen
Gewichtskriterien durch die Konsequenzen der Werkzeuge hinter dem Gateway.
| Fläche | Gewicht | Erforderliche Nachweise |
|---|---|---|
| Protokollgenauigkeit | 15 | Identifizierungs-, Transport- und Fehlerbehebung |
| Identität und Token Isolation | 20 | Publikum, Emittent, Mieter und geheime Tests |
| Genehmigung von Maßnahmen | 20 | exact-argument policy und Approval mutations tests |
| Bypasswiderstand | 15 | Netz- und Upstream-Service-Identitätstest |
| Betrieb | 15 | HA, Upgrade, Rollback und Dependence Outage Drill |
| Beweise | 10 | korrelierte Entscheidungen, Aufrufe und Ergebnisse |
| Wartung | 5 | Freigabeprozess, Sicherheitspolitik und Abhängigkeitshaltung |
Geben Sie keine Teilanrechnung für eine kritische Steuerung, die nur in der Dokumentation vorhanden ist, sondern notieren Sie einen Testbefehl, eine Gateway-Version, einen Konfigurationsverdau, eine erwartete Ausgabe und eine beobachtete Ausgabe.
Verwenden Sie einen tragbaren Kabelbaumvertrag
case_id: mcp-auth-wrong-audience
given:
gateway_version: "record-exact-version"
client: tenant-a-worker
token_audience: https://mcp.example.com/server-a
when:
server: server-b
method: tools/call
tool: issue_refund
arguments: { order_id: "9182", amount_minor: 4500 }
then:
gateway_status: denied
upstream_calls: 0
reason_code: TOKEN_AUDIENCE_MISMATCH
evidence_event: required
Die MCP-Berechtigungsspezifikation HTTP-Clients müssen Metadaten und Ressourcenindikatoren für geschützte Ressourcen verwenden, und Server müssen Token validieren, die für ihre Ressource bestimmt sind.
Test jenseits des glücklichen Weges
Umfassen mindestens diese Familien:
- fehlerhafte JSON-RPC, übergroße Nachrichten und unbekannte Methoden;
- Server-Metadaten, die auf einen nicht genehmigten Autorisierungsserver verweisen;
- zwei Mandanten, die denselben Servernamen und denselben Toolnamen verwenden;
- Werkzeugbeschreibungen, die sich nach der Genehmigung ändern;
- Injizierte Identitäts-Header und Token-Durchgangsversuche;
- doppelte Anrufe bei Wiederholungen und verlorene Antworten;
- Ausfälle von Kontrollflugzeugen, Replay-Storage und Evidenzpipeline;
- Upstream-Anrufe rund um das Gateway.
OWASP Agentische Bedrohungen und Minderungsmaßnahmen liefert Bedrohungskategorien wie Missbrauch von Werkzeugen, Identitätsmissbrauch und Kompromisse bei der Lieferkette.
Punkteansprüche und Lücken separat
Eine Vergleichstabelle sollte unterscheiden verified, documented, extension required, failed und not tested"Unterstützt OAuth" ist nicht genug, notieren Sie, welchen Fluss, Entdeckungsmechanismus, Publikumsverhalten und Token-Speichermodell Sie verifiziert haben.
weighted score = sum(weight * verified_fraction)
critical gate = all mandatory cases pass
Selection requires both. A high score cannot compensate for a failed tenant-isolation gate.
Überprüfe die Lizenzbedingungen, die Release-Kadenz und die Handhabung von Schwachstellen, aber vermeide Popularität als Sicherheits-Proxy.
Die MCP Gateway Sicherheitskontrollen Artikel bietet detaillierte Vorrichtungen. MCP Gateway gegen API Gateway erklärt, wann ein bestehendes API-Gateway MCP-fähige Erweiterungen benötigt. Kontaktieren Sie Intelliger mit den geschützten Werkzeugen und dem erforderlichen Ausfallverhalten.
Diese Bewertungsmethode ist produktneutral: Jeder von einem Anbieter, einschließlich Intelliger, veröffentlichte Vergleich sollte Versionen, Gewichte, Testgrenzen und Geschäftsbeziehungen offenlegen.
Bewertungsfragen Teams vermissen
Sollten verwaltete und selbst gehostete Optionen die gleiche Rubrik verwenden?
Verwenden Sie die gleichen Kontrollergebnisse und notieren Sie dann, wer jede Abhängigkeit betreibt. Ein Managed Service muss die Isolation von Mandanten, regionale Verarbeitung, Incident Response, Export- und Löschungsnachweise offenlegen. Ein selbst gehostetes Projekt verschiebt Patching, Verfügbarkeit, Signierschlüssel und Policy-Operationen an Ihr Team. Vergeben Sie dem Self-Hosting keinen automatischen Sicherheitsvorteil oder behandeln Sie einen Managed-Control-Anspruch ohne Test als verifiziert.
Wie sollte sich die Verlängerungsarbeit auf die Punktzahl auswirken?
Markierung extension required Eine Erweiterung, die jeden Werkzeugaufruf abfängt, kann machbar sein, wird aber zu einer kritischen Sicherheitskomponente. Fügen Sie die Tests und die Release-Kadenz der Bewertung hinzu, anstatt dem zugrunde liegenden Gateway das Verhalten zuzuschreiben, das es nicht bietet.
Welche Produktversion gehört in den Bericht?
Genaue Veröffentlichung, Edition, aktivierte Plugins und Konfigurationsverdau aufzeichnen. Hosted Services können sich ändern, ohne dass eine Version für Kunden sichtbar ist, also das Testdatum und die beobachtbaren Funktionen aufzeichnen. Kritische Gates nach Upgrades erneut ausführen. Immergrüne Behauptungen wie "Gateway X unterstützt OAuth nicht" vermeiden, wenn das Ergebnis von einer älteren Edition oder Konfiguration stammt.
Kann die Dokumentation ein Kriterium erfüllen?
Die Dokumentation kann das beabsichtigte Verhalten bestimmen und einen Test leiten. documented, not verified Für operative Ansprüche wie regionales Failover oder Datenlöschung, verlangen Sie Beweise oder führen Sie eine kontrollierte Übung mit dem Verkäufer durch.
Wie vergleichen Teams Usability, ohne die Sicherheit zu schwächen?
Ein Gateway, das undurchsichtige Fehler erzeugt, fördert Umgehungen. Das Usability-Scoring sollte eine klare Wiederherstellung innerhalb der Richtlinie belohnen, nicht eine Erweiterung der Berechtigung mit einem Klick oder Geheimnisse, die in die Clientkonfiguration eingefügt wurden.
Wann sollte ein Kandidat unabhängig von der Punktzahl abgelehnt werden?
Vor dem Testen nicht verhandelbare Gates definieren. Cross-Tenant-Zugriff, Token-Passthrough zum falschen Server, eine nicht blockierte direkte Route, fehlende Autorisierung bei Tool-Aufrufen oder nicht wiederherstellbare Duplikat-Schreiben können einen Kandidaten disqualifizieren. Halten Sie diese Ergebnisse sichtbar, auch wenn die gewichtete Punktzahl aufgrund von Routing und Integrationsbreite hoch ist.
Wiederholen Sie die abschließenden Shortlist-Tests mit den Personen, die das Gateway bedienen werden. Geben Sie ihnen eine Leugnung durch ein falsches Publikum, Metadaten-Drift, einen vorgelagerten Timeout und ein vermutetes geheimes Leck. Messen Sie, ob sie den betroffenen Mandanten, Server, Tool und Request identifizieren können, ohne einen größeren Umfang zu gewähren oder Rohdaten zu prüfen. Hier kann ein technisch leistungsfähiges Projekt bei einer Unternehmensbewertung fehlschlagen: Die Steuerung funktioniert, aber ihr Zustand und ihr Wiederherstellungspfad sind zu undurchsichtig für einen unter Druck stehenden Betreiber.
Das Test-Repository veröffentlichen oder genügend Vorrichtungen für ein anderes Team, um das Ergebnis zu wiederholen. Screenshots eines Dashboards sind schwache Vergleichsbeweise. Konfiguration, Anforderung, Code des erwarteten Grundes und Upstream-Call-Anzahl sind viel schwieriger falsch zu lesen.