Der sichtbarste Umbau ist nach Angaben des Model Context Protocol Blog der Wechsel zu einem zustandslosen Protokollmodell. Sechs Vorschläge zur Weiterentwicklung der Spezifikation wirken dabei zusammen. Für Betreiber und Entwickler gibt es nach Veröffentlichung der finalen Fassung ein zwölfmonatiges Zeitfenster, um Altsysteme abzulösen; die zehn Wochen zwischen Freigabekandidat und endgültiger Spezifikation sind laut Blog für SDK-Verantwortliche und Client-Implementierer gedacht, um die Änderungen mit realen Arbeitslasten zu prüfen.
Akamai beschreibt die neue Fassung als zweischneidig. Zu den Verbesserungen zählt das Unternehmen das Ende von Sitzungsübernahmen, die Verhinderung unaufgeforderter, vom Server initiierter Aufforderungen sowie stärkere Authentifizierungsstandards. Gleichzeitig entstehen neue Angriffsflächen. Wichtig sei dabei: Nicht das MCP-Protokoll selbst werde anfälliger, sondern die Angriffsfläche von MCP-Servern, die auf der neuen Spezifikation aufbauen.
Gerade die Zustandslosigkeit bringt laut Akamai neue Risiken mit sich. An die Stelle dauerhafter Sitzungen treten Verfolgungskennungen und Zustandsobjekte, die der Server an den Client übergibt. Sind solche Kennungen vorhersagbar, nennt Akamai drei mögliche Folgen: die Übernahme eines laufenden Arbeitsablaufs, den Zugriff auf Daten eines anderen Agenten und das Auslösen nicht autorisierter mandantenübergreifender Aktionen.
Hinzu kommen neue MCP-spezifische HTTP-Header wie MCP-Method und MCP-Name. Akamai sieht darin zwei zusätzliche Risiken: Angriffe durch Protokollverwirrung im Sinne von Desynchronisierung sowie Datenabfluss über x-mcp-header. Das Unternehmen warnt, dass Entwickler sensible Eingaben wie API-Schlüssel, Token oder personenbezogene Informationen versehentlich in Header abbilden könnten. Diese Geheimnisse würden dann für Load Balancer, Proxys und Protokollierungssysteme entlang des Übertragungswegs sichtbar.
Zwei weitere Änderungen vergrößern die Angriffsfläche aus Sicht von Akamai ebenfalls. Erstens werden MCP Apps zu einer Protokollerweiterung erster Klasse. Das verbessere die Nutzererfahrung, führe aber klassische Browser-Risiken ein, darunter gespeichertes Cross-Site-Scripting. Zweitens schaffen langlaufende Aufgaben einen erheblichen DoS-Vektor, der auf Einweg-Interaktionen beruht. Die Erstellung einer Aufgabe sei für den Client billig, für den Server aber ressourcenintensiv. Ein Angreifer könne mit einer einzelnen Anfrage eine teure Operation anstoßen, die CPU, Arbeitsspeicher oder Datenbankspeicher verbraucht, und die Verbindung sofort wieder trennen.
Maxim Zavodchik, Senior Director of Threat Research bei Akamai, erwartet deshalb spürbare Folgen für Sicherheitsteams. Weil das Protokoll zu einem zustandslosen Modell wechsle und umfangreiche UI-Apps sowie asynchrone Aufgaben einführe, hingen kritische Sicherheitsgrenzen nun vollständig davon ab, wie Entwickler sie umsetzen. Nach seiner Einschätzung verbessert das Update zwar das Fundament, indem es ältere Risiken auf Protokollebene beseitigt; die konkrete Sicherheitslage werde künftig aber von Implementierungsentscheidungen bestimmt.
Akamai nennt mehrere besonders fehleranfällige Bereiche. Dazu zählen die Übernahme von Arbeitsabläufen und mandantenübergreifender Zugriff, Rechteausweitung und Geheimnisabfluss, Inkonsistenzen zwischen Header und Nachrichtenkörper, die Sicherheitskontrollen umgehen können, schnelle DoS-Angriffe auf langlaufende Aufgaben sowie die Ausführung schädlicher Skripte und Phishing über unsichere UI-Panels. Das Unternehmen fasst den Wandel so zusammen: Es gehe nicht um bloß schrittweise Verbesserungen, sondern um eine grundlegende Neuverteilung der Sicherheitsverantwortung.