Model Context Protocol: Der Standardkampf um KI-Agenten-Infrastruktur

Das Model Context Protocol hat den Standardkampf gewonnen. Ende 2024 lancierte Anthropic das Protokoll, das definiert, wie KI-Modelle externe Tools entdecken und aufrufen. Innerhalb von Monaten schlossen sich OpenAI, Google und Microsoft an. Die Adoption ist beeindruckend: Die Cloud Security Alliance verweist auf mehr als 150 Millionen Downloads, mehr als 7'000 öffentliche Server und bis zu 200'000 potenziell verwundbare Instanzen. Das sind OX-/CSA-Schätzungen, keine neutrale Inventur, aber sie zeigen die Grössenordnung. Die Industrie hat gesprochen. Die Frage ist nur: Worauf hat sie sich geeinigt?

MCP regelt, wie Agenten externe Werkzeuge nutzen. Was es nicht zuverlässig regelt: wem ein Agent wann vertrauen darf. Server können Fähigkeiten anmelden, aber der Host muss selbst prüfen, ob das plausibel und begrenzt genug ist. Tool-Beschreibungen und Sampling-Requests bringen zusätzlichen Text in den Modellkontext. Wenn mehrere Server verbunden sind, können Daten und Anweisungen leichter über Grenzen hinweg wirken, die eigentlich getrennt bleiben müssten. Auf dem Papier gibt es Authorization und Capability-Negotiation. In der Praxis bleibt das Berechtigungsmodell lückenhaft, besonders bei mehreren Servern und Prompt-Injection-Angriffen.

Das ist kein Bug. Das ist eine Designentscheidung.

Wie das Model Context Protocol zum Standard wurde

Vor MCP war die Integration externer Tools in KI-Modelle ein Flickenteppich. Jeder Anbieter baute eigene Adapter, jede Plattform definierte eigene Schnittstellen. Wer einen Agenten an GitHub, Slack und eine Datenbank anbinden wollte, schrieb drei separate Integrationen mit drei verschiedenen Authentifizierungslogiken und drei verschiedenen Fehlermodellen.

Anthropic erkannte das Problem früh und veröffentlichte MCP als offenes Protokoll. Der Zeitpunkt war klug gewählt: Die Branche suchte nach Standardisierung, und Anthropic bot eine Lösung an, bevor Alternativen reifen konnten. Im März 2025 adoptierte OpenAI das Protokoll offiziell und integrierte es in die ChatGPT Desktop App. Google und Microsoft folgten. Am 9. Dezember 2025 spendete Anthropic MCP an die Agentic AI Foundation, einen Directed Fund unter der Linux Foundation. Das sollte signalisieren: MCP gehört nicht mehr einem einzelnen Vendor, es soll gemeinsame Infrastruktur sein.

Der Konsolidierungsprozess verlief schneller als bei vergleichbaren Protokollstandards, weil alle Beteiligten denselben Druck spürten. Agentische KI-Systeme brauchen Werkzeugzugang, und ohne gemeinsames Protokoll fragmentiert der Markt in inkompatible Silos. Die ökonomische Logik war zwingend: Entwickler bauen dort, wo die grösste Reichweite winkt. Sobald Anthropic und OpenAI denselben Standard nutzten, war die kritische Masse erreicht.

Doch Standards, die unter Zeitdruck entstehen, tragen die Kompromisse ihrer Genese in sich. MCP wurde als Integrationsprotokoll entworfen, nicht als Sicherheitsarchitektur. Das rächt sich jetzt.

Die drei architektonischen Schwachstellen

Eine formale Sicherheitsanalyse der MCP-Spezifikation v1.0 hat drei strukturelle Probleme identifiziert, die sich nicht durch härtere Implementierungen beheben lassen. Sie stecken im Protokolldesign selbst.

Erstens: MCP-Server deklarieren bei der Initialisierung Capabilities, doch Hosts haben nur begrenzte Möglichkeiten, diese Behauptungen technisch zu verifizieren und über die gesamte Session konsistent einzuhegen. Das Prinzip der minimalen Berechtigung, ein Grundpfeiler jeder Sicherheitsarchitektur, hängt damit stark von Host-Policy, Implementierung und Nutzerentscheidung ab.

Zweitens: Das Sampling-Feature und Tool-Beschreibungen erlauben Servern, Inhalte in den Modellkontext zu bringen. Wenn Hosts diese Inhalte nicht klar markieren, begrenzen und auditieren, verschwimmt die Grenze zwischen Nutzeranweisung, Tool-Metadaten und servergeneriertem Prompt. Das öffnet die Tür für Prompt Injection auf Protokollebene.

Drittens: In Multi-Server-Konfigurationen propagiert Vertrauen in vielen Hosts implizit über Servergrenzen hinweg. Wenn ein Nutzer mehrere MCP-Server verbindet, kann ein kompromittierter Server über Kontext, Tool-Ausgaben oder indirekte Anweisungen Datenflüsse beeinflussen, die eigentlich getrennt bleiben müssten. Robuste Isolations-Boundaries zwischen Servern sind bisher eher Host-Aufgabe als Protokollgarantie.

Für den empirischen Teil testeten die Forschenden 847 Angriffsszenarien über fünf MCP-Server-Implementierungen. In diesem Versuchsaufbau erhöhte die MCP-Architektur die Angriffserfolgsraten gegenüber vergleichbaren Nicht-MCP-Integrationen um 23 bis 41 Prozent. Ohne Gegenmassnahmen lag die gemessene Gesamtangriffserfolgsrate bei 52,8 Prozent. Das ist kein universeller Branchenwert, aber ein ernstes Warnsignal für die Architekturannahmen des Protokolls.

Angriffe in der Praxis: Von der Theorie zum Exploit

Die Schwachstellen sind keine theoretischen Konstrukte. Forschungsteams haben sie in produktionsnahen Setups demonstriert.

Eine Studie von Leidos zeigte, wie Claude 3.7 und Llama-3.3-70B über Standard-MCP-Server zu drei Angriffstypen gebracht werden konnten: Malicious Code Execution, Remote Access Control und Credential Theft. Besonders aufschlussreich war das Verhalten der LLM-Guardrails. Claude verweigerte dieselbe schädliche Aktion, wenn sie obfuskiert formuliert war, führte sie im Klartext aber aus. Llama blockierte nur bei expliziten Keywords wie «hack» oder «backdoor». Die Fragilität von LLM-Guardrails als Sicherheitsnetz ist damit erneut dokumentiert.

Besonders beunruhigend ist der neu beschriebene RADE-Angriffstyp (Retrieval-Agent Deception). Ein Angreifer kompromittiert öffentlich zugängliche Dateien mit versteckten MCP-Befehlen. Wenn ein Nutzer diese Dateien in eine Vektordatenbank lädt, werden die Befehle bei späteren Abfragen automatisch ausgeführt. In einer End-to-End-Demo suchte Claude via Chroma-MCP-Server eine kompromittierte Datei, extrahierte OpenAI- und HuggingFace-API-Keys aus Environment Variables und postete sie automatisiert in einen Slack-Kanal. Ein zweites Szenario schrieb den SSH-Key eines Angreifers in die authorized_keys-Datei des Opfers.

Im April 2026 eskalierten die Befunde. OX Security veröffentlichte die Disclosure am 15. April nach eigenen Angaben nach einer Recherche, die im November 2025 begonnen hatte. Die Studie beschrieb eine Designschwäche rund um STDIO-basierte MCP-Setups und warnte vor einer Supply-Chain-Angriffsfläche, die sich nicht auf einzelne fehlerhafte Server reduzieren lässt. Parallel tauchten mehrere CVEs in MCP-nahen Tools und Integrationen auf, darunter MCP Inspector, LibreChat, WeKnora, Cursor und Windsurf. Entscheidend ist weniger die einzelne Nummer im CVE-Katalog als das Muster: Eine junge Integrationsschicht wird schneller produktiv ausgerollt, als ihre Sicherheitsannahmen belastbar geprüft werden.

Anthropic wurde laut OX Security über die Designschwäche informiert und wertete das Verhalten als expected behavior. Die Cloud Security Alliance bestätigte am 20. April 2026 in der Research Note «MCP by Design: RCE Across the AI Agent Ecosystem» den Kernbefund: Die RCE-Gefahr hängt demnach an einer bewussten STDIO-Architekturentscheidung und nicht an einem einzelnen Coding-Fehler. Damit steht zusätzlich zum Vendor-Advisory eine unabhängige Sicherheitsorganisation gegen die These, hier handle es sich bloss um erwartbares Verhalten.

Antipatterns & Systemische Risiken

Das MCP-Ökosystem reproduziert bekannte Antipatterns aus der Software-Supply-Chain in beschleunigter Form.

Registry-Vertrauen ohne Vetting. Sechs öffentliche MCP-Registries wurden empirisch untersucht. Von 67.057 analysierten Servern wiesen 833 exploitierbare Code-Schwachstellen auf, 18 enthielten verdächtige Tool-Beschreibungen, die das Reasoning von Sprachmodellen manipulieren konnten. OX fand dasselbe Muster aus der anderen Richtung: Neun von elf getesteten MCP-Marketplaces liessen sich mit einem harmlosen Proof-of-Concept-Server vergiften, darunter populäre Verzeichnisse wie LobeHub und Cursor Directory. Server werden veröffentlicht und sofort auffindbar, analog zu den frühen Tagen von npm, bevor Supply-Chain-Angriffe das Ökosystem erschütterten.

Guardrails als Sicherheitstheater. Die wiederholte Demonstration, dass LLM-Guardrails je nach Formulierung dieselbe Aktion erlauben oder blockieren, offenbart ein Grundproblem der aktuellen Agenten-Sicherheitsarchitektur. Wer Sicherheit auf die Fähigkeit eines Sprachmodells stützt, schädliche Absichten zu erkennen, baut auf Sand. Die Agenten-Sicherheitsforschung weist seit Monaten darauf hin, dass deterministische Sicherheitsschichten jenseits des LLM-Reasoning nötig sind.

Der Governance-Bruch

Die Donation von MCP an die Agentic AI Foundation unter der Linux Foundation im Dezember 2025 war politisch geschickt, aber strukturell noch nicht ausreichend. Die Spezifikation wird weiterhin massgeblich von Anthropic vorangetrieben. Die Foundation stellt den institutionellen Rahmen, aber die Entscheidungsgewalt über Protokolländerungen liegt faktisch bei den Unternehmen, die die Referenzimplementierungen kontrollieren.

Das erzeugt eine spezifische Dynamik. Anthropic hat ein kommerzielles Interesse daran, MCP-Adoption zu maximieren, weil jeder MCP-Server die Nützlichkeit von Claude als Plattform steigert. Sicherheitsverschärfungen, die Reibung in der Entwicklererfahrung erzeugen, stehen in direktem Konflikt mit diesem Wachstumsziel. Die Ablehnung architektonischer Änderungen nach der OX-Security-Disclosure fügt sich in dieses Muster. Schwerer wiegt, dass die Cloud Security Alliance den Befund wenige Tage später bestätigte: Wenn ein unabhängiger Sicherheitsverband dieselbe Architektur als RCE-Risiko beschreibt, reicht «expected behavior» als Antwort nicht mehr.

OpenAI und Google haben MCP adoptiert, weil die Alternative, ein eigenes konkurrierendes Protokoll durchzusetzen, teurer gewesen wäre als die Übernahme eines bereits etablierten Standards. Aber ihre Adoption bedeutet nicht, dass sie MCP mitgestalten. Sie konsumieren den Standard, ohne die Sicherheitslast mitzutragen.

Das Ergebnis ist ein Protokoll, das von allen genutzt, aber von niemandem verantwortet wird. Ein bekanntes Muster aus der Geschichte offener Standards, von OpenSSL bis Log4j. Diesmal liegt die Angriffsfläche allerdings in der gesamten Interaktionsschicht zwischen KI-Modellen und der Aussenwelt.

Second-Order Effects: Was in 12 bis 24 Monaten passiert

Fragmentierung der Sicherheitsschichten. Weil MCP selbst keine Sicherheit erzwingt, werden Drittanbieter diese Lücke füllen. Tools wie McpSafetyScanner und MCPInspect existieren bereits. In den nächsten Monaten wird ein Markt für MCP-Security-Middleware entstehen, vergleichbar mit der WAF-Industrie, die sich um die Unsicherheit von Web-Applikationen herum aufgebaut hat. Das Problem dabei: Jeder Anbieter wird eigene Heuristiken und Policies implementieren. Die Sicherheitslandschaft fragmentiert, und Entwickler müssen sich zwischen konkurrierenden Lösungen entscheiden, deren Wirksamkeit sie nicht beurteilen können. Das Versprechen eines einheitlichen Protokolls wird durch eine uneinheitliche Sicherheitsschicht darüber konterkariert.

Regulatorische Kollateralschäden. Sobald ein MCP-basierter Angriff in einem regulierten Umfeld Schaden anrichtet, etwa in der Finanzbranche oder im Gesundheitswesen, werden Compliance-Frameworks reagieren. Da MCP selbst keine einheitliche Audit- und Policy-Schicht erzwingt und Berechtigungen hostabhängig bleiben, fehlt oft die Grundlage für Nachvollziehbarkeit. Für DACH-Unternehmen ist das keine abstrakte Compliance-Frage. Eine Schweizer Bank, die MCP-Agenten unter FINMA-Aufsicht produktiv einsetzt, müsste erklären können, warum ein System mit dokumentiertem RCE-Risiko, uneinheitlicher Berechtigungsdurchsetzung und schwacher Auditierbarkeit ausreichend kontrolliert ist. Genau diese Begründung wird schwierig, solange die Sicherheit primär am Host und nicht am Protokoll hängt. Wahrscheinlicher als ein Verbot sind zusätzliche Dokumentations- und Überwachungspflichten, die den operativen Aufwand für agentische Systeme erheblich steigern.

Vendor-Lock-in durch die Hintertür. MCP ist ein offener Standard, aber die Referenzimplementierungen und die populärsten Server werden von den grossen Anbietern kontrolliert. Wer heute einen MCP-Server für sein Produkt baut, optimiert implizit für die Eigenheiten der dominanten Hosts. Wenn Anthropic oder OpenAI proprietäre Erweiterungen einführen, die in der Spezifikation nicht vorgesehen, aber in der Praxis unverzichtbar sind, wiederholt sich das Muster von Embrace-Extend-Extinguish in neuem Gewand. Die Linux-Foundation-Governance bietet dagegen wenig Schutz, solange die faktische Kontrolle bei den Implementierern liegt.

Was jetzt passieren muss

Die Forschung liefert neben Diagnosen auch Ansätze. MCPSec, in Teilen auch als AttestMCP-Ansatz diskutiert, skizziert ein Overlay, das Server-Capabilities kryptographisch verifiziert und Capability-Eskalation blockiert. ETDI geht in dieselbe Richtung: OAuth-erweiterte Tool-Definitionen, kryptographische Tool-Identität und überprüfbare Metadaten, damit ein Host den Tool-Namen zusammen mit einer attestierten Identität sieht. MCP-Guard und Pre-Integration-Tools wie MCPInspect können verdächtige Server vor dem Deployment identifizieren.

Aber technische Patches allein reichen nicht. MCP braucht drei Dinge auf Spezifikationsebene: ein Berechtigungsmodell, das Least Privilege durchsetzt; eine Isolationsarchitektur für Multi-Server-Setups; und Audit-Fähigkeit, die nachvollziehbar macht, welcher Server welche Aktion ausgelöst hat. Konkret heisst das: signierte Tool-Definitionen, verpflichtende Allowlist-Policies für STDIO-Server, getrennte Kontext- und Datenräume pro Server und maschinenlesbare Logs für jeden Tool-Aufruf. Solange diese Elemente fehlen, bleibt MCP eine Integrationsschicht ohne Sicherheitsgarantien.

Die Industrie hat ein Zeitfenster. MCP ist jung genug, dass Breaking Changes in der Spezifikation noch vertretbar wären. In zwei Jahren, wenn Hunderttausende produktive Deployments auf der aktuellen Architektur laufen, wird jede Verschärfung zum Migrationsprojekt. Wer jetzt nicht handelt, zementiert die Schwächen für eine Generation von Agenten-Software.

Fazit

MCP hat den Standardkampf um die KI-Agenten-Infrastruktur gewonnen. Die Architektur ist nicht fertig. Das Protokoll definiert, wie Agenten mit Tools sprechen, aber nicht zuverlässig genug, wie sie dabei sicher bleiben. Hohe Angriffserfolgsraten in Forschungstests, uneinheitliche Berechtigungsdurchsetzung und eine Governance, die Adoption stärker belohnt als harte Sicherheitsbrüche, sind keine Kinderkrankheiten. Sie sind das Fundament, auf dem das Ökosystem gerade baut. MCP-basierte Angriffe werden in Produktionsumgebungen Schaden anrichten. Offen ist, ob die Spezifikation vorher repariert wird.