Der MCP-Fehler, der KI-Agenten zum Risiko macht

Wenn es um die Sicherheit von KI-Systemen geht, konzentrieren wir uns oft zu sehr auf das Modell selbst: Trainingsdaten, Prompt-Injection oder Output-Filter. Dabei entsteht eine kritische Schwachstelle im Verbindungsgewebe, das diesen Modellen Handlungsfähigkeit verleiht: den Protokollen, die KI-Agenten mit den Werkzeugen und Daten verbinden, die sie nutzen. Das Model Context Protocol (MCP), ein beliebter Standard zum Anschluss von KI-Agenten an externe Ressourcen wie Datenbanken, APIs und Software-Tools, eröffnet eine subtile, aber wirkungsvolle neue Angriffsfläche. Forschungen zeigen, dass diese Protokollschicht eigene Sicherheitsprobleme schafft und vertrauenswürdige Tool-Integrationen in ein ernsthaftes Software-Supply-Chain-Risiko verwandelt [1].

Warum das jetzt wichtig ist

Das Kernproblem ist nicht einfach nur eine neue Variante von Prompt-Hacking. Es ist ein struktureller Fehler darin, wie KI-Agenten ihre Umgebung wahrnehmen und ihr vertrauen. MCP ermöglicht es Agenten, Werkzeuge über standardisierte Beschreibungen zu entdecken und zu nutzen. Diese Beschreibungen, oder Tool-Metadaten, teilen dem Agenten mit, was das Tool tut, wie es aufzurufen ist und welche Parameter zu verwenden sind. Dieses System ist für Flexibilität und Interoperabilität ausgelegt, schafft aber stillschweigend eine kritische Abhängigkeit. Das Verständnis des Agenten von einem Werkzeug: und damit sein Verhalten: wird vollständig von diesen Metadaten diktiert. Wenn diese Metadaten vergiftet sind, wird das Vertrauen des Agenten in das Tool zu seiner Achillesferse.

Dieser Angriffsvektor, als „Tool Poisoning“ bezeichnet, besteht darin, bösartige Anweisungen direkt in die Metadaten eines Tools einzubetten [2]. Anders als traditionelle Angriffe, die den Prompt des Modells ins Visier nehmen, nutzt diese Methode die Protokollschicht aus. Eine vergiftete Tool-Beschreibung könnte den Agenten beispielsweise anweisen, eine Datenbankabfrage so zu formatieren, dass sie sensible Datensätze preisgibt, oder eine API mit Parametern aufzurufen, die eine serverseitige Schwachstelle auslösen. Da der Agent diese Anweisung als Teil des vertrauenswürdigen Tool-Entdeckungsprozesses erhält, führt er die bösartige Aktion möglicherweise ohne jeden verdächtigen Nutzer-Prompt aus. In diesem Szenario ist die Integrität der Tool-Beschreibung wichtiger als die eigenen Sicherheitsvorkehrungen des Modells.

Das Risiko steigert sich vom abstrakten Konzept zu einem konkreten Bereitstellungsproblem, wenn man reale MCP-Integrationen betrachtet. Eine Warnmeldung aus dem Jahr 2026 bezüglich eines MCP-Server-Pakets für Atlassian-Produkte zeigte, wie dies mehrere Schwachstellen verketten konnte [3]. Die Meldung verknüpfte Server-Side Request Forgery (SSRF), den Diebstahl von Zugangsdaten und traditionelle Prompt-Injection über einen kompromittierten MCP-Tool-Server. Dies veranschaulicht, dass ein einziges vergiftetes Tool in einem gemeinsam genutzten MCP-Ökosystem zu einem Supply-Chain-Problem werden kann, das jeden Agenten betrifft, der sich damit verbindet. Organisationen mögen ihre eigenen KI-Modelle rigoros prüfen, aber wenn sie diese Modelle an einen gemeinsam genutzten MCP-Server mit einem vergifteten Tool anschließen, ist die gesamte Funktionalität des Agenten kompromittiert.

Was sich in der Praxis aendert

Dies schafft einen klassischen Software-Supply-Chain-Angriff, der an Schwachstellen in traditionellen Software-Bibliotheken erinnert. Man vertraut einer Komponente, weil sie weit verbreitet und legitim erscheint, aber ihre Beschreibung enthält eine versteckte Nutzlast. Für KI-Agenten ist die „Komponente“ die Tool-Definition. Der Angriff erfordert nicht die Korrumpierung des Kerncodes oder der Modellgewichte des Agenten; es reicht aus, die Anweisungen zu korrumpieren, die dem Agenten mitteilen, wie er ein scheinbar harmloses Werkzeug benutzen soll. Dies verlagert die Sicherheitslast. Die Verteidigung muss sich nun über das KI-Modell hinaus auf die gesamte Tool-Entdeckungs- und Protokollverarbeitungs-Pipeline erstrecken.

Die Implikationen sind besonders bedeutsam für Unternehmen, die Prozesse mit KI-Agenten automatisieren. Ein Agent, der für den Kundensupport zuständig ist und ein vergiftetes Tool zum Zugriff auf die Support-Ticket-Datenbank verwendet, könnte unbeabsichtigt Daten preisgeben. Ein Agent, der Cloud-Infrastruktur verwaltet und von bösartigen Metadaten geleitet wird, könnte Sicherheitseinstellungen falsch konfigurieren. Der Einbruchsvektor ist nicht eine gehackte KI; es ist eine gehackte Bedienungsanleitung für ein Werkzeug, das die KI benutzt. Dies passt zu einem breiteren Trend in der Cybersicherheit, bei dem die schädlichsten Verstöße oft von übersehener, „langweiliger“ Infrastruktur ausgehen, nicht von spektakulären, direkten Angriffen.

Die Bewältigung dessen erfordert eine neue Sicherheitsmentalität. Erstens müssen Tool-Metadaten als kritische, verifizierbare Assets behandelt werden. Organisationen sollten Signierung und Verifizierung für MCP-Tool-Schemata implementieren, ähnlich wie sie Software-Pakete verifizieren würden. Zweitens benötigen Agenten-Bereitstellungen eine „Tool-Kontext“-Überwachung. Logs sollten nicht nur protokollieren, welche Prompts ein Agent erhalten hat, sondern auch, welche Tool-Definitionen er konsumiert und danach gehandelt hat. Schließlich muss das Prinzip der geringsten Rechte für den Tool-Zugriff gelten. Ein Agent sollte nicht in der Lage sein, Werkzeuge aus ungeprüften Quellen zu entdecken und zu nutzen, nur weil sie auf einem MCP-Server beworben werden.

Die Schwachstelle unterstreicht, dass KI-Sicherheit ein Systemproblem ist, nicht nur ein Modellproblem. Da die Sicherheit von MCP selbst von der Integrität oft ignorierter Tool-Metadaten abhängt, erfordert die Sicherung des Agenten die Sicherung jedes Glieds in seiner operationellen Kette. Das Protokoll, das KI-Agenten befähigt, in der realen Welt zu handeln, schafft auch einen neuen Pfad für Angreifer, durch sie zu handeln. Der Fehler liegt nicht in der Intelligenz des Agenten, sondern in dem Vertrauen, das er in die Beschreibungen der von ihm genutzten Werkzeuge setzt: ein Supply-Chain-Risiko, das sich in aller Öffentlichkeit verbirgt.