Die OWASP MCP Top 10: das Protokoll der Agenten absichern

Es sind komplementäre OWASP-Listen auf verschiedenen Zoomstufen, und wer mit Agenten baut, sollte beide lesen. Die Top 10 für agentische Anwendungen decken den Agenten als Ganzes ab — wie er denkt, was er darf, wie Aufsicht greift — und spannen von Prompt Injection über Excessive Agency bis Gedächtnis und menschliche Kontrolle. Die MCP Top 10 zoomen in eine bestimmte Schicht: das Model Context Protocol, das den Agenten mit seinen Tools und Daten verbindet, mit Risiken wie zu weiter Server-Autorisierung, manipulierten Tool-Beschreibungen, Lieferketten-Exposition durch Drittanbieter-Server und undichtem Transport. Beide überlappen bewusst, statt zu konkurrieren; dasselbe Tool-Poisoning-Risiko etwa erscheint in beiden, doch die MCP-Liste liefert das Detail auf Protokollebene. Nützlich ist, die agentische Liste auf Systemebene und die MCP-Liste auf Integrationsebene anzuwenden, damit keine Schicht im Default bleibt.

Breite, langlebige Autorisierung ist das wiederkehrende Thema und der Grund, warum die Autorisierungskategorie ganz oben steht. Das typische Muster ist ein Server oder Token, der korrekt authentifiziert — er weist nach, wer der Agent ist —, aber nie richtig autorisiert, sodass die Identität nach dem Verbinden weit mehr darf, als eine einzelne Aufgabe braucht. Kommen Credentials hinzu, die nie ablaufen und über Tools geteilt werden, erbt eine einzige Kompromittierung weitreichenden Zugriff. Die wirkungsvollste Maßnahme ist feingranulare Laufzeit-Autorisierung über ein MCP-Gateway, das pro Aktion statt pro Login entscheidet, gestützt auf kurzlebige, eng gefasste Credentials. Diese eine Änderung verkleinert den Schadensradius fast jedes anderen MCP-Risikos, denn selbst ein vergiftetes Tool oder ein geleaktes Token trifft auf eine Policy-Prüfung, bevor es etwas Sensibles erreicht. Wenn Sie sonst nichts von der Liste tun, tun Sie das.

Behandeln Sie jeden Drittanbieter-MCP-Server als nicht vertrauenswürdige Abhängigkeit, denn genau das ist er — Code und Definitionen von außerhalb Ihrer Vertrauensgrenze, auf die sich Ihr Agent dann verlässt. Das Lieferkettenrisiko ist real: Ein ungeprüfter oder später kompromittierter Server wird zum Brückenkopf im vertrauten Tool-Set des Agenten, und weil der Server sowohl Tool-Beschreibungen als auch Ausgaben kontrolliert, kann er den Agenten täuschen oder Kontext exfiltrieren, ohne Sie je direkt anzugreifen. Das ist kein Grund, das Ökosystem zu meiden, das wirklich nützlich ist, aber ein Grund, externe Server in die Kontrollen jeder Abhängigkeit zu hüllen. Prüfen Sie Quelle und Pflege, pinnen und reviewen Sie die übernommenen Definitionen, isolieren Sie die Ausführung in einer Sandbox, gewähren Sie Least Privilege und führen Sie Audit-Logs pro Identität, um nachzuvollziehen, was ein Server tatsächlich tat. Die Bequemlichkeit eines externen Servers hebt die Notwendigkeit nie auf, sein Vertrauen zu begrenzen.

Ja — der Großteil der Liste gilt für Clients ebenso wie für Server-Betreiber, denn einen Server zu nutzen heißt, seiner Autorisierung, seinen Tool-Definitionen und seinen Ausgaben zu vertrauen. Als Konsument kontrollieren Sie vielleicht nicht, wie ein Server gebaut ist, aber Sie kontrollieren, wie viel Vertrauen und Zugriff Sie ihm gewähren — und genau dort sitzt das eigentliche Risiko. Die Kategorien Autorisierung, Lieferkette und Tool-Integrität liegen klar in Ihrer Client-seitigen Verantwortung: Sie entscheiden, welche Server Sie verbinden, welche Scopes deren Credentials tragen, ob Sie ihre Definitionen pinnen und ob ihre Ausführung isoliert und auditiert ist. Einen Server zu hosten bringt weitere Pflichten rund um Transportsicherheit und Datenexposition, aber ein reiner Konsument besitzt weiterhin die Entscheidungen, die den Schadensradius bestimmen. Behandeln Sie in der Praxis jeden verbundenen Server als Teil Ihrer eigenen Angriffsfläche und wenden Sie dieselbe Least-Privilege- und Review-Disziplin an, egal wer ihn geschrieben hat.