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

> Die OWASP MCP Top 10 (v0.1, Beta) benennen zehn Risikokategorien für Model-Context-Protocol-Installationen. Gegen die Enforcement-Pipeline eines Gateways gehalten, schließt keine einzige davon vollständig: Manche Angriffswege verschwinden bauartbedingt, andere hängen an einer Voreinstellung, die ausgeschaltet ausgeliefert wird, und MCP06 liegt außerhalb der Gateway-Grenze. Mit den Expositionszahlen aus arXiv 2608.00150, den NSA-AISC-Design-Empfehlungen und der MCP06-Titeldiskrepanz auf der OWASP-Seite selbst.

Canonical: https://www.toolmesh.io/de/blog/owasp-mcp-top-10/

**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](https://github.com/DunkelCloud/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*](https://arxiv.org/abs/2608.00150) (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](https://forkast.news/the-model-context-protocol-reaches-a-security-inflection-point/) 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*](https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4496698/nsa-releases-security-design-considerations-for-ai-driven-automation-leveraging/). 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](https://owasp.org/www-project-mcp-top-10/) 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`](https://github.com/DunkelCloud/ToolMesh/blob/main/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](https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html) 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](https://openfga.dev/)-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](/de/authorization/) 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](/de/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*](https://arxiv.org/abs/2605.05247) (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](/de/authentication/) 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.

### MCP10:2025 — Context Injection & Over-Sharing

Das [Output Gate](/de/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](/de/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*](https://www.infoq.com/articles/securing-mcp-production-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*](https://arxiv.org/abs/2608.10760) (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](https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html) 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](/de/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](/de/blog/anatomy-of-an-enterprise-tool-library/); wie sich das Muster unter der neuen Stateless-Spec darstellt, in [MCP wird stateless](/de/blog/mcp-goes-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](https://github.com/DunkelCloud/ToolMesh/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](https://owasp.org/www-project-mcp-top-10/) | v0.1, geprüft 18.08.2026 | Kategorie-IDs, -Titel und -Zuschnitt; Projektstatus; die MCP06-Diskrepanz |
| [OWASP MCP Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html) | undatiert, geprüft 18.08.2026 | Credential-Leitlinien, Tool-Pinning, Gateway-Isolation, SIEM |
| [arXiv:2608.00150 — *Exposed by Design*](https://arxiv.org/abs/2608.00150) | v1, 31.07.2026 | 21.000+ Instanzen, 640/414 Server, 91,8 %, 687 Tools, 41,6 % |
| [NSA-AISC-Cybersecurity-Information-Sheet zu MCP](https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4496698/nsa-releases-security-design-considerations-for-ai-driven-automation-leveraging/) | 20.05.2026 | Dynamische Tool-Aufrufe, implizites Vertrauen, Context Sharing |
| [Forkast — MCP security inflection point](https://forkast.news/the-model-context-protocol-reaches-a-security-inflection-point/) | 11.08.2026 | 10+ kritische/hohe CVEs, Ökosystem-Kontext (Sekundärquelle) |
| [InfoQ — *Defense-in-Depth beyond the Gateway*](https://www.infoq.com/articles/securing-mcp-production-gateway/) | 29.07.2026 | Die vier Verteidigungsschichten jenseits des Gateways |
| [arXiv:2608.10760 — *A Gateway Architecture for Enterprise MCP Authentication*](https://arxiv.org/abs/2608.10760) | v1, 11.08.2026 | Unabhängige Produktionsvalidierung des Musters |