Offener Standard, offenes Einfallstor?

MCP wird gern als neutraler Fortschritt erzählt. Ein gemeinsamer Standard. Ein Bus, an den sich Tools, Agenten, IDEs und externe Systeme anschließen können. Das klingt erst einmal vernünftig.

Sicherheitsseitig wird es genau dort interessant.

paddo greift einen Punkt auf, der für Entscheider wichtiger ist als die nächste Tool-Demo: Was passiert, wenn ein Standard als universelle Integrationsschicht verkauft wird, die Sicherheitslast aber am Ende fast vollständig nach unten durchgereicht wird?

Die Vorwürfe aus der Ox-Recherche sind nicht klein. Mehrere SDKs reichen bei STDIO-Transporten Kommandos an das Betriebssystem weiter, ohne dass das Protokoll selbst Capability-Grenzen, Sanitization oder harte Schutzmechaniken mitbringt. Theoretisch klingt das nach Transportfrage. Praktisch kann daraus schnell Remote Code Execution in nachgelagerten Projekten, IDEs oder Marktplätzen werden. Genau deshalb ist auch nicht nur die einzelne CVE interessant, sondern das Muster dahinter.

Das Muster lautet: Der Standard profitiert von Netzwerkeffekten, die Absicherung bleibt aber bei den Integratoren hängen.

Das ist für Management kein Nerd-Detail. Das ist eine klassische Infrastrukturfrage. Denn Standards sind nur dann wertvoll, wenn sie nicht nur Anschlussfähigkeit, sondern auch verlässliche Randbedingungen mitbringen. Ein offener Standard, der die Sicherheitsarbeit weitgehend an jedes einzelne Downstream-Team delegiert, erzeugt nicht nur Innovation. Er erzeugt auch verteilte Haftung, verteilte Unsicherheit und sehr vorhersehbare Patch-Lücken.

Die MCP-Spezifikation selbst ist dabei aufschlussreich. Sie beschreibt STDIO als Standardtransport, bei dem der Client den Server als Subprozess startet. Für HTTP-Transporte enthält die Spezifikation explizite Security Warnings zu Origin-Prüfung, Authentifizierung und Bindung an localhost. Genau diese Asymmetrie macht die Debatte unerquicklich. Die Sicherheitsprobleme wirken nicht wie ein Randfall neben dem Standard. Sie wirken wie etwas, das zu spät als Architekturfrage ernst genommen wurde.

Natürlich gibt es das Gegenargument. Jeder, der Prozesse startet, müsse eben wissen, was er startet. Nicht jeder unsichere Integrationspunkt ist ein Protokollfehler. Das stimmt als technischer Minimalismus. Es reicht aber politisch nicht aus, wenn derselbe Standard zugleich als zukünftige Konvergenzschicht für AI-Tooling beworben wird.

Denn dann verschiebt sich die Managementfrage. Sie lautet nicht mehr nur: Ist MCP elegant?

Sie lautet: Wollt ihr auf einen Standard setzen, bei dem Offenheit und Verbreitung schneller skalieren als die Sicherheitsgarantien, die ihr für produktiven Betrieb eigentlich bräuchtet?

Das ist keine Absage an MCP. Aber es ist eine Erinnerung daran, dass Standardisierung allein noch keine Infrastrukturqualität erzeugt.

Im Zweifel gilt auch hier die unangenehme, aber nützliche Faustregel: Wenn ein Standard den Anschluss vereinfacht, aber die Sicherheitslast nach unten verteilt, dann kauft ihr nicht nur Kompatibilität ein. Ihr kauft Governance-Arbeit.