# MCP-Server-Security: Lokalen LLM-Zugriff auf das Dateisystem absichern MCP-Server-Security ist entscheidend, wenn KI-Anwendungen auf lokale Dateien und Verzeichnisse zugreifen. Das Model Context Protocol (MCP) ermöglicht die Einbindung von Dateisystemen in KI-Workflows, schafft dabei aber auch neue Angriffsflächen. Unzureichende Berechtigungen, manipulierte Dateien und unkontrollierte Datenübertragungen können sensible Informationen gefährden. Geeignete Sicherheitsmaßnahmen helfen, diese Risiken zu reduzieren. ## Was bedeutet MCP-Server-Security? MCP-Server-Security bezeichnet die **technischen und organisatorischen Maßnahmen**, mit denen der Zugriff von KI-Anwendungen auf lokale Ressourcen über [MCP](https://www.ionos.de/digitalguide/server/knowhow/model-context-protocol/)-Server abgesichert wird. Dazu gehören Berechtigungen, Zugriffsbeschränkungen und Isolationsmechanismen. Sie sollen verhindern, dass Sprachmodelle über bereitgestellte Werkzeuge unbefugt Dateien auslesen, verändern oder vertrauliche Informationen weitergeben. Grundsätzlich greifen [Large Language Models (LLMs)](https://www.ionos.de/digitalguide/server/knowhow/large-language-model/) nicht unmittelbar auf das Dateisystem zu. Die KI-Anwendung vermittelt über einen MCP-Client entsprechende Tool-Aufrufe an den MCP-Server. Welche Dateioperationen tatsächlich möglich sind, hängt von den angebotenen Funktionen und den Berechtigungen des Serverprozesses ab. MCP selbst stellt dabei jedoch **keine vollständige Sicherheitsumgebung** bereit. Die Absicherung muss durch die Serverimplementierung, die Konfiguration des Clients und zusätzliche Schutzmechanismen des Betriebssystems erfolgen. ## Welche Sicherheitsrisiken bestehen beim lokalen MCP-Dateizugriff? Ein MCP-Server mit Dateisystemzugriff erweitert die Handlungsmöglichkeiten einer KI-Anwendung. Gleichzeitig entstehen neue Angriffsflächen, insbesondere wenn der Server umfassende Lese- und Schreibrechte besitzt oder Inhalte aus nicht vertrauenswürdigen Quellen verarbeitet. ### Indirekte Prompt Injections durch manipulierte Dateien Bei einer Prompt Injection werden **Anweisungen in Inhalte eingeschleust**, die ein Sprachmodell eigentlich nur als Daten verarbeiten soll. Beim lokalen Dateizugriff können solche Anweisungen beispielsweise in Markdown-Dateien, Quellcode-Kommentaren oder Dokumentationen enthalten sein. Liest das LLM eine manipulierte Datei, kann es die darin enthaltenen Anweisungen fälschlicherweise als Handlungsaufforderung interpretieren. Dadurch könnte es über den MCP-Client weitere Tools aufrufen und unerwünschte Aktionen ausführen, beispielsweise: - Dateien überschreiben - Verzeichnisse verändern - vertrauliche Informationen auslesen Ein mögliches Szenario ist eine manipulierte Projektdatei, die das Modell dazu auffordert, vor der eigentlichen Aufgabe eine bestehende Konfigurationsdatei zu verändern. Verfügt der MCP-Server über die erforderlichen Schreibrechte, kann die **Änderung ohne entsprechende Absicht der nutzenden Person** erfolgen. Entscheidend ist daher die Trennung zwischen vertrauenswürdigen Anweisungen und potenziell manipulierten Dateiinhalten. Letztere dürfen nicht als autorisierte Handlungsanweisungen behandelt werden. ### Unbefugter Zugriff auf sensible Dateien Ein weiteres Risiko entsteht durch zu weitreichende Dateisystemberechtigungen. Wird ein MCP-Server beispielsweise mit **Zugriff auf das gesamte Benutzerverzeichnis** gestartet, kann er möglicherweise auch Dateien erreichen, die für die eigentliche Aufgabe nicht erforderlich sind. Dazu zählen unter anderem: - Konfigurationsdateien mit [API-Schlüsseln](https://www.ionos.de/digitalguide/websites/web-entwicklung/api-key/) oder Zugangsdaten - [SSH-Schlüssel](https://www.ionos.de/digitalguide/server/sicherheit/ssh-keys-fuer-ihre-netzwerkverbindung-nutzen/) und andere Authentifizierungsinformationen - interne Geschäftsunterlagen und [personenbezogene Daten](https://www.ionos.de/digitalguide/websites/online-recht/personenbezogene-daten/) - System- und Anwendungskonfigurationen Bereits **Lesezugriff kann ausreichen, um vertrauliche Informationen offenzulegen**. Schreibrechte erhöhen das Risiko zusätzlich, weil Dateien unbeabsichtigt verändert, überschrieben oder gelöscht werden können. Problematisch ist dabei, dass der MCP-Server technisch erlaubte Operationen ausführen kann, obwohl diese für die eigentliche Aufgabe nicht erforderlich oder nicht erwünscht sind. Eine Schwachstelle im MCP-Protokoll ist dafür nicht notwendig. ### Datenexfiltration durch externe Tools und Netzwerkzugriffe Neben unerwünschten Dateizugriffen besteht das Risiko, dass **vertrauliche Informationen das lokale System verlassen**. Dieser Vorgang wird als Datenexfiltration bezeichnet. Besonders kritisch ist es, wenn eine KI-Anwendung sowohl auf sensible Dateien als auch auf Tools mit externen Kommunikationsmöglichkeiten zugreifen kann. Beispielsweise können ausgelesene Zugangsdaten über ein zusätzlich eingebundenes Tool mit Netzwerkzugriff an einen externen Server übertragen werden. Dafür benötigt der MCP-Filesystem-Server selbst keine Schreibrechte. Ein weiterer möglicher Übertragungsweg entsteht beim **Einsatz cloudbasierter LLMs**. Werden lokale Dateiinhalte in Modellanfragen eingebunden, können diese Informationen an den externen Modellanbieter gelangen. Ob dies zulässig ist, hängt von den verarbeiteten Daten und den geltenden Datenschutzanforderungen ab. ## Wie lässt sich die MCP-Server-Security verbessern? Für einen sicheren MCP-Betrieb sollten **mehrere Schutzmechanismen kombiniert** werden. Im Mittelpunkt stehen minimale Berechtigungen, klar definierte Dateisystemgrenzen, die Isolation des Serverprozesses und die Kontrolle kritischer Tool-Aufrufe.
Schutzmaßnahme Technische Umsetzung Sicherheitswirkung
Principle of Least Privilege Separates Benutzerkonto, minimale Betriebssystemrechte, schreibgeschützte Mounts und ausschließlich benötigte Tools Begrenzung möglicher Lese- und Schreiboperationen
Pfadbeschränkungen Explizite Verzeichnisfreigaben (Allowlisting), kanonische Pfadprüfung und Kontrolle symbolischer Links Verhindert Zugriffe außerhalb der vorgesehenen Verzeichnisse
Sandboxing Isolation beispielsweise mit Docker oder einer geeigneten WebAssembly-Laufzeit, eingeschränkte Mounts und Netzwerkrechte Begrenzt die Auswirkungen kompromittierter oder fehlerhafter Server
Human-in-the-Loop Manuelle Freigabe kritischer Dateioperationen vor der Ausführung Reduziert das Risiko unbeabsichtigter oder manipulierter Tool-Aufrufe
### Minimale Berechtigungen nach dem Least-Privilege-Prinzip Das Prinzip der geringsten Privilegien besagt, dass **Prozesse nur die Berechtigungen erhalten sollten, die sie zur Erfüllung ihrer Aufgaben benötigen**. Ein MCP-Server, der Dokumente ausschließlich analysieren soll, benötigt beispielsweise keine Schreibrechte. Solche Rechte sollten deshalb nicht nur auf Anwendungsebene ausgeschlossen, sondern auch durch Betriebssystemberechtigungen oder schreibgeschützte Dateisystem-Mounts wirksam unterbunden werden. Zusätzlich empfiehlt es sich, MCP-Server unter einem **separaten Benutzerkonto mit eingeschränkten Zugriffsrechten** auszuführen. Unter Linux lassen sich die [Datei- und Verzeichnisrechte mit chmod gezielt anpassen](https://www.ionos.de/digitalguide/server/knowhow/die-vergabe-von-verzeichnisrechten-mit-chmod/). Dadurch wird vermieden, dass ein Server automatisch sämtliche Berechtigungen des angemeldeten Benutzerkontos übernimmt. Hinweis Das MCP-Protokoll unterstützt Tool-Annotationen wie readOnlyHint, mit denen Server eine Funktion als lesend kennzeichnen können. Diese Angaben dienen allerdings nur als Hinweise für den Client und stellen keine verbindliche Sicherheitskontrolle dar. Tools ohne entsprechende Annotationen gelten standardmäßig als potenziell destruktiv. Entscheidend sind die tatsächlich durchgesetzten Berechtigungen. ### Dateizugriffe durch Pfadbeschränkungen begrenzen Neben den allgemeinen Dateisystemrechten sollte festgelegt werden, welche Verzeichnisse ein MCP-Server überhaupt verwenden darf. Beim sogenannten Allowlisting ist der Zugriff **ausschließlich auf ausdrücklich freigegebene Pfade beschränkt**. Eine sichere Implementierung muss außerdem prüfen, ob angeforderte Dateipfade nach ihrer Auflösung innerhalb dieser Grenzen liegen. Das ist insbesondere bei relativen Pfaden, symbolischen Links und sogenannten Path-Traversal-Angriffen wichtig, bei denen beispielsweise durch `../` auf übergeordnete Verzeichnisse zugegriffen werden soll. Frühere Sicherheitslücken im offiziellen MCP-Filesystem-Server zeigen, dass fehlerhafte Pfadprüfungen oder eine unzureichende Kontrolle symbolischer Links die vorgesehenen Zugriffsbeschränkungen aushebeln können. Der offizielle MCP-Filesystem-Server unterstützt die **Konfiguration erlaubter Verzeichnisse über Startargumente** und die ältere Roots-Funktion. Dabei ist eine Besonderheit zu beachten: Laut Dokumentation des offiziellen MCP-Filesystem-Servers können vom Client gemeldete Roots die über Startargumente festgelegten Verzeichnisse vollständig ersetzen. Welche Verzeichnisse tatsächlich freigegeben sind, lässt sich mit `list_allowed_directories` überprüfen. Um beim Start des Filesystem-Servers ein Projektverzeichnis als erlaubten Pfad festzulegen, verwenden Sie beispielsweise folgenden Befehl: ```bash npx -y @modelcontextprotocol/server-filesystem@ /home/mcp/projekt ``` Ersetzen Sie <VERSION> durch eine geprüfte, aktuelle Paketversion und /home/mcp/projekt durch den Pfad zum gewünschten Verzeichnis. Der gezeigte Pfad ist ein Linux-Beispiel – unter Windows muss ein entsprechender Windows-Pfad angegeben werden. Der Server erhält damit eine **anwendungsseitige Pfadbeschränkung**. Diese ersetzt jedoch keine Betriebssystemberechtigungen. Zusätzlich muss geprüft werden, welche Verzeichnisse der Client tatsächlich freigibt und welche Rechte der Serverprozess besitzt. Die feste Paketversion verhindert, dass beim Start unbeabsichtigt eine andere Version des MCP-Servers verwendet wird. Hinweis Die Roots-Funktion sollte nicht als technisch durchgesetzte Sicherheitsgrenze betrachtet werden. Welche Unterstützung für Roots besteht, hängt von der verwendeten MCP-Spezifikationsversion und der jeweiligen Implementierung ab. Für neue Implementierungen empfiehlt die Spezifikation, Verzeichnisse und Dateien stattdessen über Tool-Parameter, Resource-URIs oder die Serverkonfiguration festzulegen. Der tatsächliche Dateizugriff muss weiterhin durch serverseitige Zugriffskontrollen und Betriebssystemberechtigungen abgesichert werden. ### MCP-Server durch Sandboxing isolieren Beim [Sandboxing](https://www.ionos.de/digitalguide/websites/web-entwicklung/was-ist-eine-sandbox/) wird ein MCP-Server in einer eingeschränkten Ausführungsumgebung betrieben. Dadurch lassen sich die erreichbaren Dateien, Prozesse und Netzwerkressourcen begrenzen: - Eine Möglichkeit ist der Einsatz eines [Docker-Containers](https://www.ionos.de/digitalguide/server/knowhow/docker-container/). Dabei werden nur die benötigten Verzeichnisse eingebunden, möglichst schreibgeschützt. Zusätzlich können Linux-Sicherheitsmechanismen wie Seccomp, AppArmor oder [SELinux](https://www.ionos.de/digitalguide/server/sicherheit/was-ist-selinux/) eingesetzt und unnötige Netzwerkverbindungen unterbunden werden. - Auch [WebAssembly](https://www.ionos.de/digitalguide/websites/web-entwicklung/was-ist-webassembly/) kann bei geeigneten MCP-Serverimplementierungen eine isolierte Laufzeitumgebung bereitstellen. Welche Zugriffe möglich sind, hängt dabei von der verwendeten Laufzeit und ihren freigegebenen Funktionen ab. Wichtig ist, dass Container **nicht automatisch eine vollständige Sicherheitsgrenze** darstellen. Werden beispielsweise umfangreiche Host-Verzeichnisse eingebunden oder privilegierte Container verwendet, kann die Schutzwirkung erheblich eingeschränkt sein. Gleiches gilt für einfache `chroot`-Umgebungen, die allein keine umfassende Prozessisolation gewährleisten. Hinweis Bei lokal über stdio gestarteten MCP-Servern stehen die Berechtigungen und die Isolation des Serverprozesses im Vordergrund. Wird ein MCP-Server dagegen über HTTP bereitgestellt, müssen zusätzlich die Netzwerkzugriffe abgesichert werden. Lokal betriebene HTTP-Server sollten deshalb nur an die Loopback-Adresse (127.0.0.1) gebunden werden und eingehende Host- sowie gegebenenfalls Origin-Header validieren, um unter anderem DNS-Rebinding-Angriffe zu verhindern. Für den Zugriff weiterer Clients sind geeignete Authentifizierungs- und Autorisierungsmechanismen erforderlich. ### Kritische Dateioperationen manuell freigeben Beim Human-in-the-Loop-Ansatz wird ein Mensch in sicherheitsrelevante Entscheidungen eingebunden. Vor kritischen Tool-Aufrufen sollte die KI-Anwendung eine **ausdrückliche Bestätigung einholen**. Dies ist insbesondere bei Operationen sinnvoll, die Dateien überschreiben, löschen, verschieben oder umfangreich verändern. Die Freigabe sollte erkennen lassen, welches Tool aufgerufen wird, welche Datei betroffen ist und welche Änderung vorgenommen werden soll. Manuelle Bestätigungen sind allerdings nur eine zusätzliche Sicherheitsebene. Sie **können technische Zugriffsbeschränkungen nicht ersetzen**, da auch freigegebene Operationen unbeabsichtigte Folgen haben können. ## MCP-Server-Security und Datenschutz: Lokale vs. Cloud-LLMs Der lokale Betrieb eines MCP-Servers bedeutet nicht zwangsläufig, dass sämtliche Daten auf dem eigenen System verbleiben. Entscheidend ist, **wo das Sprachmodell ausgeführt wird** und welche Informationen die KI-Anwendung an externe Dienste übermittelt. - Bei einem **Cloud-LLM** werden Modellanfragen an einen externen Anbieter übertragen. Enthalten diese Anfragen Informationen aus lokalen Dateien, verlassen möglicherweise auch vertrauliche Unternehmensdaten oder personenbezogene Informationen die eigene Infrastruktur. - Ein **lokales LLM** kann dagegen vollständig innerhalb der eigenen IT-Umgebung betrieben werden. Zusammen mit einem lokalen MCP-Server lässt sich so eine Architektur aufbauen, bei der Dateiinhalte nicht für die Modellverarbeitung an externe Anbieter übertragen werden müssen. Voraussetzung ist, dass auch andere Komponenten keine entsprechenden Daten nach außen senden.
Aspekt Cloud-LLM mit lokalem MCP-Server Lokales LLM mit lokalem MCP-Server
Modellverarbeitung Auf externen Servern Auf eigener Infrastruktur
Übermittlung von Dateiinhalten Möglich, wenn Inhalte in Modellanfragen einfließen Für die Modellverarbeitung nicht erforderlich
Kontrolle über Datenverarbeitung Abhängig vom Anbieter und der Konfiguration Weitgehend innerhalb der eigenen Infrastruktur
Datenschutzmaßnahmen Datenminimierung, Filterung und vertragliche Absicherung Zugriffskontrollen, lokale Datenhaltung und Netzwerkkontrolle
### Sensible Informationen vor der Übermittlung filtern Soll ein Cloud-LLM verwendet werden, können lokale [Proxy-Server](https://www.ionos.de/digitalguide/server/knowhow/was-ist-ein-proxy-server/) mit Filterfunktionen als zusätzliche Schutzschicht dienen. Sie prüfen Informationen vor der Übermittlung an den Modelldienst und können beispielsweise bestimmte Zugangsdaten, personenbezogene Informationen oder vertrauliche Textpassagen entfernen beziehungsweise maskieren. Solche Filter reduzieren das Risiko unbeabsichtigter Datenweitergaben. Sie erkennen jedoch nicht zuverlässig sämtliche schützenswerten Informationen. Deshalb sollten sensible Dateien möglichst bereits durch restriktive Zugriffsrechte von der Verarbeitung ausgeschlossen werden. Für die **Data Governance** sind außerdem klare Vorgaben zur Verarbeitung, Protokollierung und Aufbewahrung der Daten erforderlich. Auch die Berechtigungen weiterer eingebundener Tools und mögliche Netzwerkzugriffe müssen berücksichtigt werden. Ein vollständig lokal betriebenes LLM kann die **Kontrolle über die Verarbeitung sensibler Daten verbessern**. Eine automatische [DSGVO](https://www.ionos.de/digitalguide/websites/online-recht/datenschutz-grundverordnung-regeln-fuer-unternehmen/)-Konformität ergibt sich daraus jedoch nicht. Auch lokale Anwendungen müssen die jeweils geltenden Datenschutzanforderungen erfüllen. ## Checkliste für einen sicheren MCP-Server Das Model Context Protocol ermöglicht leistungsfähige Integrationen zwischen KI-Anwendungen und lokalen Dateisystemen. Die damit verbundenen Risiken lassen sich jedoch nur durch geeignete Schutzmaßnahmen begrenzen. MCP selbst garantiert weder eine sichere Dateisystemisolation noch den Schutz vor Prompt Injections. Entscheidend sind insbesondere **minimale Berechtigungen, zuverlässig durchgesetzte Verzeichnisgrenzen und die Isolation des MCP-Servers**. Ergänzende Freigabeprozesse und eine kontrollierte Datenverarbeitung erhöhen die Sicherheit. Vor dem produktiven Einsatz eines MCP-Servers sollten Entwicklerinnen und Entwickler folgende Punkte überprüfen: Stammt der MCP-Server aus einer vertrauenswürdigen Quelle, ist seine Software aktuell und erhält der Prozess nur die erforderlichen Umgebungsvariablen und Zugangsdaten? Sind nur die erforderlichen Tools und Dateisystemberechtigungen aktiviert? Sind die erlaubten Verzeichnisse eindeutig festgelegt und tatsächlich wirksam? Sind sensible Dateien und Verzeichnisse vom Zugriff ausgeschlossen? Werden symbolische Links und Pfadumgehungen sicher behandelt? Ist der Serverprozess ausreichend isoliert und sind Netzwerkzugriffe beschränkt? Müssen kritische Schreib- und Löschoperationen ausdrücklich bestätigt werden? Ist geklärt, welche Dateiinhalte an externe Modellanbieter übermittelt werden? Sind Protokollierung, Datenaufbewahrung und Zugriffsrechte geregelt? Wurden Prompt Injections und unzulässige Dateizugriffe vor dem Deployment getestet? Eine sorgfältige Konfiguration und regelmäßige Überprüfung der Sicherheitsmaßnahmen bilden die **Grundlage für einen kontrollierten MCP-Dateizugriff**. This is a markdown version of: [https://www.ionos.de/digitalguide/server/sicherheit/mcp-server-security/](https://www.ionos.de/digitalguide/server/sicherheit/mcp-server-security/) for AI/LLM consumption.