MCP absichern: das Risiko, das ihr anbindet

Ihr hängt Claude an euer GitHub, dazu Gmail, Slack und die Datenbank. Ein paar Klicks, und der Agent kann Tickets lesen, Code reviewen und die Zusammenfassung ins Team posten. Genau das ist der Sinn von MCP: ein Stecker, der überall passt. Nur öffnet jeder dieser Stecker auch eine Tür, und die Türen kennen sich untereinander nicht.

Der Grundlagenartikel erklärt, wie MCP technisch funktioniert. Hier geht es um die andere Seite: Was passiert eigentlich, wenn ihr eurem Agenten Zugriff auf echte Dienste gebt, und warum das mehr Risiko ist als die Summe der einzelnen Anbindungen.

Das Grundmuster: die tödliche Dreifaltigkeit

Der Sicherheitsforscher Simon Willison hat für das Kernproblem einen Begriff geprägt, der sich durchgesetzt hat: die tödliche Dreifaltigkeit, im Original "lethal trifecta". Drei Fähigkeiten, die einzeln harmlos sind und zusammen gefährlich werden.

flowchart TB
  A["Zugriff auf<br/>private Daten"] --> D{"Alle drei<br/>in einer Session?"}
  B["Verarbeitet<br/>fremde Inhalte"] --> D
  C["Kanal<br/>nach außen"] --> D
  D --> E["Prompt Injection wird zur<br/>automatischen Datenabfluss-Pipeline"]
  class D decision
  class E abort

Ein Agent, der eure privaten Daten sieht (Punkt 1), dabei fremde Inhalte verarbeitet (Punkt 2, etwa eine E-Mail, ein Issue, eine Webseite) und irgendwie nach außen kommunizieren kann (Punkt 3), lässt sich über eine versteckte Anweisung im fremden Inhalt umlenken. Er nutzt dann seine legitimen Rechte, um eure Daten dorthin zu schicken, wo der Angreifer sie abgreift. Das ist keine Lücke im Code, sondern eine Eigenschaft der Kombination. Und MCP macht diese Kombination zum Normalfall, weil es dazu einlädt, Tools aus verschiedenen Quellen zu mischen.

Ein realer Fall: das GitHub-MCP-Leck

Wie konkret das wird, hat Invariant Labs im Mai 2025 am offiziellen GitHub-MCP-Server gezeigt. Der Ablauf:

flowchart TB
  A["Angreifer stellt bösartiges<br/>Issue in ein öffentliches Repo"] --> B["Opfer: 'Arbeite meine<br/>offenen Issues ab'"]
  B --> C["Agent liest die versteckte<br/>Anweisung im Issue"]
  C --> D["Agent zieht Daten aus<br/>privaten Repos in den Kontext"]
  D --> E["Agent öffnet öffentlichen PR<br/>mit den privaten Daten"]
  class E abort

Herausgekommen sind unter anderem Namen privater Repos, Umzugspläne und Gehaltsdaten des Nutzers, alles öffentlich lesbar im automatisch erzeugten Pull Request. Zwei Dinge sind daran wichtig. Erstens war das kein Bug im MCP-Server, sondern die tödliche Dreifaltigkeit in Reinform: private Daten, fremder Inhalt, Kanal nach außen. Zweitens funktionierte der Angriff über verschiedene Modelle und Clients hinweg. Auch ein gut ausgerichtetes Modell wie Claude Opus fällt darauf herein, weil es die versteckte Anweisung nicht von einer echten Aufgabe unterscheiden kann. Es gibt dafür keinen einfachen Patch.

Wenn der Server selbst der Angreifer ist

Beim GitHub-Fall kam die Anweisung von außen. Es geht aber auch direkter: Der MCP-Server, den ihr einbindet, kann selbst bösartig sein. Invariant Labs hat dafür drei Angriffsklassen beschrieben, die inzwischen Standardvokabular sind.

Der gemeinsame Nenner: Ein MCP-Client lädt oft mehrere Server in denselben Kontext. Ein einziger schlechter Server unter fünf guten reicht, um die anderen zu kapern. In einer Demo genügte ein präparierter Server, um über ein vertrauenswürdiges E-Mail-Tool alle ausgehenden Mails still an den Angreifer zu kopieren.

Connectors bewegen sich, während ihr wegschaut

Selbst wenn ein Server heute sauber ist, bleibt er es nicht zwangsläufig. Die Sicherheitsfirma PromptArmor hat kommerzielle Connectors über sechs Wochen beobachtet, The Register hat darüber berichtet. Von 2.517 Connectors änderten sich in dieser Zeit 931, also gut ein Drittel. Dabei kamen 1.686 neue Tools dazu und 1.127 Tool-Beschreibungen wurden umgeschrieben, meist ohne dass jemand die Freigabe erneut geprüft hätte.

Ein Beispiel aus dem Bericht zeigt die Richtung. Der Dropbox-Connector wuchs im Beobachtungszeitraum so:

Ihr habt also einen Connector mit acht harmlosen Lese-Tools freigegeben und betreibt sechs Wochen später einen mit vier Tools, die Daten löschen können. Dazu kommt ein zweiter Effekt: Laut der Analyse rufen zwei von fünf Connectors ihrerseits weitere KI-Dienste auf. Wenn euer Agent etwa Zooms Connector nutzt und dabei eine Anfrage mit sensiblen Daten übergibt, kann Zooms KI diese Daten an eigene Subdienstleister weiterreichen. Für DACH-Teams ist das direkt ein DSGVO-Thema: Die Daten verlassen eure Kontrolle und oft auch die Rechtsordnung, in der ihr sie glaubtet.

Was wirklich hilft

Die schlechte Nachricht zuerst: Gegen Prompt Injection gibt es kein Tool, das die Lücke schließt. Die gute: Ihr müsst die tödliche Dreifaltigkeit nur auseinanderhalten und den Schaden begrenzen. Sieben Hebel, grob nach Wirkung sortiert:

• Die Trifecta trennen. Gebt einem Agenten nicht gleichzeitig Zugriff auf private Daten, fremde Inhalte und einen Kanal nach außen. Wer öffentliche Issues verarbeitet, sollte in derselben Session keinen Schreibzugriff auf private Repos haben. Zwei getrennte, enger geschnittene Agenten sind sicherer als einer, der alles kann.
• Least Privilege, ernst gemeint. Startet mit Read-Only. Schreib- und erst recht Löschrechte nur, wo eine Aufgabe sie wirklich braucht. Prüft bei jedem Connector, welche Tools er tatsächlich mitbringt, nicht nur, was sein Name verspricht.
• Destruktive Aktionen brauchen einen Menschen. Löschen, Pushen, Mails senden, Geld bewegen: Solche Schritte gehören hinter eine explizite Freigabe, nicht in den Autopilot.
• Server festnageln und wiederholt prüfen. Gegen Rug Pulls hilft nur, Versionen zu pinnen und Änderungen an Tools und Beschreibungen aktiv zu beobachten, statt einmal beim Einrichten zu vertrauen. Bevorzugt Server von bekannten Herausgebern.
• Ausgehenden Verkehr begrenzen. Ein Agent, der nur mit den Diensten sprechen darf, die er braucht, kann Daten schlechter irgendwohin abfließen lassen. Egress-Kontrolle ist wirksamer als jede Allowlist im Prompt.
• Identität statt Sammel-Account. Der Agent sollte mit den Rechten der Person laufen, die ihn nutzt, nicht mit einem Service-Account, der an alles kommt. Das begrenzt den Schaden auf das, was diese eine Person ohnehin darf. Wie große Plattformen das umsetzen, steht im Artikel zum Context Layer.
• Alles protokollieren. Wenn etwas schiefgeht, müsst ihr rekonstruieren können, welches Tool wann mit welcher Berechtigung was getan hat. Ohne Audit-Log ist ein autonomer Agent eine Blackbox.

Für die Authentifizierung gilt OAuth 2.1 mit kurzlebigen Tokens und rollenbasiertem Zugriff als Stand der Technik, Microsoft hat die MCP-Risiken und passenden Gegenmaßnahmen ausführlich dokumentiert. Für den produktiven Einsatz ist das Pflicht, nicht Kür. Wie so eine Absicherung an lauffähigem Code aussieht, zeigt unser Praxis-How-to MCP-Server absichern: OAuth mit Spring AI.

Fazit

MCP ist zu Recht erfolgreich, weil es Integration billig macht. Das ist zugleich die Falle: Jede billige Anbindung vergrößert den Radius, in dem ein einziger manipulierter Inhalt Schaden anrichten kann. Die tödliche Dreifaltigkeit ist der Kompass dafür. Wer private Daten, fremde Inhalte und einen Kanal nach außen bewusst auseinanderhält, dem Agenten nur die nötigen Rechte gibt und seine Server im Blick behält, senkt das Risiko von einem offenen Scheunentor auf eine Tür mit Schloss. Ganz abschließen lässt sie sich nicht, aber man entscheidet, wer durchkommt.