MCP-Sicherheit 2026: Die Human-in-the-Loop-Lücke in der Spezifikation

Die Model Context Protocol-Spezifikation räumt in klarem Wortlaut ein, dass sie menschliche Freigabe vor einem KI-Tool-Akt nicht erzwingen kann — diese Garantie ist eine Empfehlung für die Anwendung darüber, keine Regel, die MCP selbst prüft. Für jede Agentur, die ihre eigene KI oder die eines Kunden über MCP an echte Geschäftssysteme anbindet, ist dieser eine Satz das gesamte Risikomodell. Das Protokoll sagt deiner KI, welche Tools existieren und was sie vorgeben zu tun. Ob ein Mensch tatsächlich sieht und freigibt, was gleich passieren soll, liegt vollständig bei demjenigen, der den Client gebaut hat.

Was sagt die MCP-Spezifikation tatsächlich über Zustimmung?

Der Abschnitt „Key Principles“ der Spezifikation ist direkt über die Grenzen dessen, was das Protokoll garantiert:

“1. User Consent and Control — Users must explicitly consent to and understand all data access and operations… 3. Tool Safety — Tools represent arbitrary code execution and must be treated with appropriate caution… Hosts must obtain explicit user consent before invoking any tool.”

Und dann, unmittelbar danach:

“While MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD: Build robust consent and authorization flows into their applications…”

Das ist die Lücke in einem Absatz. Die Prinzipien sind mit kleingeschriebenem „must“ formuliert, was nach der Konvention, der die MCP-Spezifikation folgt, Empfehlung bedeutet, kein Protokollanforderung. Die separate Tools-Spezifikation wiederholt dieselbe Struktur in ihrem „User Interaction Model“: „there SHOULD always be a human in the loop with the ability to deny tool invocations“, zusammen mit der Anleitung, dass Anwendungen „SHOULD… present confirmation prompts to the user for operations.“ Empfohlen. Nicht erzwungen. Nichts, was ein MCP-Server verifizieren kann, dass ein Client tatsächlich tut.

Das ist kein MCP-spezifischer Fehler — kein Protokoll kann eine darauf aufgebaute Anwendung zu einem bestimmten Verhalten zwingen. Aber es bedeutet, dass „unsere KI ist über MCP verbunden“ dir nichts darüber sagt, ob ein Mensch tatsächlich in der Schleife ist. Das ist eine Behauptung über die konkrete Anwendung, und sie muss dort verifiziert werden, nicht aus dem Protokollnamen angenommen.

Was passiert, wenn die Lücke ausgenutzt wird

Drei dokumentierte Vorfälle zeigen, was die Lücke in der Praxis kostet — an drei verschiedenen Punkten der Kette.

Asana, Juni 2025 — der Isolationsfehler. Asana startete am 1. Mai 2025 eine MCP-Integration. Am 4. Juni wurde ein Mandantenisolations-Bug identifiziert, und die Integration wurde für etwa zwei Wochen offline genommen, während er behoben wurde. Der Fehler ließ Daten einer Organisation — Aufgaben, Projektmetadaten, Teamdetails, Kommentare und hochgeladene Dateien — über Organisationsgrenzen hinweg sichtbar werden. Etwa 1.000 Kunden waren betroffen, und die Schwachstelle bestand seit dem ersten Tag der Funktion. Das war kein Human-in-the-Loop-Fehler im engeren Sinne — es erinnert daran, dass die Isolationsgrenze um das, was eine MCP-Integration erreichen kann, genauso zählt wie wer den Aufruf freigibt.

GitHub, Mai 2025 — der „toxic agent flow“. Sicherheitsforscher bei Invariant Labs demonstrierten einen Angriff, bei dem ein Entwickler einen KI-Agenten, verbunden über GitHubs MCP-Server, bat, offene Issues in einem öffentlichen Repository zu prüfen. Ein platziertes Issue enthielt versteckte Anweisungen. Der Agent las sie und nutzte dann seinen bereits autorisierten Zugriff auf die privaten Repositories des Entwicklers, um sensible Informationen zu ziehen und in einem Pull Request im öffentlichen Repo zu posten. Jeder einzelne Tool-Aufruf des Agenten war einer, den der Nutzer wirklich autorisiert hatte. Was nicht autorisiert war — und was kein einzelner Freigabe-Prompt erfasst hätte — war die Kombination: ein öffentliches Issue lesen, dann auf privaten Daten handeln, dann extern veröffentlichen. Invariants eigene Schlussfolgerung war klar: „This vulnerability cannot be resolved through server-side patches.“ Es ist ein Architekturproblem darin, wie Berechtigungen über Tool-Aufrufe hinweg zusammenspielen, kein Bug in GitHubs Code.

Microsoft, 30. Juni 2026 — die Re-Approval-Lücke. Microsofts Sicherheitsteam veröffentlichte eine direkte Warnung über einen Mechanismus, der ins Vertrauensmodell selbst eingebaut ist: Die Beschreibung eines Tools — der Text, den ein Nutzer liest und freigibt, bevor er einer KI die Nutzung erlaubt — kann sich nach dieser Freigabe ändern, und nichts im Protokoll verlangt, dass der Client erneut fragt. Microsofts eigene Worte: „In configurations where description changes do not trigger a re-approval workflow, the updated instructions become active without additional review.“ Ein Tool, das am ersten Tag sicher aussah, kann am dreißigsten Tag still neu definiert werden, und ein Nutzer, der es einmal freigegeben hat, hat keinen Grund zu wissen, dass es passiert ist. Microsoft beschrieb MCP als „the fastest-growing part of the agentic AI supply chain“ — genau deshalb zählt diese Lücke jeden Monat mehr, in dem sie unadressiert bleibt.

Neben diesen sind zwei konkrete CVEs wissenswert, wenn du MCP-Tooling evaluierst: CVE-2025-49596, eine kritische (CVSS 9,4) Remote-Code-Execution-Schwachstelle in Anthropics eigenem MCP Inspector-Tool, und CVE-2025-6514, eine kritische (CVSS 9,6) Command-Injection-Schwachstelle im weit verbreiteten mcp-remote-Paket, ausgelöst durch die Autorisierungs-URL eines bösartigen Servers. Beide sind gepatcht, aber beide zeigen, dass das Tooling um MCP dieselbe Klasse von Lücke wie das Vertrauensmodell des Protokolls hatte: Dinge, die ein Nutzer vernünftigerweise für inert hielt, erwiesen sich als nicht inert.

Was „Human-in-the-Loop“ in der Praxis bedeuten muss

Da das Protokoll es nicht erzwingen wird, sind die Fragen, die sich bei jedem KI-verbundenen Tool lohnen — einschließlich sSystms eigenem — die, die „Human-in-the-Loop“ von einem Slogan in etwas Prüfbares verwandeln:

1. Wartet eine Schreiboperation wirklich auf eine Person, jedes Mal, oder nur beim ersten Mal? Eine einmalige Freigabe beim Verbinden ist nicht dieselbe Garantie wie Freigabe pro Aktion.
2. Wenn sich die Beschreibung oder das Verhalten eines Tools ändert, löst das eine erneute Freigabe aus, oder tritt es still in Kraft? Das ist genau die Lücke, die Microsoft im Juni 2026 markierte.
3. Ist das Token oder die Anmeldedaten auf die Daten einer Organisation beschränkt, oder könnte eine kompromittierte Sitzung mandantenübergreifend reichen? Das ist bei Asana fehlgeschlagen — nicht der Freigabeschritt, sondern die Isolationsgrenze dahinter.
4. Gibt es einen Audit-Trail dessen, was die KI tatsächlich getan hat, getrennt von dem, wozu sie aufgefordert wurde? Zusammengesetzte Angriffe wie der GitHub-Fall zeigen sich nur im Nachhinein, wenn die einzelnen Schritte protokolliert wurden.
5. Wer steuert die Spezifikation, und wie aktiv entwickelt sich das Sicherheitsmodell? MCP wurde am 9. Dezember 2025 an die Agentic AI Foundation unter der Linux Foundation gespendet, mit Anthropic, Block, OpenAI, Google, Microsoft, AWS und Cloudflare als beteiligt genannt — ein Zeichen, dass das Ökosystem sich um gemeinsame Governance konsolidiert, statt dass jeder Anbieter unabhängig patcht.

sSystms eigener MCP-Endpunkt stellt ein pro-Nutzer-Token aus, das auf die Organisation dieses Nutzers beschränkt ist, und jede Schreiboperation, die eine KI vorschlägt — über die eingebaute Build AI oder einen verbundenen externen Client — liegt als ausstehende Aktion, bis eine Person sie freigibt. Das ist keine Behauptung, dass MCP das erzwingt; es ist der Gegensatz. Weil das Protokoll es nicht tut, muss es bewusst in die Anwendung eingebaut werden, und es lohnt sich, explizit danach zu prüfen, statt es aus „es nutzt MCP“ anzunehmen. Mehr dazu, wie die Freigabegrenze funktioniert, in wie KI und Menschen den sSystm-Arbeitsbereich teilen, wie das Isolationsmodell aussieht in unserer Sicherheitsarchitektur, und die Mechanik, externe KI über MCP anzubinden, in wie du deine KI mit deiner Agentur über MCP verbindest.