Das MCP-Versprechen ist elegant: Agenten erhalten eine konsistente, prüfbare Möglichkeit, Tools aufzurufen. Doch eine entscheidende Nuance zeichnet sich ab – nachdem ein Nutzer einem Server vertraut hat, verkleinert sich die Angriffsfläche nicht, sie verlagert sich. Eine versteckte Anweisung in der Antwort oder im Kontext des Servers kann das Modell dazu bringen, genau die Tools zu nutzen, die es aufrufen darf, nun jedoch mit dem Ziel, Tokens, API-Schlüssel oder interne Daten auszuspähen. Dies ist kein klassischer Jailbreak; es handelt sich um einen Steuerungsangriff nach der Freigabe, der legitime Fähigkeiten ausnutzt.

Das Muster ist täuschend einfach. Ein Nutzer genehmigt einem Server und einer Reihe von Tools den Zugriff. Später liefert der Server eine harmlos wirkende Nutzlast zurück, die strategisch platzierte Anweisungen enthält. Das Modell, das innerhalb seiner erteilten Berechtigungen arbeitet, folgt diesen: Es ruft einen genehmigten Befehl auf, liest eine Datei oder Umgebungsvariable aus und übermittelt das Ergebnis an einen vom Angreifer kontrollierten Endpunkt. Da jeder Schritt technisch im erlaubten Rahmen liegt, passieren naive Richtlinienprüfungen und herkömmliche Jailbreak-Filter selten eine Erkennung. Die Vertrauensgrenze hat sich vom Klick auf den Button auf den gesamten Gesprächs- und Tool-Aufrufzyklus verschoben.

Für Unternehmen, die agentenbasierte Workflows pilotieren, sind die Auswirkungen operativ, nicht theoretisch. Sicherheitskontrollen müssen regeln, wie, wann und mit welchen Parametern Tools verwendet werden dürfen – besonders beim Zugriff auf Geheimnisse, Systemeinsichten und externe Netzwerkaufrufe. Compliance- und Audit-Teams sollten MCP-Server wie Drittanbietersoftware behandeln: Atteste verlangen, sie durch Netzwerk- und Namespace-Kontrollen isolieren, temporäre Zugangsdaten rotieren und manipulationssichere Protokolle vorschreiben. Am wichtigsten ist, die Befugnis zur Tool-Freigabe von den Umständen zu trennen, die dessen Nutzung bei einer bestimmten Anfrage erlauben.

Gegenmaßnahmen existieren, müssen aber präzise sein. Erzwingen Sie Parameter-Whitelist und verweigern Sie gefährliche Wildcards standardmäßig. Fordern Sie für risikoreiche Operationen (Geheimnisse lesen, Dateien schreiben, externe URLs ansteuern) Bestätigungen außerhalb des normalen Ablaufs. Nutzen Sie kryptographische Signaturen für Serverantworten und binden Sie Freigaben an kurzlebige Sitzungen mit engen Berechtigungen. Setzen Sie eine Kontext-Firewall ein, die tool-orientierte Anweisungen aus nicht vertrauenswürdigen Inhalten entfernt oder isoliert. Überwachen Sie schließlich auf Zwangsmuster – plötzliche Datenabflüsse, wiederholtes Umgehen von Schemata oder Modelle, die Anweisungen zum Offenlegen von Tokens wiederholen – und widerrufen Sie Sitzungen automatisch bei Auslösung.