MCP-Server-Security: Lokalen LLM-Zugriff auf das Da­tei­sys­tem absichern

MCP-Server-Security ist ent­schei­dend, wenn KI-An­wen­dun­gen auf lokale Dateien und Ver­zeich­nis­se zugreifen. Das Model Context Protocol (MCP) er­mög­licht die Ein­bin­dung von Da­tei­sys­te­men in KI-Workflows, schafft dabei aber auch neue An­griffs­flä­chen. Un­zu­rei­chen­de Be­rech­ti­gun­gen, ma­ni­pu­lier­te Dateien und un­kon­trol­lier­te Da­ten­über­tra­gun­gen können sensible In­for­ma­tio­nen gefährden. Geeignete Si­cher­heits­maß­nah­men helfen, diese Risiken zu re­du­zie­ren.

Was bedeutet MCP-Server-Security?

MCP-Server-Security be­zeich­net die tech­ni­schen und or­ga­ni­sa­to­ri­schen Maßnahmen, mit denen der Zugriff von KI-An­wen­dun­gen auf lokale Res­sour­cen über MCP-Server ab­ge­si­chert wird. Dazu gehören Be­rech­ti­gun­gen, Zu­griffs­be­schrän­kun­gen und Iso­la­ti­ons­me­cha­nis­men. Sie sollen ver­hin­dern, dass Sprach­mo­del­le über be­reit­ge­stell­te Werkzeuge unbefugt Dateien auslesen, verändern oder ver­trau­li­che In­for­ma­tio­nen wei­ter­ge­ben.

Grund­sätz­lich greifen Large Language Models (LLMs) nicht un­mit­tel­bar auf das Da­tei­sys­tem zu. Die KI-Anwendung ver­mit­telt über einen MCP-Client ent­spre­chen­de Tool-Aufrufe an den MCP-Server. Welche Da­tei­ope­ra­tio­nen tat­säch­lich möglich sind, hängt von den an­ge­bo­te­nen Funk­tio­nen und den Be­rech­ti­gun­gen des Ser­ver­pro­zes­ses ab. MCP selbst stellt dabei jedoch keine voll­stän­di­ge Si­cher­heits­um­ge­bung bereit. Die Ab­si­che­rung muss durch die Ser­ver­im­ple­men­tie­rung, die Kon­fi­gu­ra­ti­on des Clients und zu­sätz­li­che Schutz­me­cha­nis­men des Be­triebs­sys­tems erfolgen.

Welche Si­cher­heits­ri­si­ken bestehen beim lokalen MCP-Da­tei­zu­griff?

Ein MCP-Server mit Da­tei­sys­tem­zu­griff erweitert die Hand­lungs­mög­lich­kei­ten einer KI-Anwendung. Gleich­zei­tig entstehen neue An­griffs­flä­chen, ins­be­son­de­re wenn der Server um­fas­sen­de Lese- und Schreib­rech­te besitzt oder Inhalte aus nicht ver­trau­ens­wür­di­gen Quellen ver­ar­bei­tet.

Indirekte Prompt In­jec­tions durch ma­ni­pu­lier­te Dateien

Bei einer Prompt Injection werden An­wei­sun­gen in Inhalte ein­ge­schleust, die ein Sprach­mo­dell ei­gent­lich nur als Daten ver­ar­bei­ten soll. Beim lokalen Da­tei­zu­griff können solche An­wei­sun­gen bei­spiels­wei­se in Markdown-Dateien, Quellcode-Kom­men­ta­ren oder Do­ku­men­ta­tio­nen enthalten sein. Liest das LLM eine ma­ni­pu­lier­te Datei, kann es die darin ent­hal­te­nen An­wei­sun­gen fälsch­li­cher­wei­se als Hand­lungs­auf­for­de­rung in­ter­pre­tie­ren. Dadurch könnte es über den MCP-Client weitere Tools aufrufen und un­er­wünsch­te Aktionen ausführen, bei­spiels­wei­se:

• Dateien über­schrei­ben
• Ver­zeich­nis­se verändern
• ver­trau­li­che In­for­ma­tio­nen auslesen

Ein mögliches Szenario ist eine ma­ni­pu­lier­te Pro­jekt­da­tei, die das Modell dazu auf­for­dert, vor der ei­gent­li­chen Aufgabe eine be­stehen­de Kon­fi­gu­ra­ti­ons­da­tei zu verändern. Verfügt der MCP-Server über die er­for­der­li­chen Schreib­rech­te, kann die Änderung ohne ent­spre­chen­de Absicht der nutzenden Person erfolgen.

Ent­schei­dend ist daher die Trennung zwischen ver­trau­ens­wür­di­gen An­wei­sun­gen und po­ten­zi­ell ma­ni­pu­lier­ten Da­tei­in­hal­ten. Letztere dürfen nicht als au­to­ri­sier­te Hand­lungs­an­wei­sun­gen behandelt werden.

Un­be­fug­ter Zugriff auf sensible Dateien

Ein weiteres Risiko entsteht durch zu weit­rei­chen­de Da­tei­sys­tem­be­rech­ti­gun­gen. Wird ein MCP-Server bei­spiels­wei­se mit Zugriff auf das gesamte Be­nut­zer­ver­zeich­nis gestartet, kann er mög­li­cher­wei­se auch Dateien erreichen, die für die ei­gent­li­che Aufgabe nicht er­for­der­lich sind. Dazu zählen unter anderem:

• Kon­fi­gu­ra­ti­ons­da­tei­en mit API-Schlüs­seln oder Zu­gangs­da­ten
• SSH-Schlüssel und andere Au­then­ti­fi­zie­rungs­in­for­ma­tio­nen
• interne Ge­schäfts­un­ter­la­gen und per­so­nen­be­zo­ge­ne Daten
• System- und An­wen­dungs­kon­fi­gu­ra­tio­nen

Bereits Le­se­zu­griff kann aus­rei­chen, um ver­trau­li­che In­for­ma­tio­nen of­fen­zu­le­gen. Schreib­rech­te erhöhen das Risiko zu­sätz­lich, weil Dateien un­be­ab­sich­tigt verändert, über­schrie­ben oder gelöscht werden können.

Pro­ble­ma­tisch ist dabei, dass der MCP-Server technisch erlaubte Ope­ra­tio­nen ausführen kann, obwohl diese für die ei­gent­li­che Aufgabe nicht er­for­der­lich oder nicht erwünscht sind. Eine Schwach­stel­le im MCP-Protokoll ist dafür nicht notwendig.

Da­ten­ex­fil­tra­ti­on durch externe Tools und Netz­werk­zu­grif­fe

Neben un­er­wünsch­ten Da­tei­zu­grif­fen besteht das Risiko, dass ver­trau­li­che In­for­ma­tio­nen das lokale System verlassen. Dieser Vorgang wird als Da­ten­ex­fil­tra­ti­on be­zeich­net. Besonders kritisch ist es, wenn eine KI-Anwendung sowohl auf sensible Dateien als auch auf Tools mit externen Kom­mu­ni­ka­ti­ons­mög­lich­kei­ten zugreifen kann. Bei­spiels­wei­se können aus­ge­le­se­ne Zu­gangs­da­ten über ein zu­sätz­lich ein­ge­bun­de­nes Tool mit Netz­werk­zu­griff an einen externen Server über­tra­gen werden. Dafür benötigt der MCP-File­sys­tem-Server selbst keine Schreib­rech­te.

Ein weiterer möglicher Über­tra­gungs­weg entsteht beim Einsatz cloud­ba­sier­ter LLMs. Werden lokale Da­tei­in­hal­te in Mo­dell­an­fra­gen ein­ge­bun­den, können diese In­for­ma­tio­nen an den externen Mo­dell­an­bie­ter gelangen. Ob dies zulässig ist, hängt von den ver­ar­bei­te­ten Daten und den geltenden Da­ten­schutz­an­for­de­run­gen ab.

Wie lässt sich die MCP-Server-Security ver­bes­sern?

Für einen sicheren MCP-Betrieb sollten mehrere Schutz­me­cha­nis­men kom­bi­niert werden. Im Mit­tel­punkt stehen minimale Be­rech­ti­gun­gen, klar de­fi­nier­te Da­tei­sys­tem­gren­zen, die Isolation des Ser­ver­pro­zes­ses und die Kontrolle kri­ti­scher Tool-Aufrufe.

Minimale Be­rech­ti­gun­gen nach dem Least-Privilege-Prinzip

Das Prinzip der ge­rings­ten Pri­vi­le­gi­en besagt, dass Prozesse nur die Be­rech­ti­gun­gen erhalten sollten, die sie zur Erfüllung ihrer Aufgaben benötigen. Ein MCP-Server, der Dokumente aus­schließ­lich ana­ly­sie­ren soll, benötigt bei­spiels­wei­se keine Schreib­rech­te. Solche Rechte sollten deshalb nicht nur auf An­wen­dungs­ebe­ne aus­ge­schlos­sen, sondern auch durch Be­triebs­sys­tem­be­rech­ti­gun­gen oder schreib­ge­schütz­te Da­tei­sys­tem-Mounts wirksam un­ter­bun­den werden.

Zu­sätz­lich empfiehlt es sich, MCP-Server unter einem separaten Be­nut­zer­kon­to mit ein­ge­schränk­ten Zu­griffs­rech­ten aus­zu­füh­ren. Unter Linux lassen sich die Datei- und Ver­zeich­nis­rech­te mit chmod gezielt anpassen. Dadurch wird vermieden, dass ein Server au­to­ma­tisch sämtliche Be­rech­ti­gun­gen des an­ge­mel­de­ten Be­nut­zer­kon­tos übernimmt.

Da­tei­zu­grif­fe durch Pfad­be­schrän­kun­gen begrenzen

Neben den all­ge­mei­nen Da­tei­sys­tem­rech­ten sollte fest­ge­legt werden, welche Ver­zeich­nis­se ein MCP-Server überhaupt verwenden darf. Beim so­ge­nann­ten Al­low­lis­ting ist der Zugriff aus­schließ­lich auf aus­drück­lich frei­ge­ge­be­ne Pfade be­schränkt. Eine sichere Im­ple­men­tie­rung muss außerdem prüfen, ob an­ge­for­der­te Da­tei­pfa­de nach ihrer Auflösung innerhalb dieser Grenzen liegen. Das ist ins­be­son­de­re bei relativen Pfaden, sym­bo­li­schen Links und so­ge­nann­ten Path-Traversal-Angriffen wichtig, bei denen bei­spiels­wei­se durch ../ auf über­ge­ord­ne­te Ver­zeich­nis­se zu­ge­grif­fen werden soll. Frühere Si­cher­heits­lü­cken im of­fi­zi­el­len MCP-File­sys­tem-Server zeigen, dass feh­ler­haf­te Pfad­prü­fun­gen oder eine un­zu­rei­chen­de Kontrolle sym­bo­li­scher Links die vor­ge­se­he­nen Zu­griffs­be­schrän­kun­gen aushebeln können.

Der of­fi­zi­el­le MCP-File­sys­tem-Server un­ter­stützt die Kon­fi­gu­ra­ti­on erlaubter Ver­zeich­nis­se über Start­ar­gu­men­te und die ältere Roots-Funktion. Dabei ist eine Be­son­der­heit zu beachten: Laut Do­ku­men­ta­ti­on des of­fi­zi­el­len MCP-File­sys­tem-Servers können vom Client gemeldete Roots die über Start­ar­gu­men­te fest­ge­leg­ten Ver­zeich­nis­se voll­stän­dig ersetzen. Welche Ver­zeich­nis­se tat­säch­lich frei­ge­ge­ben sind, lässt sich mit list_allowed_directories über­prü­fen.

Um beim Start des File­sys­tem-Servers ein Pro­jekt­ver­zeich­nis als erlaubten Pfad fest­zu­le­gen, verwenden Sie bei­spiels­wei­se folgenden Befehl:

npx -y @modelcontextprotocol/server-filesystem@<VERSION> /home/mcp/projekt

Ersetzen Sie <VERSION> durch eine geprüfte, aktuelle Pa­ket­ver­si­on und /home/mcp/projekt durch den Pfad zum ge­wünsch­ten Ver­zeich­nis. Der gezeigte Pfad ist ein Linux-Beispiel – unter Windows muss ein ent­spre­chen­der Windows-Pfad angegeben werden.

Der Server erhält damit eine an­wen­dungs­sei­ti­ge Pfad­be­schrän­kung. Diese ersetzt jedoch keine Be­triebs­sys­tem­be­rech­ti­gun­gen. Zu­sätz­lich muss geprüft werden, welche Ver­zeich­nis­se der Client tat­säch­lich freigibt und welche Rechte der Ser­ver­pro­zess besitzt. Die feste Pa­ket­ver­si­on ver­hin­dert, dass beim Start un­be­ab­sich­tigt eine andere Version des MCP-Servers verwendet wird.

MCP-Server durch Sand­boxing isolieren

Beim Sand­boxing wird ein MCP-Server in einer ein­ge­schränk­ten Aus­füh­rungs­um­ge­bung betrieben. Dadurch lassen sich die er­reich­ba­ren Dateien, Prozesse und Netz­werk­res­sour­cen begrenzen:

• Eine Mög­lich­keit ist der Einsatz eines Docker-Con­tai­ners. Dabei werden nur die be­nö­tig­ten Ver­zeich­nis­se ein­ge­bun­den, möglichst schreib­ge­schützt. Zu­sätz­lich können Linux-Si­cher­heits­me­cha­nis­men wie Seccomp, AppArmor oder SELinux ein­ge­setzt und unnötige Netz­werk­ver­bin­dun­gen un­ter­bun­den werden.
• Auch We­b­As­sem­bly kann bei ge­eig­ne­ten MCP-Ser­ver­im­ple­men­tie­run­gen eine isolierte Lauf­zeit­um­ge­bung be­reit­stel­len. Welche Zugriffe möglich sind, hängt dabei von der ver­wen­de­ten Laufzeit und ihren frei­ge­ge­be­nen Funk­tio­nen ab.

Wichtig ist, dass Container nicht au­to­ma­tisch eine voll­stän­di­ge Si­cher­heits­gren­ze dar­stel­len. Werden bei­spiels­wei­se um­fang­rei­che Host-Ver­zeich­nis­se ein­ge­bun­den oder pri­vi­le­gier­te Container verwendet, kann die Schutz­wir­kung erheblich ein­ge­schränkt sein. Gleiches gilt für einfache chroot-Um­ge­bun­gen, die allein keine um­fas­sen­de Pro­zes­s­iso­la­ti­on ge­währ­leis­ten.

Kritische Da­tei­ope­ra­tio­nen manuell freigeben

Beim Human-in-the-Loop-Ansatz wird ein Mensch in si­cher­heits­re­le­van­te Ent­schei­dun­gen ein­ge­bun­den. Vor kri­ti­schen Tool-Aufrufen sollte die KI-Anwendung eine aus­drück­li­che Be­stä­ti­gung einholen. Dies ist ins­be­son­de­re bei Ope­ra­tio­nen sinnvoll, die Dateien über­schrei­ben, löschen, ver­schie­ben oder um­fang­reich verändern. Die Freigabe sollte erkennen lassen, welches Tool auf­ge­ru­fen wird, welche Datei betroffen ist und welche Änderung vor­ge­nom­men werden soll.

Manuelle Be­stä­ti­gun­gen sind al­ler­dings nur eine zu­sätz­li­che Si­cher­heits­ebe­ne. Sie können tech­ni­sche Zu­griffs­be­schrän­kun­gen nicht ersetzen, da auch frei­ge­ge­be­ne Ope­ra­tio­nen un­be­ab­sich­tig­te Folgen haben können.

MCP-Server-Security und Da­ten­schutz: Lokale vs. Cloud-LLMs

Der lokale Betrieb eines MCP-Servers bedeutet nicht zwangs­läu­fig, dass sämtliche Daten auf dem eigenen System ver­blei­ben. Ent­schei­dend ist, wo das Sprach­mo­dell aus­ge­führt wird und welche In­for­ma­tio­nen die KI-Anwendung an externe Dienste über­mit­telt.

• Bei einem Cloud-LLM werden Mo­dell­an­fra­gen an einen externen Anbieter über­tra­gen. Enthalten diese Anfragen In­for­ma­tio­nen aus lokalen Dateien, verlassen mög­li­cher­wei­se auch ver­trau­li­che Un­ter­neh­mens­da­ten oder per­so­nen­be­zo­ge­ne In­for­ma­tio­nen die eigene In­fra­struk­tur.
• Ein lokales LLM kann dagegen voll­stän­dig innerhalb der eigenen IT-Umgebung betrieben werden. Zusammen mit einem lokalen MCP-Server lässt sich so eine Ar­chi­tek­tur aufbauen, bei der Da­tei­in­hal­te nicht für die Mo­dell­ver­ar­bei­tung an externe Anbieter über­tra­gen werden müssen. Vor­aus­set­zung ist, dass auch andere Kom­po­nen­ten keine ent­spre­chen­den Daten nach außen senden.

Sensible In­for­ma­tio­nen vor der Über­mitt­lung filtern

Soll ein Cloud-LLM verwendet werden, können lokale Proxy-Server mit Fil­ter­funk­tio­nen als zu­sätz­li­che Schutz­schicht dienen. Sie prüfen In­for­ma­tio­nen vor der Über­mitt­lung an den Mo­dell­dienst und können bei­spiels­wei­se bestimmte Zu­gangs­da­ten, per­so­nen­be­zo­ge­ne In­for­ma­tio­nen oder ver­trau­li­che Text­pas­sa­gen entfernen be­zie­hungs­wei­se maskieren.

Solche Filter re­du­zie­ren das Risiko un­be­ab­sich­tig­ter Da­ten­wei­ter­ga­ben. Sie erkennen jedoch nicht zu­ver­läs­sig sämtliche schüt­zens­wer­ten In­for­ma­tio­nen. Deshalb sollten sensible Dateien möglichst bereits durch re­strik­ti­ve Zu­griffs­rech­te von der Ver­ar­bei­tung aus­ge­schlos­sen werden. Für die Data Go­ver­nan­ce sind außerdem klare Vorgaben zur Ver­ar­bei­tung, Pro­to­kol­lie­rung und Auf­be­wah­rung der Daten er­for­der­lich. Auch die Be­rech­ti­gun­gen weiterer ein­ge­bun­de­ner Tools und mögliche Netz­werk­zu­grif­fe müssen be­rück­sich­tigt werden.

Ein voll­stän­dig lokal be­trie­be­nes LLM kann die Kontrolle über die Ver­ar­bei­tung sensibler Daten ver­bes­sern. Eine au­to­ma­ti­sche DSGVO-Kon­for­mi­tät ergibt sich daraus jedoch nicht. Auch lokale An­wen­dun­gen müssen die jeweils geltenden Da­ten­schutz­an­for­de­run­gen erfüllen.

Check­lis­te für einen sicheren MCP-Server

Das Model Context Protocol er­mög­licht leis­tungs­fä­hi­ge In­te­gra­tio­nen zwischen KI-An­wen­dun­gen und lokalen Da­tei­sys­te­men. Die damit ver­bun­de­nen Risiken lassen sich jedoch nur durch geeignete Schutz­maß­nah­men begrenzen. MCP selbst ga­ran­tiert weder eine sichere Da­tei­sys­temiso­la­ti­on noch den Schutz vor Prompt In­jec­tions. Ent­schei­dend sind ins­be­son­de­re minimale Be­rech­ti­gun­gen, zu­ver­läs­sig durch­ge­setz­te Ver­zeich­nis­gren­zen und die Isolation des MCP-Servers. Er­gän­zen­de Frei­ga­be­pro­zes­se und eine kon­trol­lier­te Da­ten­ver­ar­bei­tung erhöhen die Si­cher­heit.

Vor dem pro­duk­ti­ven Einsatz eines MCP-Servers sollten Ent­wick­le­rin­nen und Ent­wick­ler folgende Punkte über­prü­fen:

✓ Stammt der MCP-Server aus einer ver­trau­ens­wür­di­gen Quelle, ist seine Software aktuell und erhält der Prozess nur die er­for­der­li­chen Um­ge­bungs­va­ria­blen und Zu­gangs­da­ten?

✓ Sind nur die er­for­der­li­chen Tools und Da­tei­sys­tem­be­rech­ti­gun­gen aktiviert?

✓ Sind die erlaubten Ver­zeich­nis­se eindeutig fest­ge­legt und tat­säch­lich wirksam?

✓ Sind sensible Dateien und Ver­zeich­nis­se vom Zugriff aus­ge­schlos­sen?

✓ Werden sym­bo­li­sche Links und Pfad­um­ge­hun­gen sicher behandelt?

✓ Ist der Ser­ver­pro­zess aus­rei­chend isoliert und sind Netz­werk­zu­grif­fe be­schränkt?

✓ Müssen kritische Schreib- und Lösch­ope­ra­tio­nen aus­drück­lich bestätigt werden?

✓ Ist geklärt, welche Da­tei­in­hal­te an externe Mo­dell­an­bie­ter über­mit­telt werden?

✓ Sind Pro­to­kol­lie­rung, Da­ten­auf­be­wah­rung und Zu­griffs­rech­te geregelt?

✓ Wurden Prompt In­jec­tions und un­zu­läs­si­ge Da­tei­zu­grif­fe vor dem De­ploy­ment getestet?

Eine sorg­fäl­ti­ge Kon­fi­gu­ra­ti­on und re­gel­mä­ßi­ge Über­prü­fung der Si­cher­heits­maß­nah­men bilden die Grundlage für einen kon­trol­lier­ten MCP-Da­tei­zu­griff.