OWASP MCP Top 10: Was ein Gateway löst — und was nicht

18.08.2026

Axel Dunkel

Ein Gateway beseitigt einen Teil der OWASP-MCP-Top-10-Angriffswege bauartbedingt, legt andere hinter einen Schalter, den Sie erst umlegen müssen — und eine Kategorie erreicht es gar nicht. Das ist die ehrliche Kurzfassung; dieser Beitrag ist die lange: jede der zehn Kategorien, was eine Control Plane vor Ihrem MCP-Bestand tatsächlich dagegen ausrichtet und wo der Mechanismus endet. Referenzimplementierung ist durchgehend ToolMesh, unser Apache-2.0-lizenziertes, selbst gehostetes MCP-Gateway — jede Aussage unten ist also gegen lesbaren Code prüfbar.

Drei Dinge finden Sie hier, die eine Zusammenfassung der Liste nicht liefert: die gemessenen Expositionszahlen, auf die die Liste antwortet, eine Tabelle mit einem Urteil je Kategorie und einen Abschnitt, der die Kategorien benennt, die ein Gateway offen lässt — verankert in fremder Analyse, nicht in eigenem Marketing.

Die Zahlen, die diese Liste dringlich gemacht haben

Die Top 10 sind nicht im luftleeren Raum entstanden — und sie sind älter als die Schlagzeilen dieses Sommers: Die Liste war da, bevor die Messung kam, die sie dringlich gemacht hat. Im Juli 2026 veröffentlichte Nicolás Padilla Exposed by Design: A Dynamic Security Assessment of Internet-Facing MCP Servers at Scale (arXiv:2608.00150, v1 eingereicht am 31. Juli 2026) — die erste dynamische Verhaltensanalyse von MCP-Servern, die aus dem öffentlichen Internet erreichbar sind. Die Befunde, entnommen dem Abstract des Papers:

über 21.000 MCP-Server-Instanzen im öffentlichen Internet nachweisbar
640 Produktionsserver bestätigt, davon 414 dynamisch auditiert
91,8 % der dynamisch auditierten Server ohne OAuth-Authentifizierung
687 Tool-Instanzen über die bestätigten Server hinweg bieten Shell-Ausführung ohne Zugriffskontrolle
41,6 % der bestätigten Server verschwinden binnen drei Tagen zwischen zwei Messläufen

Die letzte Zahl ist die, bei der Betreiber verweilen sollten. Sie beschreibt einen Bestand, der schneller ausgerollt wird, als er geprüft werden kann. Forkast hat die Gesamtlage am 11. August 2026 zusammengefasst und zählt für denselben Zeitraum mehr als zehn kritische oder hochgestufte CVEs im MCP-Ökosystem. Ein Detail für den Vergleich mit anderen Darstellungen: Die 91,8 % beziehen sich auf die 414 dynamisch auditierten Server, und die 687 Shell-fähigen Instanzen sind Tools, keine Server — mehrere Sekundärberichte runden beides auf die 640-Server-Zahl.

Die behördliche Leitlinie kam früher. Am 20. Mai 2026 veröffentlichte das Artificial Intelligence Security Center (AISC) der NSA das Cybersecurity Information Sheet Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation. Wichtiger als jede Einzelempfehlung ist dessen Rahmung: Neben Serialisierungsrisiken und Vertrauensgrenzen benennt das CSI dynamische Tool-Aufrufe, implizite Vertrauensbeziehungen und Context Sharing als Risiken, denen etablierte Cyber-Defence-Strategien nicht angemessen begegnen — und argumentiert, dass sich diese nicht auf Schnittstellen- oder Endpunktebene patchen lassen.

Das ist eine strukturelle Aussage, und sie ist der Grund, warum eine Absicherung je Server nicht skaliert. Einundzwanzigtausend einzeln gehärtete Server sind kein Plan.

Was die OWASP MCP Top 10 tatsächlich sind

Zur ehrlichen Verwendung gehört Präzision über den Status des Artefakts. Die OWASP Top 10 for Model Context Protocol sind ein Incubator-Projekt, aktuell in Version v0.1, und die eigene Roadmap verortet sie in Phase 3 — Beta Release and Pilot Testing; das nächste Release ist für Oktober 2026 angekündigt (Projektseite, geprüft am 18. August 2026). Das Dokument steht unter CC BY-NC-SA 4.0.

Also: kein Zertifizierungsziel, keine Compliance-Baseline — und die IDs tragen weiterhin das Suffix :2025. Was die Liste ist: ein gemeinsames Vokabular für MCP-Risiken, und genau das hat der Kategorie gefehlt. Nutzen Sie sie als Checkliste für Design-Reviews, nicht als Prüfstandard — und rechnen Sie damit, dass sich die Kategorien im Oktober bewegen.

Die zehn Kategorien, wie sie die Übersichtsliste der Projektseite führt (Originaltitel auf Englisch):

ID	Kategorie
MCP01:2025	Token Mismanagement & Secret Exposure
MCP02:2025	Privilege Escalation via Scope Creep
MCP03:2025	Tool Poisoning
MCP04:2025	Software Supply Chain Attacks & Dependency Tampering
MCP05:2025	Command Injection & Execution
MCP06:2025	Intent Flow Subversion
MCP07:2025	Insufficient Authentication & Authorization
MCP08:2025	Lack of Audit and Telemetry
MCP09:2025	Shadow MCP Servers
MCP10:2025	Context Injection & Over-Sharing

Ein Vorbehalt zu dieser Tabelle — und zugleich der schärfste verfügbare Beleg für den oben genannten Beta-Status: Die Projektseite ist sich selbst nicht einig. Die Übersichtsliste führt MCP06 als Intent Flow Subversion. Eine zweite, ausführlichere Auflistung weiter unten auf derselben Seite betitelt denselben Eintrag als Prompt Injection via Contextual Payloads — und dort verlieren die IDs ihre führende Null (MCP1:2025, MCP4:2025, MCP5:2025, MCP6:2025, MCP8:2025), während MCP03 und MCP07 sie behalten. Beide Lesarten standen am 18. August 2026 gleichzeitig auf der Seite. Wir verwenden durchgehend die Übersichtsliste. Wenn Sie OWASP MCP06 anderswo zitieren, sagen Sie dazu, welchen der beiden Titel Sie meinen — sie beschreiben spürbar Verschiedenes: einmal gekaperte Absicht, einmal Prompt Injection als Injektionsklasse.

Die Zuordnung im Überblick

ToolMesh führt jeden Tool-Call durch eine Pipeline. Der Quellcode-Kommentar nennt die Reihenfolge unmissverständlich: AuthZ → Credentials → Gate pre → Backend → Gate post → Audit (internal/executor/executor.go). Die folgende Zuordnung hält diese Pipeline gegen die zehn Kategorien, mit einem Urteil je Zeile.

OWASP-Kategorie	Mechanismus	Urteil
MCP01 Token Mismanagement & Secret Exposure	Credentials werden serverseitig pro Request injiziert; nie in Client-Config oder Modellkontext	Client-/Modell-Exposure geschlossen; Credential-Lifecycle offen
MCP02 Privilege Escalation via Scope Creep	OpenFGA-Beziehungsprüfung je Call; Discovery über dieselbe Prüfung gefiltert	Greift bei Konfiguration
MCP03 Tool Poisoning	REST-Tool-Definitionen stammen aus betreibereigenem YAML, nicht vom Upstream-Server	Geschlossen für DADL-Backends, offen für aggregierte MCP-Server
MCP04 Supply Chain Attacks & Dependency Tampering	Ein Backend sind ~30 Zeilen YAML statt eines Pakets; strikter Parser weist unbekannte Felder ab	Verringert, nicht beseitigt
MCP05 Command Injection & Execution	Tools sind deklarierte HTTP-Calls mit typisierten Parametern; keine Shell, sofern Sie keine hinzufügen	Shell-Injection auf Tool-Ebene geschlossen; Backend-Injection bleibt
MCP06 Intent Flow Subversion	Nur Begrenzung des Schadensradius: Autorisierungsdecke, Output-Policies, Audit-Trail	Nicht geschlossen
MCP07 Insufficient Authentication & Authorization	OAuth-2.1-Issuer, PKCE verpflichtend, ausschließlich S256; bcrypt-API-Keys	Authentifizierung geschlossen; Autorisierung nur bei aktiviertem Enforcement
MCP08 Lack of Audit and Telemetry	Strukturierter Audit-Eintrag auf jedem Ausgangspfad, Ablehnungen eingeschlossen	Überall protokolliert; nicht unveränderlich, und der Schreibvorgang selbst ist fail-open
MCP09 Shadow MCP Servers	Ein Endpunkt, ein dateideklarierter Katalog — Inventar per Konstruktion	Konsolidiert, nicht verhindert
MCP10 Context Injection & Over-Sharing	goja-Policy-Engine vor und nach der Ausführung; Code Mode projiziert Ergebnisse	Greift bei Konfiguration

Die zehn Kategorien im Einzelnen

MCP01:2025 — Token Mismanagement & Secret Exposure

Der Fehlermodus ist ein Backend-API-Key in einer Client-Konfigurationsdatei — oder schlimmer: einer, der auf dem Weg zum Tool durch den Modellkontext läuft. Bei ToolMesh erreichen Backend-Credentials den Client nie. Sie werden in ExecuteTool() in Schritt 2 der Pipeline aufgelöst und vom Adapter an den ausgehenden Request geheftet — der Agent fragt nach netbox_list_devices, nicht nach einem Token. Wer einen Key sperrt, fasst das Gateway an, nicht dreißig Client-Konfigurationen.

Ehrliche Reichweite — und sie ist weiter, als sie zunächst wirkt. Ausgeliefert wird der eingebettete Credential Store, der CREDENTIAL_*-Umgebungsvariablen liest; Vault-, OpenBao- und Infisical-Adapter sind als Stufenpfad dokumentiert, das Open-Source-Binary liefert heute jedoch den eingebetteten Store, und die Auflösung per Benutzer ist ein beschlossenes Design-ADR statt laufender Code. Wichtiger noch: OWASPs eigener Zuschnitt von MCP01 geht über Exposure hinaus — die Beschreibung nennt long-lived Tokens ausdrücklich und bezeichnet kurzlebige, eng gescopte Credentials als essenziell. Das OWASP MCP Security Cheat Sheet wird noch deutlicher: keine Secrets in Servercode, Configs oder Umgebungsvariablen, und ephemere Tokens statt langlebiger. Daran gemessen schließt ToolMesh den Weg vom Credential zum Modell und lässt den Credential-Lifecycle, wie er ihn vorgefunden hat.

MCP02:2025 — Privilege Escalation via Scope Creep

Die Autorisierung läuft als Erstes in der Pipeline, je Call und je Benutzer, gegen ein OpenFGA-Beziehungsmodell in der Struktur User → Plan → Tool. Das wissenswerte Detail: Dieselbe Prüfung filtert die Tool-Discovery — wer ein Tool nicht aufrufen darf, sieht es auch nicht im Listing. Scope-to-Filter-Injection geht einen Schritt weiter und verengt Backend-Query-Parameter anhand des Scopes des Aufrufers; die Autorisierung formt den Request also, statt ihn nur zuzulassen.

Ehrliche Reichweite: ToolMesh wird mit OPENFGA_MODE=bypass als Voreinstellung ausgeliefert — also gänzlich ohne Autorisierungsprüfung. Enforcement ist eine Einstellung (restrict) plus ein Beziehungsmodell, das Sie schreiben müssen; ein auf Bequemlichkeit konfiguriertes Gateway erzwingt gar nichts. Das Modell ist unter Autorisierung dokumentiert.

MCP03:2025 — Tool Poisoning

Die Rug-Pull-Variante dieses Angriffs funktioniert, weil ein MCP-Client Tool-Definitionen erneut vom Server liest — eine im Review freigegebene Beschreibung kann sich also nachträglich ändern. Für Backends, die in DADL deklariert sind, existiert dieser Kanal nicht: RESTAdapter.ListTools liest die geparste YAML-Datei, die der Betreiber hält — die Methode nimmt keinen Context entgegen und stellt keine Upstream-Anfrage. Der Katalog ändert sich, wenn jemand eine Datei in Ihrem Repository ändert: ein prüfbares Ereignis mit Autor.

Ehrliche Reichweite: Das gilt für DADL-deklarierte REST-Backends. Wo ToolMesh einen echten Upstream-MCP-Server aggregiert, fragt MCPAdapter.ListTools diesen Server sehr wohl ab — jene Definitionen sind exakt so vertrauenswürdig wie ihre Quelle. Und in keinem der beiden Fälle prüft das Gateway eine Beschreibung semantisch auf versteckte Anweisungen: Pinning ist keine Erkennung.

MCP04:2025 — Software Supply Chain Attacks & Dependency Tampering

Jeder zusätzliche MCP-Server ist üblicherweise ein Paket, eine Laufzeitumgebung und ein transitiver Abhängigkeitsbaum. Genau dieses Kostenmodell ist der Ausgangspunkt unseres eigenen Preprints DADL: A Declarative Description Language for Enterprise Tool Libraries in LLM Agent Systems (arXiv:2605.05247, 4. Mai 2026): Im organisatorischen Maßstab wird jede API-Integration als eigener Serverprozess mit eigenem Deployment, eigenem Abhängigkeitsbaum und eigenem Credential-Handling ausgeliefert — während sich die überwiegende Mehrheit dieser Server als dünne Wrapper um REST-APIs erweist. Mit DADL heißt „eine API hinzufügen“: eine YAML-Datei hinzufügen — es gelangt kein Fremdcode in die Laufzeit. Der Parser ist ausdrücklich darin, was er nicht versteht — eine schwächere und nützlichere Eigenschaft als Strenge: Ein unbekannter Schlüssel wird strikt nachdekodiert, als Warnung gemeldet und dann ignoriert. Das ist die Warn-and-ignore-Regel der DADL-Spezifikation, damit eine Datei mit neueren additiven Feldern weiterhin lädt — sichtbar eingeschränkt statt stillschweigend. Zwei Dinge schlagen sehr wohl fail-closed fehl: Ein requires-Block, der eine in diesem Build fehlende Fähigkeit nennt, verweigert das Laden ganz, und ein verhaltensbestimmender Wert, den diese Version nicht implementiert — ein Pagination-Verhalten, eine Stream-Behandlung —, wird abgewiesen statt geraten.

Ehrliche Reichweite: Das verschiebt die Lieferkette, es beseitigt sie nicht. Das Gateway-Binary hat einen eigenen Go-Abhängigkeitsbaum, und eine bösartige DADL-Datei bleibt ein Config-Supply-Chain-Problem — die Milderung besteht darin, dass es prüfbares YAML in Git ist statt minifizierter Code in node_modules.

MCP05:2025 — Command Injection & Execution

Gegen die 687 Tool-Instanzen mit unbeschränkter Shell-Ausführung aus dem Paper gehalten, ist dies der strukturellste Unterschied der Liste. Ein DADL-Tool ist ein deklarierter HTTP-Call: Methode, Pfad und ein typisiertes Parameter-Schema. Es gibt keine Shell, in die injiziert werden könnte, weil es keine Shell gibt — eine entsteht nur, wenn ein Betreiber bewusst ein Backend hinzufügt, das eine bereitstellt. Die Validierung ausgehender URLs schlägt bei DNS-Auflösungsfehlern fail-closed fehl und behandelt nicht auflösbare Adressen als privat — das ist genau der SSRF-Pfad auf Cloud-Metadatendienste, den dasselbe Paper in freier Wildbahn berichtet.

Ehrliche Reichweite: OWASPs Kategorie ist breiter als Shells. Ihre Beschreibung erfasst einen Agenten, der Systembefehle, Shell-Skripte, API-Calls oder Code-Schnipsel aus nicht vertrauenswürdigem Input ohne Validierung konstruiert und ausführt — und API-Calls zu konstruieren ist genau das Tagesgeschäft von DADL. Ein typisierter String-Parameter verhindert, dass die Tool-Ebene zum Interpreter wird; er verhindert nicht, dass das Backend am anderen Ende denselben String in sein eigenes SQL oder seine eigene Shell reicht. Wenn die Backend-API selbst einen Endpunkt zur Kommandoausführung anbietet, wird DADL ihn getreu exponieren. Deklarative Anbindung beschränkt den Transportweg, nicht die API, auf die Sie ihn richten — und die Input-Validierung gegen die Semantik des Backends bleibt Ihre Aufgabe, spätestens im Gate. Auch die Unterscheidung aus MCP03 gilt hier unverändert: Aggregiert ToolMesh einen Upstream-MCP-Server, der ein Shell-Tool mitbringt, reicht das Gateway dieses Tool durch — Autorisierung und Gates gelten dort wie überall, aber „keine Shell“ ist eine Eigenschaft der DADL-Ebene, kein Filter, den das Gateway fremden Katalogen aufzwingt.

MCP06:2025 — Intent Flow Subversion

Das ist die Kategorie, die ein Gateway nicht schließt — und etwas anderes zu behaupten, würde die übrigen neun entwerten. Wenn eingeschleuster Kontext einen Agenten auf das Ziel eines Angreifers lenkt, ist der resultierende Tool-Call authentifiziert, autorisiert, schemakonform und falsch. Jede Prüfung der Pipeline greift, denn jede Prüfung beantwortet, ob dieser Aufrufer dies tun darf — nicht, warum er fragt.

Was die Pipeline beisteuert, sind eine Decke und ein Protokoll: Die Autorisierung begrenzt, was ein unterwanderter Agent überhaupt erreichen kann, Output-Policies können bestimmte Exfiltrationsmuster blockieren, und das Audit-Log macht die Trajektorie im Nachhinein rekonstruierbar. Semantische Autorisierung — ein LLM-Supervisor, der über Absichten urteilt — existiert in unseren Konzeptnotizen und nicht im Binary. Bis dahin gilt MCP06 als nicht gemindert; planen Sie den Schadensradius entsprechend.

MCP07:2025 — Insufficient Authentication & Authorization

Gegen die 91,8 % gehalten, hat die Authentifizierungshälfte dieser Kategorie eine scharfe Antwort. ToolMesh tritt als OAuth-2.1-Issuer auf: PKCE ist verpflichtend, S256 die einzige akzeptierte Challenge-Methode, und ein Request ohne code_challenge wird am Authorization-Endpunkt abgewiesen. API-Keys und Benutzerpasswörter sind bcrypt-gehasht. Kein anonymer Aufrufer erreicht ein Tool.

Ehrliche Reichweite: Die Kategorie heißt Authentication & Authorization, und das zweite Wort landet dort, wo MCP02 es bereits liegen ließ — OPENFGA_MODE steht per Default auf bypass, jeder authentifizierte Aufrufer ist ab Werk also zugleich ein vollständig autorisierter. Zu sagen, der Autorisierungsschritt der Pipeline werde in diesem Modus „passiert“, wäre ein Wortspiel: Es fällt überhaupt keine Autorisierungsentscheidung. Streng gelesen schließt ToolMesh die Authentifizierungshälfte von MCP07 bauartbedingt und reicht Ihnen die Autorisierungshälfte als Konfigurationsaufgabe weiter. Darüber hinaus terminiert TLS vor dem Gateway (Caddy, nginx oder Cloudflare Tunnel), die Identität ist heute lokal — users.yaml und apikeys.yaml oder der eingebaute Issuer —, und OIDC-Connectoren zu Keycloak, Entra, Okta oder Zitadel stehen auf der Roadmap, sind aber nicht ausgeliefert. Die aktuelle Oberfläche ist unter Authentifizierung dokumentiert.

MCP08:2025 — Lack of Audit and Telemetry

Ein Audit-Eintrag wird auf jedem Ausgangspfad der Pipeline geschrieben, auch auf denen, die nie ein Backend erreichen: Autorisierungsfehler, Autorisierungsablehnung, Pre-Gate-Ablehnung, Backend-Fehler, Post-Gate-Ablehnung und Erfolg. Ablehnungen sind die Einträge, auf die es im Vorfall ankommt — und genau die, die selbstgebautes Logging am häufigsten auslässt. Gespeichert wird als strukturiertes slog nach stdout oder in SQLite (AUDIT_STORE), die Aufbewahrung ist konfigurierbar und liegt standardmäßig bei 90 Tagen; Prometheus-Metriken laufen daneben.

Ehrliche Reichweite, in zwei Teilen. Erstens ist das Log exakt so vertrauenswürdig wie der Host: Manipulationssicherheit — Hash-Verkettung mit externer Verankerung — ist ein ADR-Entwurf, keine Implementierung; OWASP verlangt unveränderliche Audit-Trails, das Cheat Sheet legt SIEM-Anbindung und Alerting obendrauf. Beides ist nicht in der Box. Zweitens, und weniger offensichtlich: Der Audit-Schreibvorgang ist bewusst fail-open. Der Quellkommentar sagt es wörtlich — Fehler beim Schreiben des Audit-Eintrags blockieren die Tool-Antwort nicht, weil Verfügbarkeit höher gewichtet wird als Auditierbarkeit. Die Pipeline ist also fail-closed an den Schritten, die über das Zustandekommen eines Calls entscheiden, und fail-open an dem Schritt, der ihn protokolliert. Wenn Ihre Anforderung lautet, dass niemals ein ungeloggter Call ausgeführt werden darf, erfüllt ToolMesh sie heute nicht — dafür bräuchten Sie eine externe Audit-Pipeline und Alarme auf diese Fehlereinträge.

MCP09:2025 — Shadow MCP Servers

Konsolidierung ist hier die ganze Antwort, und sie ist eine Deployment-Eigenschaft, kein cleveres Feature. Ein Endpunkt, ein Katalog, in Dateien deklariert: Unsere eigene Produktionsinstanz stellt derzeit 5.590 Tools über 60 Backends hinter einem einzigen MCP-Endpunkt bereit (geprüft am 18. August 2026). Die Frage „Worauf können unsere Agenten zugreifen?“ beantwortet ein Verzeichnislisting, kein Netzwerkscan.

Ehrliche Reichweite: Ein Gateway hindert niemanden daran, daneben einen eigenen MCP-Server zu betreiben. Schatten-Deployments zu verhindern, ist Egress-Policy, Asset-Management und organisatorische Disziplin. Was ein Gateway beseitigt, ist der Anlass, einen hochzuziehen — und es gibt Ihnen etwas, wogegen Sie einen Scan abgleichen können.

Das Output Gate ist eine goja-JavaScript-Policy-Engine, die zweimal je Call läuft: vor der Ausführung auf dem Request, danach auf der Response, mit fünf Sekunden Timeout je Policy. Mitgelieferte Policies decken PII-Redaktion, rollenbasierte Feldfilterung und Caller-Blocking ab; die Redaktion selbst schlägt fail-closed fehl. Code Mode greift dieselbe Kategorie von der anderen Seite an — der Agent führt typisiertes JavaScript gegen die Tools aus und gibt nur zurück, was er projiziert; eine Antwort mit tausend Zeilen lässt sich so auf fünf Felder reduzieren, bevor überhaupt etwas in das Kontextfenster gelangt.

Ehrliche Reichweite: Das Open-Source-Gate kennt ausschließlich deterministische Regeln. Der LLM-basierte Compliance-Evaluator ist eine Enterprise-Erweiterung, und Human-in-the-Loop-Freigaben sind gar nicht implementiert. Eine Regel fängt, wofür Sie sie geschrieben haben.

Was ein Gateway nicht löst

Die nützlichste Kritik am Gateway-Muster in diesem Jahr kam von außerhalb des Anbieterfelds. In Securing MCP in Production: Defense-in-Depth beyond the Gateway (InfoQ, 29. Juli 2026) räumt Nik Kale ein, dass Gateways zentrale Authentifizierung, Autorisierung, Auditierung und Policy-Auswertung leisten — und ordnet dann, was um sie herum trotzdem existieren muss, in vier Verteidigungsschichten, deren früheste vertrauenswürdige Durchsetzungsstelle, so sein Argument, jeweils nicht das Gateway ist. Sein Urteil über das Muster sind zwei Sätze zu je drei Wörtern: „It is necessary. It is insufficient.“ Wir stimmen zu, und gegen die Karte oben gehalten teilen sich seine vier Schichten genau auf: Zwei landen dort, wo DADL die Mechanik bereits verändert, zwei liegen jenseits von allem, was eine Pipeline erreicht.

Sichere Tool-Ausführung. Ein Gateway kann nicht sicherstellen, dass ein Tool-Handler seine Argumente als Daten behandelt statt als Anweisungen. Für DADL-deklarierte Backends kollabiert diese Schicht bauartbedingt: Es gibt keinen Handler-Code, in dem etwas schiefgehen könnte, weil das Gateway den HTTP-Call selbst aus dem typisierten Schema konstruiert. Die Grenzen aus MCP05 bleiben stehen — was das Backend mit den Werten anstellt und jeder Handler in einem aggregierten MCP-Server liegen dahinter.
Die Management-Plane. Die Inspektoren, Harnesses, Dashboards und Konsolen rund um MCP stehen nicht hinter dem Gateway — und halten häufig mehr Rechte als die Agenten selbst. Nichts in der obigen Pipeline schützt sie.
Ausgehendes Vertrauen, Egress und Token-Scope. Serverseitige Injection verhindert, dass ein Credential das Modell erreicht. Sie verhindert nicht, dass ein Backend ein Token erhält, das breiter ist als die Aufgabe es verlangt, oder damit eigene unsichere ausgehende Aufrufe tätigt. Credential-Scoping entscheiden Sie beim Schreiben des DADL; keine Pipeline-Stufe rettet ein zu breites Token.
Semantische Integrität und Manifest-Pinning. Kales vierte Schicht ist das Rug-Pull-Problem aus MCP03 — und er hält fest, dass die MCP-Spezifikation zum Pinning schweigt: Funktionalität, die Teams am Gateway selbst bauen müssen. DADL-deklarierte Backends bekommen sie bauartbedingt, aggregierte MCP-Server nicht. Genau an dieser Stelle teilt sich unser MCP03-Urteil.

Eine Kategorie der Tabelle taucht in keiner der vier Schichten auf: MCP06. Ein authentifizierter, autorisierter, schemakonformer Call, der aus den Gründen eines Angreifers geschieht, ist kein Ausführungs-, kein Management-Plane-, kein Egress- und kein Manifest-Problem. Das sagt auf einem weiteren Weg, was die Urteilsspalte längst sagt: Ein Gateway schließt ihn nicht — mit Schichten drumherum ebenso wenig wie ohne.

Eine Lücke fügen wir selbst hinzu, weil sie speziell uns betrifft: Ein Gateway konzentriert Risiko genauso wie Kontrolle. 60 Backends hinter einem Endpunkt zu konsolidieren heißt, dass dieser Endpunkt sämtliche Credentials hält und sämtliche Tools bereitstellt — internet-exponierter MCP-Endpunkt und lohnendes Ziel in einem Objekt. Er braucht eigene Härtung, eine eigene Expositionsprüfung und einen Platz in dem Bestand, den Sie auditieren, statt nur das Werkzeug zu sein, mit dem Sie auditieren. Wir führen das als offenen Punkt an unserer eigenen Instanz, nicht als gelöstes Problem.

Zwei Dinge gehören gegen die Versuchung gesagt, all das als Argument für Nichtstun zu lesen. Erstens ist das Muster nicht spekulativ: In A Gateway Architecture for Enterprise MCP Authentication (arXiv:2608.10760, v1, 11. August 2026) beschreibt ein Autorenteam mit PayPal-Affiliation genau diese Konsolidierung — je Team unabhängig implementierte Authentifizierung, kein einheitlicher Weg, Aufrufer zu autorisieren oder eine ausscheidende Person flottenweit abzumelden — und berichtet von einer produktiven Architektur, die Dutzende interner MCP-Server bündelt. Das Paper selbst nennt den Betreiber nicht; die Zuordnung ergibt sich aus den Autorenadressen. Unabhängig von jedem Anbieter wird die Kategorie damit im Konzernmaßstab validiert. Zweitens ist „unzureichend“ nicht „nutzlos“ — und OWASP sagt das von seiner eigenen Seite aus. Das MCP Security Cheat Sheet empfiehlt, einen MCP-Proxy oder ein Gateway zur Durchsetzung von Isolationsrichtlinien zwischen Servern einzusetzen und Tool-Definitionen zu pinnen, um Rug Pulls zu erkennen. Das sind zwei der oben beschriebenen Mechanismen — empfohlen von derselben Stiftung, die die Risikoliste veröffentlicht. Jede Kategorie außer MCP06 wird am Gateway spürbar besser — und zwar einmal, statt auf jedem Server einzeln.

Wo ToolMesh steht

ToolMesh ist ein Apache-2.0-lizenziertes, selbst gehostetes MCP-Gateway in Go, das jeden Tool-Call durch eine zentrale Enforcement-Pipeline führt — autorisieren, Credentials injizieren, Gate, ausführen, Gate, auditieren —, fail-closed an jedem aktivierten Enforcement-Schritt und, wie unter MCP08 beschrieben, fail-open beim Audit-Schreibvorgang. Backends werden in DADL deklariert — YAML-Dateien, die Sie in Git halten; deshalb ist der Tool-Katalog ein prüfbares Artefakt statt einer Laufzeit-Aushandlung. Die Architektur hinter der Pipeline steht in Anatomie einer Enterprise Tool Library; wie sich das Muster unter der neuen Stateless-Spec darstellt, in MCP wird stateless.

Unser Fazit zu den Top 10, streng gelesen: Keine einzige Kategorie ist in OWASPs eigenem Zuschnitt vollständig geschlossen. Was ein Gateway leistet, ist enger und nützlicher als eine Reihe grüner Haken. Es beseitigt bestimmte Angriffswege bauartbedingt — Credentials, die das Modell erreichen; einen Interpreter auf der Tool-Ebene; per Rug Pull ausgetauschte Tool-Definitionen bei DADL-deklarierten Backends. Es legt weitere hinter einen Schalter, der umgelegt werden muss, und bypass ist die Voreinstellung. Den Rest verbessert es durch Konsolidierung, nicht durch Mechanismus. Und MCP06 liegt vollständig außerhalb seiner Grenze. Das ist eine vertretbare Position für den August 2026 und keine fertige. Die OWASP-Liste geht im Oktober in ihr nächstes Release, und wir führen diese Zuordnung lieber gegen die neue Fassung erneut durch, als sie still altern zu lassen.

Wenn Sie dieselbe Zuordnung gegen Ihren eigenen Bestand fahren und bei einer Zeile zu einem anderen Urteil kommen: GitHub Discussions ist offen — Widerspruch zu einer dieser zehn Kategorien nützt uns mehr als Zustimmung zu allen.

Quellen

Quelle	Datum	Verwendet für
OWASP Top 10 for MCP	v0.1, geprüft 18.08.2026	Kategorie-IDs, -Titel und -Zuschnitt; Projektstatus; die MCP06-Diskrepanz
OWASP MCP Security Cheat Sheet	undatiert, geprüft 18.08.2026	Credential-Leitlinien, Tool-Pinning, Gateway-Isolation, SIEM
arXiv:2608.00150 — Exposed by Design	v1, 31.07.2026	21.000+ Instanzen, 640/414 Server, 91,8 %, 687 Tools, 41,6 %
NSA-AISC-Cybersecurity-Information-Sheet zu MCP	20.05.2026	Dynamische Tool-Aufrufe, implizites Vertrauen, Context Sharing
Forkast — MCP security inflection point	11.08.2026	10+ kritische/hohe CVEs, Ökosystem-Kontext (Sekundärquelle)
InfoQ — Defense-in-Depth beyond the Gateway	29.07.2026	Die vier Verteidigungsschichten jenseits des Gateways
arXiv:2608.10760 — A Gateway Architecture for Enterprise MCP Authentication	v1, 11.08.2026	Unabhängige Produktionsvalidierung des Musters