KI-Agent mit Root-Zugang: Warum das MCP-Sicherheitsmodell versagt
TL;DR
Wer einen Postgres-MCP-Server einbindet, bekommt nicht nur Leserechte – sondern auch DELETE, DROP TABLE und beliebiges SQL mitgeliefert, ohne Möglichkeit zur Einschränkung.
Key Points
- GitHub-MCP für Code-Lesen? Kommt mit delete_repository. Slack-MCP für Suche? Bringt remove_user und delete_channel gleich mit.
- Ein Scan von 1.808 MCP-Servern ergab: 66 % hatten Sicherheitslücken, 30 CVEs in 60 Tagen, 76 veröffentlichte Skills enthielten Malware – 5 der 7 meistgeladenen Skills waren schädlich.
- Claude, Cursor, ChatGPT – überall dasselbe Prinzip: alles oder nichts. Ein granulares Rechtemodell existiert in keinem der großen Systeme.
- Aerostack hat das Problem mit einem eigenen Gateway gelöst: pro Tool ein Toggle, destruktive Operationen standardmäßig geblockt, durchgesetzt auf Proxy-Ebene.
Nauti's Take
Das ist kein Edge Case, das ist Systemdesign-Versagen auf breiter Front. Wenn 5 von 7 meistgeladenen Skills Malware sind, hat das Ökosystem kein Sicherheitsproblem – es hat kein Sicherheitskonzept.
Die Plattformanbieter haben hier eine klare Verantwortung, die sie bislang an die Community ausgelagert haben. Workarounds auf Gateway-Ebene wie bei Aerostack sind clever, aber das ist Symptombekämpfung.
Solange die großen Anbieter kein natives, granulares Tool-Permission-Modell liefern, ist jeder Produktiveinsatz von MCP-Agenten ein kalkuliertes Risiko – und die meisten Teams kalkulieren es gerade nicht.
Quellen