Anthropic stellte das Model Context Protocol (MCP) am 25. November 2024 vor, als „einen offenen Standard, der es Entwicklern ermöglicht, sichere, bidirektionale Verbindungen zwischen ihren Datenquellen und KI-gestützten Werkzeugen zu bauen“. In der Praxis lässt MCP einen KI-Assistenten lokale Programme aufrufen, sogenannte MCP-Server, die in seinem Namen Dateien lesen, Datenbanken abfragen oder das Web erreichen. Das ist wirklich nützlich, und es ist auch eine neue Art von Angriffsfläche: Das Modell entscheidet, welches Werkzeug es aufruft, anhand von Text, den es gelesen hat, und es kann Ihre Anweisungen nicht immer von denen jemand anderem unterscheiden.
Wie ein MCP-Server tatsächlich läuft
Die MCP-Spezifikation definiert zwei Transportarten. Über stdio „startet der Client den MCP-Server als Subprozess“, und beide sprechen über Standard-Ein- und -Ausgabe miteinander. Über Streamable HTTP (das den ursprünglichen HTTP+SSE-Transport aus der Spezifikation von November 2024 ersetzt hat) läuft der Server als eigener lokaler Prozess, und der Client sendet ihm HTTP-Anfragen, mit der Möglichkeit, im Gegenzug einen Strom von Server-Sent Events zu empfangen (MCP-Spezifikation, Transporte). So oder so läuft ein lokaler MCP-Server meist mit denselben Datei- und Netzwerkrechten wie die Person, die ihn gestartet hat, weil nichts im Protokoll etwas anderes verlangt.
Die Spezifikation selbst weist direkt auf das Risiko der HTTP-Variante hin: Sie verlangt von Servern, den Origin-Header zu validieren, empfiehlt bei lokalem Betrieb die Bindung an 127.0.0.1 statt 0.0.0.0, und fordert Authentifizierung bei jeder Verbindung, mit der Warnung, dass ohne diese Maßnahmen „Angreifer DNS-Rebinding nutzen könnten, um von entfernten Websites aus mit lokalen MCP-Servern zu interagieren“.
Der Mechanismus: ein confused deputy
Der klassische Name für diesen Fehlermodus ist das Confused-Deputy-Problem: „ein Computerprogramm, das von einem anderen Programm (mit weniger Privilegien oder Rechten) dazu gebracht wird, seine Autorität zu missbrauchen.“ Ein KI-Agent mit MCP-Werkzeugzugriff ist ein Stellvertreter mit echter Autorität — Ihre Dateien zu lesen, Netzwerkanfragen zu stellen —, der auf Anweisungen handelt, die aus Inhalten stammen können, die er nur zusammenfassen oder analysieren sollte. Enthält dieser Inhalt eigene Anweisungen, folgt der Agent möglicherweise diesen statt Ihren, oder zusätzlich zu ihnen. Das ist es, was OWASPs Risikokategorie der Top 10 für LLM-Anwendungen Prompt Injection und übermäßige Handlungsfreiheit nennt: OWASP: Top 10 für LLM-Anwendungen; OWASP LLM01:2025, Prompt Injection.
Ein gezeigter Fall: der GitHub-MCP-Server
Das ist nicht theoretisch. Am 26. Mai 2025 berichtete Invariant Labs über einen Machbarkeitsnachweis gegen den offiziellen GitHub-MCP-Server, der damals rund 14.000 GitHub-Stars hatte. Der Aufbau: Ein Agent mit Zugriff auf ein öffentliches und ein privates Repository wurde gebeten, offene Issues im öffentlichen zu prüfen. Ein präpariertes Issue im öffentlichen Repository trug versteckte Anweisungen; der Agent, der es im Rahmen seiner normalen Aufgabe las, folgte ihnen und gab in der Demonstration daraufhin Details aus dem privaten Repository preis, einschließlich Informationen, die die Forscher als persönlich beschreiben, im vom Angreifer kontrollierten Issue-Thread. Invariant Labs stellte ausdrücklich klar, dass dies ein gezeigter Machbarkeitsnachweis an Test-Repositorys war, kein in freier Wildbahn beobachteter Angriff, und dass „dies kein Fehler im Code des GitHub-MCP-Servers selbst ist, sondern ein grundlegendes architektonisches Problem, das auf Ebene des Agentensystems angegangen werden muss.“ Das in der Demonstration verwendete Modell war Claude 4 Opus.
Die tödliche Dreierkombination
Am 16. Juni 2025 benannte Simon Willison das Muster hinter Fällen wie diesem als „lethal trifecta“: ein Agent, der (1) Zugriff auf private Daten hat, (2) mit nicht vertrauenswürdigen Inhalten in Kontakt kommt, und (3) einen Weg zur externen Kommunikation besitzt. „Wenn Ihr Agent diese drei Eigenschaften kombiniert, kann ein Angreifer ihn leicht dazu bringen, auf Ihre privaten Daten zuzugreifen und sie an diesen Angreifer zu senden.“ Er nennt MCP ausdrücklich als Mitverursacher: „Das Problem am Model Context Protocol — MCP — ist, dass es Nutzer dazu ermutigt, Werkzeuge aus verschiedenen Quellen zu mischen, die unterschiedliche Dinge tun können“, wodurch es leicht passiert, dass alle drei Eigenschaften in einer Sitzung aktiv sind, ohne dass das bewusst entschieden wurde.
Warum das für Endpoint-Werkzeuge schwer zu erkennen ist
Aus Sicht des Betriebssystems geschah im GitHub-MCP-Fall nichts Ungewöhnliches: eine signierte, vertrauenswürdige Anwendung las etwas Text und stellte eine Netzwerkanfrage über einen lokalen Hilfsprozess, für dessen Nutzung sie konfiguriert war. Es gibt keine schädliche Binärdatei zu melden und keine ausgenutzte Speichersicherheitslücke. Die entscheidende Anfrage — die, die Daten hinausträgt — hat dieselbe Form wie jeder andere Werkzeugaufruf, den der Agent hundertmal am Tag korrekt macht.
Was das Risiko tatsächlich verringert
- Geben Sie jedem MCP-Server nur die engstmöglichen Werkzeuge und den Dateizugriff, den er braucht, statt breitem Dateisystem- oder Shell-Zugriff, damit ein gekaperter Werkzeugaufruf weniger anrichten kann.
- Behandeln Sie jeden Inhalt, den ein Agent außerhalb Ihrer Kontrolle liest (Issues, Webseiten, heruntergeladene Dateien), als nicht vertrauenswürdige Eingabe — dieselbe Disziplin, die Sie bei Nutzereingaben in jedem anderen System anwenden würden.
- Folgen Sie den Empfehlungen der MCP-Spezifikation selbst auf Transportebene: lokale Server an Localhost binden, Authentifizierung verlangen, den Origin-Header validieren.
- Beobachten oder kontrollieren Sie den einen Schritt, den jede Version dieses Angriffs teilt: die ausgehende Verbindung, die Daten zum Angreifer tragen würde. Dieser Schritt passiert, nachdem das Modell bereits getäuscht wurde, weshalb er die zuverlässigste Stelle ist, um ihn abzufangen.
Wo FireAI und HisnLabs ins Spiel kommen
The step an injected agent cannot skip is the outbound connection that carries your data out, which is exactly what a per-app firewall like FireAI is built to see and stop, whether the process asking to connect is a familiar app or an MCP server it has never seen before.
FireAI ist das eigene Produkt von HisnLabs: eine KI-Firewall für den Mac, die direkt auf dem Gerät läuft. Sie zeigt jede Verbindung Ihrer Apps in verständlicher Sprache und lässt Sie entscheiden, was Ihren Mac verlässt — die KI arbeitet lokal, Ihr Datenverkehr wird also nie an uns oder irgendjemand anderen gesendet. Das Sicherheitsforschungsteam von HisnLabs sorgt dafür, dass diese Entscheidungen verlässlich bleiben: Es katalogisiert, welche Domains gewöhnliche Telemetrie und welche ein echter Dienst sind, verfolgt Land und Netzwerk hinter einer Verbindung und trainiert das lokale Modell (die Autopilot-Funktion) mit echten Verkehrsmustern — ohne dass irgendetwas davon Ihren Mac verlässt.
Die technischen Entscheidungen dahinter können Sie nachlesen — oder FireAI 17 Tage lang ausprobieren — unter FireAI, von HisnLabs.