Am 7. April 2025 demonstrierte Invariant Labs einen funktionierenden Angriff auf den offiziellen WhatsApp-MCP-Server. Der Trick war kein Buffer-Overflow, kein Zero-Day im Server-Code, kein leakendes Secret. Die Forscher schickten einfach eine WhatsApp-Nachricht. Der MCP-Server las den Nachrichteninhalt, verarbeitete eingebettete Anweisungen wie legitime Tool-Calls und leitete sie an verbundene Tools weiter. Der Nutzer sah nichts davon. Das ist laut Invariant Labs Blog vom 7. April 2025 die erste öffentlich dokumentierte MCP-spezifische Exploit-Demonstration.
Wer das als Forschungs-Kuriosität abgetan hat, hatte zwei Monate Ruhe.
Asana hat den Beweis im Produktivbetrieb geliefert
Im Juni 2025 musste Asana seinen MCP-Server für 13 Tage offline nehmen. Ursache: eine fehlerhafte Scope-Validierung, durch die Workspace-Metadaten zwischen Tenants leaken konnten. Etwa 1.000 Enterprise-Kunden wurden benachrichtigt. Inhalte waren nicht betroffen, aber Projektstrukturen und Mitgliederlisten reichen für gezieltes Social Engineering vollständig aus. Wer weiß, dass dein Compliance-Team an einem Projekt namens “Vendor Audit Q3” arbeitet, schreibt eine glaubwürdigere Phishing-Mail als jemand, der nur deinen Firmennamen kennt.
Der Asana-Vorfall ist die unangenehme Antwort auf eine bequeme Frage. Die bequeme Frage lautet: Sind MCP-Sicherheitsprobleme ein theoretisches Risiko oder ein operatives? Asana hat geliefert. 13 Tage Downtime auf einem produktiv genutzten Enterprise-Tool, weil die Sicherheitsschicht nicht mit der Geschwindigkeit der Feature-Entwicklung mitgekommen ist.
Die meisten Unternehmen, die heute MCP-Integrationen aktivieren, haben weder die Forensik noch die Compliance-Reife, einen vergleichbaren Fall in 13 Tagen aufzuräumen.
Was Tool-Use im Klartext bedeutet
MCP ist nicht “noch eine API”. Eine MCP-Verbindung gibt einem Sprachmodell die Fähigkeit, in deinem Namen Aktionen auszuführen: Tickets schließen, Dateien lesen, Mails senden, Datenbankabfragen stellen. Genau die Operationen, für die deine IT-Sicherheit klassisch SSO, Audit-Trails und granulare Berechtigungen verlangt.
Bei klassischen APIs hast du diese Schichten. Eine SaaS-Integration läuft über OAuth, der Scope ist im Token kodiert, jeder Call hinterlässt eine Audit-Spur mit User, Zeitstempel und Action.
Bei MCP-Tool-Use im Mai 2026 fehlt dir typischerweise alles davon. Der Agent agiert mit den vollen Rechten des angemeldeten Nutzers. Die Audit-Spur endet beim Modell. Was das Modell danach an welches Tool weitergegeben hat, lebt im besten Fall in einem unstrukturierten Log auf dem MCP-Server selbst. Im schlechtesten Fall existiert sie nicht.
Das ist die Lücke, die Invariant Labs ausgenutzt hat. Das ist die Lücke, durch die bei Asana Daten gewandert sind.
Das ungelöste OBO-Problem
Der saubere Weg wäre RFC 8693 Token Exchange, der On-Behalf-Of-Flow, den Enterprise-Identitätsanbieter seit Jahren nutzen. Die Idee: Wenn der Nutzer Anna sich bei Claude anmeldet und Claude im Namen von Anna ein Asana-Tool aufruft, bekommt das Tool kein Token mit Annas vollen Rechten. Es bekommt ein delegiertes Token mit eingeschränktem Scope, kurzlebig, nur für diese eine Aktion.
Das MCP-Protokoll spezifiziert genau das bis heute nicht. IBM hat dieses Problem in seinem ContextForge-Projekt als Epic #3385 seit April 2026 öffentlich offen. Wenn der Enterprise-Anbieter mit dem stärksten Identity-Stack der Branche keine Lösung publiziert hat, hast du sie auch nicht.
Im Mai 2026 läuft jede produktiv geschaltete MCP-Integration mit dem vollen Berechtigungssatz des angemeldeten Nutzers. Wenn dein CFO im Claude-Chat eine Frage stellt, deren Beantwortung über MCP einen Lookup in deinem ERP auslöst, sieht der MCP-Server für den Bruchteil dieser Anfrage alles, was dein CFO sehen darf. Inklusive Daten, die mit der eigentlichen Anfrage nichts zu tun haben.
Die einzige saubere Antwort ist eine Schicht davor, die Scopes filtert, Calls auditiert und im Zweifel blockt. Diese Schicht heißt Gateway.
Was Enterprise jetzt einziehen muss
Drei Komponenten sind nicht verhandelbar, wenn MCP über die Sandbox hinaus gehen soll.
Erstens: SSO vor dem MCP-Server, nicht dahinter. Jeder MCP-Tool-Call muss authentifiziert sein, bevor er den Server überhaupt erreicht. Identity-Provider-Anbindung über OIDC oder SAML. Service-Accounts für Agenten haben eigene Identitäten mit eigenem Scope, nicht das Token des letzten menschlichen Nutzers, der zufällig in der Session war. Solange dein MCP-Server kein “wer hat das aufgerufen” ableitet, sondern es vom aufrufenden Client erfährt, ist er für Spoofing offen.
Zweitens: Audit-Trails auf Tool-Call-Ebene, nicht auf Session-Ebene. Jeder einzelne Tool-Call braucht ein Log-Event mit User-ID, Tool-Name, Parametern, Ergebnis-Hash und Zeitstempel. Strukturiert, in einer SIEM-anbindbaren Form. Das ist nicht nur Forensik-Hygiene. Das KRITIS-Dachgesetz ist seit dem 17. März 2026 in Kraft und schreibt Audit-Trails für kritische Automatisierungssysteme vor. Wer MCP für KRITIS-relevante Prozesse nutzt, fällt darunter, ob er es bemerkt hat oder nicht.
Drittens: ein dediziertes MCP-Gateway zwischen Modell und Tool-Server. Kong hat mit Gateway 3.12 vom 14. Oktober 2025 das erste kommerzielle API-Gateway veröffentlicht, das nativen MCP-Proxy, OAuth 2.0 Token Exchange, Rate Limiting und ein Audit-Log-Schema für Tool-Calls mitbringt. AWS zieht 2026 mit Bedrock AgentCore nach, einem managed MCP Gateway mit IAM-Integration. Wer heute baut, sollte auf einer dieser Schichten oder einer äquivalenten Eigenentwicklung aufsetzen, nicht direkt auf dem nackten MCP-Server.
Das ehrlichste Gegenargument
MCP ist ein offenes Protokoll. Jede Organisation kann eigene Sicherheitsschichten bauen. Stimmt technisch. Ist aber kein Argument, sondern das Problem.
“Kann bauen” heißt nicht “hat gebaut”. Das RFC-8693-Token-Exchange-Problem ist seit über einem Jahr offen, IBM ContextForge bekommt es seit April 2026 nicht zugemacht. Solange das Protokoll keine standardisierte OBO-Antwort hat, baut jedes Unternehmen seine eigene Halblösung oder, was wahrscheinlicher ist, gar keine. Genau in dieser Lücke leben Invariant-Labs-Demonstrationen und Asana-Vorfälle.
Wer auf das offene Protokoll wartet, deployt in der Zwischenzeit ohne Token-Chaining, ohne Gateway, ohne Audit-Tiefe. Das ist nicht “noch nicht produktionsreif”. Das ist “produktiv in einer Phase, in der die Forensik fehlt, um den ersten Vorfall sauber aufzuarbeiten”.
Wo die Verantwortung liegt
In den meisten Organisationen ist gerade nicht klar, wer für MCP-Sicherheit zuständig ist. Das Plattform-Team aktiviert Integrationen, weil ein Fachbereich gefragt hat. Das Security-Team sieht keine neuen API-Endpunkte, weil MCP-Calls über bestehende Tunnels laufen. Der CISO erfährt vom Deployment, wenn der erste Audit-Befund auf dem Tisch liegt.
Das ist die organisatorische Variante der gleichen Lücke. Die technische Lücke heißt fehlender OBO-Flow. Die organisatorische heißt fehlende Zuständigkeit. Beide schließen sich nicht von selbst.
Wer im Unternehmen MCP-Server betreibt, ohne dass Security ein Sign-off auf Authentifizierung, Audit und Gateway-Strategie gegeben hat, hat ein Compliance-Problem, bevor er ein Sicherheits-Problem hat. Im KRITIS-Kontext ist die Reihenfolge sogar umgekehrt: Das Compliance-Problem ist seit März 2026 da, das Sicherheits-Problem materialisiert sich beim ersten Vorfall.
Die nüchterne Lage
MCP wird bleiben. Das Protokoll löst ein reales Problem, hat eine wachsende Server-Basis und mit OpenAIs Migration auf MCP-Standard 2026 die Größenordnung erreicht, ab der man sich für oder gegen den Standard entscheidet, nicht mehr für oder gegen MCP. Die Frage ist nicht, ob du MCP einsetzt. Die Frage ist, ob deine Sicherheitsarchitektur in dem Moment steht, in dem du den ersten Server produktiv schaltest.
Bei den meisten Unternehmen steht sie nicht. Und der eigene Asana-Moment kommt früher, als das Plattform-Team denkt.
Wer früher als der Markt sieht, welche Standards-Bewegung als nächstes kippt, welche Sicherheitslücke als nächstes operativ wird und was das für die eigene Architektur bedeutet: Der KI-Syndikat Newsletter ordnet diese Verschiebungen einmal pro Woche ein, mit Quellen und ohne Schaumschlägerei.