Versteckte Bedrohung in MCP-Servern: eigene DLP-Schicht nötig

Achtzehn Monate von der Spezifikation zur Schatten-IT-Krise

Anthropic veröffentlichte die erste Model-Context-Protocol-Spezifikation im November 2024. Achtzehn Monate später ist MCP die Standardverrohrung zwischen Agenten und Werkzeugen in Claude Desktop, Cursor, Claude Code, Continue, Zed, Windsurf, dem Copilot-Agent-Panel und einer wachsenden Liste von Enterprise-IDE-Plugins. Der Community-Marktplatz mcp.so listet über zweitausend Server, die Notion, Linear, GitHub, Postgres, Snowflake, Stripe, Jira, S3, Kubernetes, interne Wikis und maßgeschneiderte Hersteller-APIs abdecken. Jeder dieser Server kann im Auftrag eines Modells Daten lesen.

Kaum einer sitzt hinter einem DLP-Sieb.

Browser-Erweiterungen fangen den ChatGPT-Tab. Desktop-Agenten fangen die Claude-Desktop-App. Keiner sieht, was über eine stdio-Pipe zwischen Claude Desktop und dem Postgres-MCP-Server fließt, den Sie letzte Woche installiert haben. Um diesen blinden Fleck geht es in diesem Beitrag.

Der MCP-Primer in 30 Sekunden

MCP ist ein JSON-RPC-2.0-Protokoll mit zwei Transporten: stdio (der Modell-Host startet den Server als Subprozess und kommuniziert über Standard-Ein/Ausgabe) und SSE (Server-Sent Events über HTTPS, für entfernte Server). Claude Desktop, Cursor und die meisten lokalen IDE-Integrationen nutzen stdio per Standard. Enterprise-Deployments beginnen, SSE hinter einem internen Gateway einzusetzen.

Das Vokabular ist klein. Nach dem initialize-Handshake sehen Sie hauptsächlich vier Methoden.

• tools/list — der Server gibt die angebotenen Werkzeuge und das JSON-Schema jedes Arguments bekannt.
• tools/call — das Modell ruft ein Werkzeug mit Argumenten auf und der Server liefert ein strukturiertes Ergebnis zurück.
• resources/list und resources/read — der Server stellt adressierbare Inhalte bereit (eine Datei, eine Datenbankzeile, eine Confluence-Seite), die das Modell in seinen Kontext ziehen kann.
• resources/subscribe — das Modell bittet um Benachrichtigung, wenn sich eine Ressource ändert; jedes Update fließt in den nächsten Turn.

Das ist im Wesentlichen die Leitung. Einfach, gut spezifiziert, leicht zu parsen — genau deshalb ist eine eigene DLP-Schicht überhaupt machbar.

Vier Stellen, an denen in einem MCP-Austausch sensible Daten lecken

Jeder Leckpfad, den Sie schon aus Browser-Chats fürchten, existiert auch in MCP, plus zwei neue, die der Host erzeugt, ohne dass jemand eine Taste drückt.

1. Werkzeug-Eingaben

Wenn ein Nutzer schreibt „fasse den letzten HubSpot-Deal für Acme zusammen“, baut der Agent ein tools/call mit dem wörtlichen Firmennamen, der Deal-ID und oft der E-Mail oder dem Sitzungstoken des Nutzers als Argumente. Diese Argumente sind in jeder Hinsicht außer der Optik nutzergelieferter Inhalt. Ein Jailbreak-Prompt, der die Steuernummer eines Kunden in das query-Argument eines Postgres-Werkzeugs schmuggelt, ist funktional identisch damit, dieselbe Nummer in ChatGPT zu tippen.

2. Werkzeug-Ausgaben

Das ist die neue Fläche, und sie wird von den meisten Teams unterschätzt. Ein resources/read auf eine Confluence-Seite gibt alles zurück, was auf dieser Seite steht — inklusive des api_key, den vor drei Jahren jemand in einen Runbook eingefügt hat. Ein SQL-Werkzeug liefert Zeilen mit E-Mails, IBANs, Steuer-IDs, als Data-URI kodierten Passscans. Das Modell nimmt diese Ausgabe, fasst sie zusammen, und die Zusammenfassung wandert über das Netz zu Anthropic, OpenAI, Google oder Mistral. Der Nutzer hat nichts davon getippt.

3. Ressourcen-Abonnements

Ein IDE-Agent, der für Hot-Reload während einer Debug-Sitzung file:///home/dev/secrets.env abonniert hat, streamt jedes Speicher-Ereignis in den Modellkontext. Langlebige Abonnements sind besonders gefährlich, weil sie die Datenbewegung von der Aufmerksamkeit des Nutzers entkoppeln — niemand schaut um 02:14 Uhr auf das Gespräch, wenn die Geheimnisdatei rotiert.

4. Akkumulierter Host-Kontext

Der Host (Claude Desktop, Cursor) ist dafür zuständig, den an das Modell gehenden Prompt zusammenzustellen. Er faltet vorherige Werkzeug-Ausgaben, Ressourcen-Snapshots und Konversationshistorie hinein. Über eine lange Sitzung sammelt dieses Kontextfenster leise eine Scheibe jedes Systems, das der Nutzer berührt hat. Die meisten Hosts schicken diesen kompletten Kontext mit jedem Turn mit. Wer nur den getippten Prompt inspiziert, übersieht 90 % dessen, was tatsächlich über die Leitung geht.

Warum generisches DLP all das verfehlt

Drei Gründe, alle strukturell.

Kein HTTP-Abfangpunkt. Browser-DLP setzt darauf, fetch im Seitenkontext zu haken. Ein stdio-MCP-Server hat keine Seite, keinen Browser, kein fetch. Die Bytes wandern durch eine anonyme Pipe zwischen zwei Prozessen, die das Betriebssystem als Geschwister behandelt. Web-Proxy-DLP, CASB, SWG — keines sieht das Gespräch.

SSE-Verkehr sieht nicht wie Chat aus. Auch wenn MCP über HTTPS läuft, ist die Rahmung text/event-stream mit JSON-RPC-Hüllen, nicht die Chat-Completion-Formen, für die DLP-Hersteller Signatur-Bibliotheken gebaut haben. Generische Inhaltsinspektion behandelt den Stream als opake Telemetrie.

Die sensible Nutzlast kommt vom Server. Klassisches DLP ist ausgehend: Es überwacht, was der Nutzer sendet. MCP dreht die Bedrohung um. Der hochriskante Inhalt ist die Antwort des Werkzeugs, die im Modellkontext landet und beim nächsten LLM-Aufruf das Gerät verlässt. Wenn sie die Netzgrenze überquert, ist sie bereits durch eine Modellzusammenfassung gewaschen und passt vielleicht auf kein literales Muster mehr.

Was eine MCP-bewusste DLP-Schicht tatsächlich tut

Die Komponente ist klein. Sie sitzt zwischen dem Host-Prozess und dem MCP-Server und macht vier Dinge.

1. JSON-RPC-Hüllen parsen. tools/call-Requests, tools/call-Responses, resources/read-Responses und Abonnement-Benachrichtigungen erkennen. Alles andere mit vernachlässigbarem Overhead durchlassen.
2. Dieselbe Fundtyp-Erkennung anwenden wie überall sonst. Die Detektoren für api_key, password, jwt, private_key, credit_card, IBAN, email, phone, deutsche Steuer-ID, französische NIR, passport, connection_string und Quellcode sind dieselben, die auch die Browser-Erweiterung nutzt. Keine zweite Taxonomie zu pflegen.
3. Pro Fundtyp handeln. Monitor, Anonymize mit formaterhaltender Maskierung oder Block — die Richtlinienmatrix ist mit der Browser- und Desktop-Matrix identisch. Ein SOC-Analyst, der die Operator Console kennt, versteht MCP-Vorfälle ohne Nachschulung.
4. Dieselbe Vorfall-Hülle emittieren. Jede Erkennung wird ein Vorfall mit derselben Form, demselben Schweregradmodell, derselben Webhook-Nutzlast nach Slack, Splunk HEC oder Microsoft Sentinel. Ermittler bleiben in einem Werkzeug.

Ein 40-zeiliger Python-Wrapper, der in beide Richtungen scannt

Konkret sieht ein stdio-Wrapper so aus. Er startet den echten MCP-Server als Subprozess und schickt jede Nachricht durch einen Inhalts-Scanner, bevor er sie weiterreicht.

import asyncio, json, sys
from zeuslock_mcp import Scanner, Policy

scanner = Scanner(policy=Policy.from_file("policy.yaml"))

async def pipe(reader, writer, direction):
    while True:
        line = await reader.readline()
        if not line:
            break
        try:
            msg = json.loads(line)
        except json.JSONDecodeError:
            writer.write(line); await writer.drain(); continue
        verdict = scanner.inspect(msg, direction=direction)
        if verdict.action == "block":
            err = {"jsonrpc": "2.0", "id": msg.get("id"),
                   "error": {"code": -32001, "message": verdict.reason}}
            writer.write((json.dumps(err) + "\n").encode())
            await writer.drain(); continue
        writer.write((json.dumps(verdict.payload) + "\n").encode())
        await writer.drain()

async def main(cmd):
    proc = await asyncio.create_subprocess_exec(
        *cmd, stdin=asyncio.subprocess.PIPE,
        stdout=asyncio.subprocess.PIPE)
    loop = asyncio.get_event_loop()
    stdin_reader = asyncio.StreamReader()
    await loop.connect_read_pipe(
        lambda: asyncio.StreamReaderProtocol(stdin_reader), sys.stdin)
    stdout_writer = sys.stdout.buffer
    await asyncio.gather(
        pipe(stdin_reader, proc.stdin, direction="to_server"),
        pipe(proc.stdout, stdout_writer, direction="to_host"))

asyncio.run(main(sys.argv[1:]))

Der Nutzer richtet Claude Desktop auf zeuslock-mcp postgres-mcp-server --dsn ... statt postgres-mcp-server --dsn .... Gleiche UX, volle Sichtbarkeit, Maskier- oder Blockentscheidungen werden getroffen, bevor die Bytes die lokale Maschine verlassen.

Das Lieferkettenproblem, über das noch niemand spricht

Der Community-MCP-Marktplatz hat dieselben Eigenschaften wie npm 2015 und der VS-Code-Marketplace 2019: geringe Veröffentlichungshürde, keine Signaturpflicht, keine Provenienz, Installationsanweisungen, die das Binary eines Fremden ins Home-Verzeichnis kopieren. Ein bösartiger MCP-Server kann alles, was ein normaler Server kann — Dateien lesen, Abfragen ausführen, APIs ansprechen — plus das Kontextfenster des Modells über einen Seitenkanal-Werkzeugaufruf still exfiltrieren.

BfDI, BSI und ENISA haben noch keine MCP-spezifische Handreichung veröffentlicht. Sie werden. Behandeln Sie bis dahin jeden MCP-Drittserver wie eine nicht signierte Browser-Erweiterung oder ein anonymes VS-Code-Plugin: ein Stück Code, das mit Ihren Rechten läuft und sieht, was Ihr Agent sieht.

Verteidigungs-Checkliste für die nächsten 90 Tage

1. Inventar. Fragen Sie jeden Entwickler, welche MCP-Server in seinem Claude Desktop, Cursor und Claude Code konfiguriert sind. Die Liste wird Sie überraschen.
2. Prüfen. Identifizieren Sie für jeden Server den Herausgeber, lesen Sie den Quellcode soweit verfügbar und pinnen Sie die Version. Blockieren Sie standardmäßig die Installation unsignierter Server aus dem Marktplatz.
3. Wrappen. Setzen Sie einen MCP-bewussten DLP-Scanner zwischen den Host und jeden Server. Scannen Sie in beide Richtungen. Beginnen Sie zwei Wochen im Monitor-Modus, um die Baseline zu lernen.
4. Werkzeugaufrufe per Rolle allowlisten. Entwickler brauchen vielleicht filesystem/write; die Finanzabteilung nicht. Der Werkzeugname ist genau die Richtlinien-Primitive, die Sie wollen.
5. Ressourcenausgaben inspizieren. Ein Scan, der nur tools/call-Argumente betrachtet und resources/read-Antworten ignoriert, verfehlt die größte Leck-Kategorie.
6. Jeden tools/call für Audit loggen. Werkzeugname, Argument-Hash, Ergebnisgröße, erkannte Fundtypen, getroffene Aktion. Senden Sie das per HMAC-signiertem Webhook an Ihr SIEM.
7. Decken Sie auch entfernte SSE-Server ab. Wenn Sie einen entfernten MCP-Server über HTTPS zulassen, terminieren Sie den SSE-Stream an einem Gateway unter Ihrer Kontrolle und betreiben Sie dort denselben Scanner.
8. Mappen Sie die Kontrollen auf Ihre Rahmenwerke. MCP-Scanning passt in NIS2-Risikomanagement, DORA-IKT-Drittparteirisiko und Artikel-15-Protokollierungspflichten der KI-Verordnung. Dokumentieren Sie das Mapping jetzt, damit das Audit Sie nicht unvorbereitet erwischt.

Warum das 2026 zählt, nicht 2028

MCP ist die nächste „E-Mail-Anhang“-Bedrohungsfläche für KI-Agenten. E-Mail-Anhänge brauchten ein Jahrzehnt und mehrere Schlagzeilen-Vorfälle — ILOVEYOU, der Slammer-Wurm, Locky — bevor Unternehmen ernsthafte Inspektion davorgestellt haben. Diesmal haben wir kein Jahrzehnt. Agentische IDEs greifen schon auf Produktionsdatenbanken zu, im Auftrag jedes Entwicklers, der den falschen Server aus einer Marktplatz-Kachel installiert hat.

Die Organisationen, die die nächsten achtzehn Monate gewinnen, sind diejenigen, die MCP als erstklassige DLP-Fläche behandelt haben, bevor der erste große Vorfall in die Schlagzeilen kommt. Wrappen Sie Ihre Server. Scannen Sie in beide Richtungen. Loggen Sie alles. Das Muster ist gut verstanden; die einzige Frage ist, ob Sie es vor oder nach dem Post-Mortem ausrollen.

Wenn Sie die produktionsreife Version des obigen Wrappers wollen: Die Zeuslock-MCP-Integration ist auf zeuslock.ai/docs dokumentiert, und eine Demo können Sie von derselben Seite anfordern.