Lokale vs. entfernte MCP-Server
Die architektonische Entscheidung unter jedem Produkt dieser Kategorie. Was jeweils tatsächlich riskiert wird, was die Spezifikation fordert – und was keines von beiden löst.
Zuletzt geprüft:
Ein lokaler MCP-Server läuft als Prozess auf dem eigenen Rechner mit den eigenen Benutzerrechten. Ein entfernter MCP-Server läuft auf fremder Infrastruktur und wird über HTTP mit OAuth erreicht.
Der Handel ist überschaubar. Lokal hält die Daten auf dem Gerät und braucht kein Vertrauen in Dritte, aber der Server läuft mit allem, was Sie erreichen können – ein schlecht geschriebener oder bösartiger Server ist damit ein ernsthaftes Problem, und es gibt keine zentrale Stelle, an der man ihn entziehen könnte. Entfernt bringt echte Identität, widerrufbare Token und zentrale Protokollierung, aber Ihre Daten wandern über ein Netz in Infrastruktur, die Ihnen nicht gehört. Die meisten realen Aufbauten haben beides – deshalb ist die interessante Frage nicht „was ist sicherer“, sondern „was setzt jeweils die Grenze durch“.
Gegenüberstellung
| Lokaler MCP-Server | Entfernter MCP-Server | |
|---|---|---|
| Wo er läuft | Als Prozess auf Ihrem Rechner | Auf dem Server eines Anbieters oder Ihres Unternehmens |
| Transport | stdio (meist) | Streamable HTTP – die einzige Standard-HTTP-Bindung in der Revision 2026-07-28; ältere Server nutzen teils noch das frühere HTTP+SSE |
| Authentifizierung | Keine – er erbt Ihr Benutzerkonto | OAuth 2.1, sofern Autorisierung implementiert ist; die Spezifikation stellt Autorisierung frei, empfiehlt HTTP-Servern aber ihr OAuth-2.1-Profil |
| Effektive Rechte | Alles, was Ihr Benutzer erreichen kann | Was die Scopes des Tokens erlauben |
| Datenort | Bleibt auf dem Gerät | Verlässt das Netz |
| Entzug | Deinstallieren oder an einem lokalen Gateway sperren | Token zentral widerrufen |
| Zentrale Protokollierung | Nur, wenn etwas Lokales protokolliert | Ja, am Gateway oder Server |
| Offline nutzbar | Ja | Nein |
| Hauptrisiko | Beliebiger Code mit Ihren Rechten | Vertrauen in Dritte, Token-Diebstahl, Confused Deputy |
| Passende Kontrolle | Berechtigungsschicht oder Sandbox auf dem Gerät | Netzwerk-Gateway mit IdP-gestütztem RBAC |
Das konkrete Risiko lokaler MCP-Server
Das ist nicht theoretisch, und die Spezifikation sagt es selbst. Die Sicherheitsleitlinien zur Revision
2026-07-28 legen fest, dass ein Client mit Ein-Klick-Konfiguration lokaler Server den exakten, ungekürzten Befehl
anzeigen, ihn als gefährlich kennzeichnen und ausdrücklich bestätigen lassen muss – und den Server
sandboxen, Dateisystem- und Netzwerkzugriff einschränken und bei Mustern wie sudo, rm -rf
oder Zugriff auf ~/.ssh warnen sollte.
Der Grund ist einfach: Einen lokalen MCP-Server zu installieren heißt, Software zu installieren. Sie läuft als Sie. Nichts im Protokoll begrenzt sie auf den Ordner, den Sie im Sinn hatten.
- EscapeRoute (CVE-2025-53109 / CVE-2025-53110, Juli 2025) – eine Sandbox-Umgehung im offiziellen Filesystem-MCP-Server, verursacht durch Präfix-Vergleiche auf Pfaden und einen Rückfall in der Pfadauflösung.
- CVE-2025-59536 (Oktober 2025) – eine Code-Injection-Schwachstelle im Startdialog von Claude Code vor Version 1.0.111, durch die Projektdateien Code ausführen konnten, bevor der Dialog bestätigt war.
- CVE-2026-21852 (Januar 2026) – eine Schwachstelle im Projekt-Ladevorgang von Claude Code vor Version 2.0.65, durch die ein bösartiges Repository Daten inklusive Anthropic-API-Schlüsseln abfließen lassen konnte, bevor die Nutzerin Vertrauen bestätigt hatte.
- Lieferkette – im September 2025 stellte sich heraus, dass das npm-Paket
postmark-mcpnach fünfzehn unauffälligen Versionen mit einer Hintertür versehen war, die jede versendete E-Mail unbemerkt an eine fremde Adresse in Blindkopie schickte. Typosquattete MCP-Pakete folgten seither demselben Muster. - Scan-Ergebnisse – Sicherheitsanalysen öffentlicher MCP-Server aus 2025 und 2026 berichten wiederholt über erhebliche Anteile mit gravierenden Mängeln. Mit konkreten Prozentzahlen sollte man vorsichtig sein; Stichproben und Kriterien unterscheiden sich zwischen den Studien.
Anthropic schreibt ausdrücklich, dass Connectors gegen Aufnahmekriterien geprüft, MCP-Server aber nicht sicherheitsauditiert oder verwaltet werden. Niemand prüft das für Sie.
Das konkrete Risiko entfernter MCP-Server
Entfernte Server tauschen Code-Ausführungsrisiko gegen Vertrauens- und Protokollrisiko. Das Sicherheitsdokument der Spezifikation befasst sich überwiegend mit genau diesen Problemen:
- Confused Deputy – ein Proxy-Server mit statischer Client-ID kann dazu gebracht werden,
Zugangsdaten an Angreifer auszustellen. Zur Abwehr braucht es Zustimmungsspeicherung pro Client, exakten Abgleich
der Redirect-URI und – sofern Zustimmung über Cookies statt über serverseitige Sitzungen verfolgt wird – signierte
Cookies mit
__Host--Präfix. - Token-Durchreichung – die Spezifikation ist eindeutig: Ein MCP-Server darf keine Token akzeptieren, die nicht für ihn ausgestellt wurden.
- SSRF bei der OAuth-Metadaten-Erkennung – Clients sollten HTTPS erzwingen und private, Loopback- und Link-Local-Adressen blockieren, inklusive des Cloud-Metadaten-Endpunkts.
- State-Handle-Hijacking – MCP ist zustandslos ohne Sitzungen auf Protokollebene; der Besitz eines State-Handles darf nie als Authentifizierung gelten.
- Vertrauen in Dritte – Ihre Daten liegen auf deren Infrastruktur, unter deren Aufbewahrungsregeln.
Kein Transport schützt vor Prompt Injection
Das sollte klar gesagt werden, weil es der am häufigsten missverstandene Punkt der Kategorie ist: Lokal oder entfernt macht für indirekte Prompt Injection, Tool Poisoning, Rug Pulls oder Cross-Server-Shadowing keinen Unterschied. Diese Angriffe reisen in Inhalten – einer Tool-Beschreibung, einem Dokument, einem Kommentar, einer Fehlermeldung – und der Transport ist dabei gleichgültig.
Was den Schaden begrenzt, ist ebenfalls nicht der Transport, sondern der Wirkungsradius: was der Agent erreichen könnte, wenn er erfolgreich manipuliert würde. Das ist eine Berechtigungsfrage – weshalb ein abgestuftes Berechtigungsmodell eine Gegenmaßnahme gegen Prompt Injection ist, obwohl es sie nicht erkennt.
Wohin sich der Standard bewegt
Ein Entwurf, SEP-1708 „MCP Client-Brokered Filesystem Access“, würde den Dateizugriff aus einem lokalen Filesystem-Server heraus in den Client verlagern – mit Freigabe pro Pfad durch die Nutzerin und Entzug beim Verbindungsende. Der Vorschlag liegt seit Ende 2025 als Entwurf vor und hat weiterhin keinen Sponsor; er ist also Richtungsangabe, nicht Verlassensgrundlage. Die Richtung ist aufschlussreich: Das Ökosystem ist sich einig, dass der Client – das, was auf Ihrem Rechner läuft – der richtige Ort für die Zugriffsentscheidung ist.
Praktische Empfehlungen
- Lokale Server in ihrer Sicht beschränken. Entweder sandboxen (Docker MCP Toolkit, ToolHive) oder eine Berechtigungsschicht davorsetzen, sodass der Server nur Ordner erhält, die Sie ausdrücklich freigegeben haben.
- Für entfernte Server ein Gateway mit echter Identität nutzen. Pomerium, MintMCP, TrueFoundry, Obot und die etablierten API-Gateways machen das sauber.
- Jede Tool-Beschreibung als nicht vertrauenswürdige Eingabe behandeln. Sie erreicht das Modell, also ist sie Teil des Prompts.
- Berechtigungen abstufen statt umschalten. Nur-lesen ist nicht die einzige Alternative zu vollem Zugriff; „nur in Kopien schreiben“ und „vor jedem Schreiben sichern“ decken die meiste reale Arbeit ab.
- Lokal alles protokollieren. Wer die Frage „worauf hat die KI letzten Dienstag zugegriffen“ nicht beantworten kann, hat keine Reaktionsfähigkeit im Ernstfall.
Kobel setzt Punkt eins, vier und fünf für Windows und Mac um: ein lokales Gateway mit fünf Berechtigungsstufen pro Ressource und einem Aktivitätsprotokoll mit Zeitstempel über Dateien, Unternehmenssoftware und verbundene Konten hinweg.
Die fünf Stufen von Kobel
Jeder Ordner, jedes Programm und jedes Konto bekommt genau eine dieser fünf Stufen. Eingestellt wird sie, indem man einen Ordner hineinzieht und eine Farbe wählt – keine Konfigurationsdatei.
- GrünLesen und schreiben. Die KI darf Dateien öffnen und Änderungen direkt speichern.
- TürkisSchreiben mit automatischem Backup. Vor jeder Änderung wird eine Sicherungskopie angelegt – eine schlechte Änderung ist immer rückgängig zu machen.
- OrangeOriginal lesen, nur in Kopien schreiben. Die KI kann mit den Daten arbeiten, die Quelldatei aber nicht verändern.
- GelbNur lesen. Ansehen, nicht anfassen.
- RotGesperrt. Die Ressource ist für die KI unsichtbar.
Weiterlesen
Quellen
- Model Context Protocol – Security Best Practices (2026-07-28)
- Model Context Protocol – Lokale MCP-Server verbinden
- SEP-1708 – Client-vermittelter Dateisystemzugriff (Entwurf)
- OWASP – MCP Security Cheat Sheet
- OWASP – MCP Tool Poisoning
- Invariant Labs – Tool-Poisoning-Angriffe
- CVE-2025-53110 – Pfad-Umgehung im Filesystem-MCP-Server
- NSA – Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation (Mai 2026)
- Koi Security – Hintertür im npm-Paket postmark-mcp (September 2025)
Mit einem Ordner ausprobieren
Kobel installieren, einen einzigen Ordner hineinziehen, auf „Nur lesen“ stellen, KI verbinden. Zwei Minuten. Kostenlose Basis-Version, kein Konto nötig.
Kobel herunterladenFunktionen ansehenHäufige Fragen
Was ist der Unterschied zwischen einem lokalen und einem entfernten MCP-Server?
Ein lokaler MCP-Server läuft als Prozess auf Ihrem eigenen Rechner, meist über stdio, mit Ihren Benutzerrechten und ohne Authentifizierung. Ein entfernter MCP-Server läuft auf fremder Infrastruktur und wird über HTTP erreicht, in der Regel mit OAuth 2.1, sodass der Zugriff an ein zentral widerrufbares Token gebunden ist. Die Spezifikation stellt Autorisierung frei, empfiehlt HTTP-Servern aber ihr OAuth-2.1-Profil.
Ist lokales MCP sicherer als entferntes MCP?
Nicht automatisch. Lokal hält die Daten auf dem Gerät und braucht kein Vertrauen in Dritte, aber der Server läuft mit allem, was Ihr Benutzerkonto erreichen kann, und es gibt keinen zentralen Entzug. Entfernt bringt Identität und Protokollierung, sendet die Daten aber in fremde Infrastruktur. Sicherer ist, wovor eine durchgesetzte Grenze steht.
Schützt ein lokaler MCP-Server vor Prompt Injection?
Nein. Prompt Injection, Tool Poisoning und Rug Pulls reisen in Inhalten – Tool-Beschreibungen, Dokumenten, Fehlermeldungen – und sind vom Transport unabhängig. Den Schaden begrenzt nur, wie wenig der Agent überhaupt erreichen durfte.
Brauche ich OAuth für einen lokalen MCP-Server?
Nein. Lokale Server über stdio erben Ihr Benutzerkonto und haben keine Authentifizierungsebene – genau deshalb empfiehlt die Spezifikation, sie zu sandboxen und Dateisystem- sowie Netzwerkzugriff einzuschränken.
Wie hindere ich einen lokalen MCP-Server daran, mein ganzes Benutzerverzeichnis zu lesen?
Entweder Sie führen ihn in einer Sandbox oder einem Container mit eingeschränktem Dateisystem aus, oder Sie setzen eine Berechtigungsschicht davor, die nur die hinzugefügten Ordner freigibt. Erlaubte Verzeichnisse als Kommandozeilenargumente zu übergeben funktioniert ebenfalls, war historisch aber fragil – CVE-2025-53110 war genau eine Umgehung dieses Mechanismus.