Das „S“ in MCP steht für Sicherheit

• MCP ist ein Standardprotokoll, das LLMs mit Tools verbindet, aber standardmäßig nicht abgesichert ist
• Es gibt verschiedene Sicherheitslücken wie Command Injection, Tool Poisoning und Manipulation von Definitionen
• MCP verfügt weder über Authentifizierung, Verschlüsselung noch Integritätsprüfung und ist daher strukturell schwer vertrauenswürdig
• Mit Tools wie ScanMCP sind Sichtbarkeit und Kontrolle derzeit die beste Gegenmaßnahme

Was ist MCP und warum ist es wichtig

• MCP steht für Model Context Protocol und ist ein neuer Standard dafür, wie LLMs wie Claude, GPT und Cursor mit Tools und Daten integriert werden
• Es bietet eine standardisierte Verbindungsweise, die so weit geht, dass es als „USB-C für AI-Agenten“ bezeichnet wird
• Über MCP können AI-Agenten unter anderem Folgendes tun
  • sich über standardisierte APIs mit Tools verbinden
  • den Sitzungsstatus beibehalten
  • Befehle ausführen (unter Umständen übermäßig frei)
  • Kontext über verschiedene Workflows hinweg teilen
• Allerdings ist Sicherheit nicht standardmäßig eingebaut
• Es besteht das Risiko, dass Side Channels geöffnet werden, über die Systeme ohne Wissen des Nutzers erreicht werden können

Wichtige Sicherheitslücken in MCP

• Schwachstelle durch Command Injection (Equixly Research)

  • Auch im Jahr 2025 kommt es noch zu Remote Code Execution (RCE) durch Command Injection
  • Laut Untersuchungen von Equixly verwenden mehr als 43 % aller MCP-Server-Implementierungen unsichere Shell-Aufrufe
  • Angreifer können Shell-Befehle in Tool-Eingaben einbetten und über einen vertrauenswürdigen Agenten Remote Code ausführen

• Tool Poisoning (Invariant Labs)

  • Dabei versteckt ein Angreifer bösartige Anweisungen in der Tool-Beschreibung
  • Für den Nutzer bleibt das unsichtbar, aber die AI erkennt und befolgt es direkt
  • Ein Tool, das wie eine einfache mathematische Operation aussieht, kann in Wirklichkeit SSH-Schlüssel oder sensible Konfigurationsdateien auf dem System des Nutzers lesen

• Stille Neudefinition von Tools (Rug Pull)

  • Ein Tool kann seine eigene Definition nach der Installation verändern
  • Ein Tool, das an Tag 1 unauffällig ist, kann an Tag 7 in ein Werkzeug zum Sammeln von API-Schlüsseln umgewandelt sein
  • Das ist eine neue Form von Supply-Chain-Sicherheitsproblemen, die innerhalb von LLMs entsteht

• Tool-Shadowing über Server hinweg

  • Wenn mehrere MCP-Server mit einem Agenten verbunden sind, kann ein bösartiger Server Aufrufe eines vertrauenswürdigen Servers abfangen oder überschreiben
  • Dadurch können unter anderem folgende Probleme entstehen
    • E-Mails werden an Angreifer versendet, obwohl es so aussieht, als gingen sie an den Nutzer
    • versteckte Logik wird in Tools eingeschleust
    • codierte Daten werden exfiltriert

Warum MCP noch nicht sicher ist

• MCP priorisiert Folgendes
  • ✅ einfache Integration
  • ✅ einheitliche Schnittstelle
• Es fehlt jedoch an Folgendem
  • ❌ kein Authentifizierungsstandard
  • ❌ keine Kontextverschlüsselung
  • ❌ keine Verifikation der Tool-Integrität
• Nutzer können nicht wissen, auf Basis welcher tatsächlichen Beschreibung der Agent ein Tool verwendet

Sicherheitsmaßnahmen für Entwickler und Plattformbetreiber

• Entwickler

  • Eingabevalidierung ist Pflicht
  • Versionen von MCP-Servern und Tools fixieren (Pinning)
  • sensible Informationen aus Tool-Beschreibungen entfernen

• Plattformbetreiber

  • vollständige Tool-Metadaten für Nutzer sichtbar machen
  • Integritäts-Hashes bei Server-Updates verwenden
  • Sitzungsabsicherung verbindlich machen

• Nutzer

  • keine Verbindung zu nicht vertrauenswürdigen MCP-Servern herstellen
  • Sitzungslogs wie in einer Produktionsumgebung überwachen
  • verdächtige Tool-Updates beobachten

Der Vorschlag hinter ScanMCP.com

• ScanMCP wird als Scanner und Dashboard vorgeschlagen, das Folgendes leistet
  • verbundene MCP-Tools auditieren
  • Risiken wie RCE, Tool Poisoning und Sitzungslecks erkennen
  • visualisieren, welche Informationen der Nutzer sieht und welche der Agent tatsächlich wahrnimmt
• Nützlich sein könnte das für
  • Security-Teams von Agentenplattformen
  • AI-Infrastruktur-Startups
  • unabhängige Entwickler, die vertrauenswürdige Tools bauen wollen

Abschließende Gedanken

MCP ist ein leistungsfähiges Protokoll, wird aber zu schnell eingeführt, obwohl seine API-Sicherheitsreife noch unzureichend ist
Bis ein Secure-by-default-Ansatz eingeführt wird, sind Tools wie ScanMCP.com der beste Weg, um Sichtbarkeit und Kontrolle zu gewinnen

• Fazit: Das „S“ in MCP steht nicht für Security. Aber es sollte so sein

[GN⁺]

Hacker-News-Kommentare

• Dieser Beitrag hebt die Angriffsszenarien hervor und zitiert sie, die in der Sicherheitsnotiz beschrieben wurden, die Invariant Labs vor ein paar Tagen veröffentlicht hat (Tool Poisoning, Shadowing, MCP Rug Pull). Ich bin der Autor des entsprechenden Blogbeitrags

  • Anders als viele vermuten, liegt das Sicherheitsproblem bei MCP-artigen LLM-Tool-Calls nicht darin, verschiedene MCP-Server-Implementierungen voneinander zu isolieren
  • Lokal ausgeführte MCP-Server-Implementierungen sollten vom Paketmanager verifiziert werden, der für die Installation verwendet wird (Remote-MCP-Server sind tatsächlich noch schwerer zu verifizieren)
  • Das Problem ist eine besondere Form indirekter Prompt Injection, die auftritt, wenn MCP in Agentensystemen verwendet wird
  • Da der Agent im selben Kontext die Spezifikationen aller installierten MCP-Server enthält, kann ein nicht vertrauenswürdiger MCP-Server das Verhalten anderer MCP-Server leicht manipulieren (zum Beispiel eines Servers mit Zugriff auf eine sensible Datenbank). Das nennen wir Tool Shadowing
  • Außerdem können MCP-Server aufgrund der dynamischen Natur von MCP den Satz der angebotenen Tools nur für bestimmte Benutzer ändern. Das bedeutet, dass ein MCP-Server jederzeit bösartig werden kann
  • Die aktuellen MCP-Clients Claude und Cursor weisen nicht auf solche Änderungen hin, wodurch Agent und Benutzer angreifbar werden
  • Wer mehr Interesse hat, sollte sich den ausführlicheren Blogbeitrag unter [1] ansehen. Wir forschen schon lange zu Agentensicherheit und arbeiten bei Invariant daran
  • Wir haben außerdem Code-Snippets veröffentlicht, mit denen jeder experimentieren kann, darunter ein Tool-Poisoning-Angriff auf einen populären WhatsApp-MCP-Server [2]

• Diese Angriffe sind größtenteils nur ein weiteres Beispiel dafür, dass man auf der falschen Seite der Airlock steht. Sie überschreiten keine Berechtigungsgrenzen, sondern erledigen auf seltsame Weise nur Dinge, die ohnehin schon möglich waren

  • MCP-Server führen Code auf Benutzerebene aus, man muss also keine KI austricksen, damit sie SSH-Schlüssel liest. Man kann die Schlüssel einfach selbst lesen
  • Der Rest ist im Grunde dieselbe Kritik, die man auch an anderen Developer-Tools/Ökosystemen richten könnte (NPM oder VS Code Extensions)

• Die Herausforderung ist, sich ein besseres Design vorzustellen, das:

  • 1. angemessene Sicherheitsstandards hat, sodass Leute keine Artikel mit dem Titel "Das S steht für Sicherheit" schreiben
  • 2. Programmen denselben Funktionsumfang ermöglicht, den die derzeit nützlichsten MCPs bieten, ohne automatische Funktionen in solche umzuwandeln, die eine manuelle Bestätigung durch den Benutzer erfordern, und ohne generell den Zweck der ganzen Idee zu unterlaufen
  • 3. nicht alles in einem proprietären Marketplace mit Unternehmens-Gatekeepern einsperrt
  • Ich würde gern Vorschläge sehen, denn bisher habe ich nur allgemeines und unspezifisches "MCP ist nicht sicher!!!111" gesehen. Es ist besonders schwierig, wenn Leute vergessen, dass Sicherheit und Nützlichkeit gegensätzliche Kräfte sind

• Guter Artikel, aber ich frage mich, ob das alles KI-generiert ist

  • Das Profilbild sieht aus, als wäre es mit StableDiffusion erzeugt worden, der Account wurde heute erstellt, und es gibt keine früheren Artikel
  • Ich konnte außerdem keine weiteren Hinweise auf Elena Cross finden

• Das O steht für Observability. Ich war diese Woche tief damit beschäftigt, MCP-Server zu erkunden und zu schreiben

  • Den meisten Implementierungen, einschließlich meiner Spielzeugimplementierung, fehlen Audit-Funktionen oder Metriken. Claude speichert zwar die Log-Ausgabe von MCP-Servern, aber das ist für Debugging gedacht, nicht für DevOps/SecOps
  • Kulturell gesehen ist das von OP beschriebene Problem ein großes Problem für eher wenig technikaffine Menschen. In dem dazugehörigen Subreddit haben Leute großen Spaß daran, MCP-CLI-Programme auf ihren eigenen Rechnern auszuführen
  • Die Sicherheitskommentare von OP sind für Entwickler offensichtlich, aber solche Nutzer haben kein Gefühl dafür, wie riskant das ist
  • Die Leute lernen gerade Docker kennen, und Claude nimmt dessen Verwendung in Beispiele auf. Aber die meisten laden einfach irgendwelche Blobs herunter und führen sie aus. Leute schreiben MCP-Server blind und starten sie einfach
  • Je weiter sich MCP verbreitet, desto mehr werden Frameworks und Tools wachsen, um Sicherheit, Observability usw. zu unterstützen. Das ist wie der Aufbau des Webs Mitte der 90er
  • Hat nichts mit OP zu tun, aber während ich das gebaut habe, war es extrem faszinierend, etwas in Claude Desktop einzugeben und dann in VSCode einen Breakpoint auszulösen

• Genau. Das war auch mein Gedanke, obwohl ich bei der Veröffentlichung der Notiz nicht so tief eingestiegen bin

• Selbst wenn die verwendete Software nicht bösartig und sicher implementiert ist: Wie kann man sicherstellen, dass sie auf die gewünschte Weise verwendet wird?

  • Angenommen, es gibt einen MCP-Server, der das lokale Dateisystem ändern kann, und einen MCP-Server, der Objekte in einem Cloud-Speicher ändern kann. Wie kann der Benutzer sicherstellen, dass der LLM-Agent die richtige Wahl trifft?
  • Man möchte nicht zu viele Optionen anbieten und auch nicht jede Aktion überwachen müssen, aber genau das könnte sonst zu noch mehr Problemen führen

• Mehr als 43 % der von Equixly getesteten MCP-Server-Implementierungen hatten unsichere Shell-Aufrufe

  • Wie kann man jedes Mal wieder in dieselbe Falle tappen

• Ich frage mich, was MCP überhaupt ist. Ich habe mehrmals versucht, die Dokumentation zu lesen, aber ich konnte nicht verstehen, welches Problem es löst. Vor allem: Was ist an KI-Agenten so besonders, das nicht auch für deterministische Agenten gilt, die es seit Jahrzehnten gibt?

• Ich hatte angenommen, der ganze Zweck von MCP sei, dass Anthropic Prompts und Ausgaben belauschen und die Trainingsdaten maximieren kann. Erst jetzt habe ich gelernt, dass es sich um Middleware für alle KI-Modelle handelt