Stresserbse Blog

Tja... der Hype um KI-gestütztes Coding ist real. Aber jedes Mal, wenn ich sehe, wie Entwickler freudestrahlend ganze Repositories, API-Keys und firmeninterne Architektur-Dokumente in Cloud-LLMs wie ChatGPT oder Claude pumpen, stellen sich mir die Nackenhaare auf. WTF?

Do you really want to send your crown jewels to a server you don't control?

Deshalb habe ich mich in den letzten Wochen intensiv mit lokalen LLMs und der Integration in VS Code via MCP (Model Context Protocol) beschäftigt. Mein Fazit? Man gewinnt massive Unabhängigkeit und Datensicherheit, holt sich aber potenziell völlig neue Angriffsvektoren direkt ins private Netzwerk. SNAFU is incoming, if you don't pay attention.

1. Cloud vs. Local: The Ultimate Air-Gap

Warum den Aufwand betreiben und eine RTX 3080 stundenlang schwitzen lassen? Ganz einfach: Data Exfiltration.

Nutzt du Cloud-Modelle, bist du darauf angewiesen, dass der Anbieter (und dessen Subunternehmer) deine Prompts und Code-Snippets wirklich löscht und nicht für das nächste Training verwendet. Für ein kleines Hobby-Skript? Okay. Für den proprietären Backend-Code deines Arbeitgebers? Geht gar nicht.

Eine lokale KI (z.B. DeepSeek Coder oder Llama 3.1 running via Ollama) funkt nicht nach Hause. Es ist das perfekte, air-gapped "Brain" für deinen Editor. Die Daten verlassen die Maschine nicht. Punkt.

2. Halluzinationen als Security-Risiko

Lokale Modelle haben jedoch oft ein kleineres Kontext-Fenster und sind anfälliger für Halluzinationen. Und genau hier liegt eine massive Gefahr.

Lass uns einen konkreten Testaufbau anschauen: Ich habe ein Skript verlangt, das eine .zst Datei (RedHat VEX Data) herunterlädt und entpackt.

Während ein mächtiges Cloud-Modell das sauber über die externe zstandard Library gelöst hat, halluzinierte das lokale Modell folgenden Code:

import tarfile
# EPIC FAIL incoming
with tarfile.open(file_path, "r:zstd") as tar:
    tar.extractall()

Das Standard tarfile-Modul in Python kann out-of-the-box gar kein natives Zstandard. Das Skript crasht.

Das Security Issue hier: Was passiert, wenn das Modell eine real existierende, aber bösartige Library halluziniert (Typosquatting)? Wenn du dem Agenten erlaubst, eigenständig pip install auszuführen, lädst du dir potenziell Malware auf die Kiste. Supply Chain Attack by Hallucination.

3. MCP (Model Context Protocol) – Designt für RCE?

Um die KI in VS Code nützlich zu machen, nutzt man das Model Context Protocol (MCP). Es ist ein offener Standard, der auf JSON-RPC basiert und der KI Werkzeuge (Tools) in die Hand drückt.

Die KI sagt: "Ich muss eine Datei lesen." Der MCP-Server führt view_file aus und gibt den Inhalt zurück.

Klingt genial, oder? Ist es auch. Aber schau dir an, welche Tools so ein MCP-Server für Full-Agentic-Coding bereitstellen muss: * read_file / write_file * run_command (direkte Shell-Ausführung!) * search_web

Wenn du einen MCP-Server betreibst und seinen Port versehentlich auf 0.0.0.0 bindest, anstatt strikt auf localhost oder über lokale Standard-I/O Pipes zu kommunizieren, hast du quasi eine RCE (Remote Code Execution) API für jeden im Netzwerk geöffnet. Herzlichen Glückwunsch. Du hast dich selbst pwnd.

4. Isolation & Execution Contexts

Wenn du eine lokale KI "machen lässt" (Direct Agent Mode), brauchst du Isolation.

VENV is mandatory: Lass die KI niemals im System-Python operieren. Wenn das Modell einen wilden pip install oder rm -rf Befehl absetzt (absichtlich oder durch Halluzination), ist dein Core-OS sonst im Eimer.
Directory Traversal: Dein MCP-Server muss zwingend prüfen, ob Pfade aus den Workspace-Grenzen ausbrechen. Ein view_file("/etc/shadow") darf niemals durchgehen.

In meiner eigenen Extension (llmgui) habe ich den Workspace-Root hart verankert. Egal was das Modell will, es kommt aus dem Projektordner nicht heraus.

5. Human in the Loop (HITL) als Letzte Verteidigungslinie

Hier trennt sich die Spreu vom Weizen. Ein autonomer LLM-Agent ist eine tickende Zeitbombe im Dateisystem. Der Ansatz, den ich verfolge, bricht das Ganze in zwei Phasen auf: Planning & Refinement vs. Execution.

Bevor überhaupt Code generiert oder Shell-Commands abgefeuert werden, muss das System einen Plan vorlegen.

Tool call: run_command("rm -rf ./build")

An diesem Punkt greift bei mir ein striktes Auto-Approve / Deny System. Bevor der MCP-Server diesen Command an die Bash weiterreicht, muss ich manuell bestätigen. Das ist dein "Air-Gap" für Executions.

Wer diesen Schritt überspringt und der KI blinden Schreib-/Exec-Zugriff auf das eigene Dateisystem gibt... Tja. Selbst schuld. ;)

Fazit

Lokale KIs für das Coding sind machbar und bieten unglaubliche Vorteile beim Datenschutz. Aber die Integrationstools – allen voran MCP und autonome Agenten-Frameworks – sind extrem scharfe Schwerter. Man muss die Architektur dahinter genau verstehen, Isolation erzwingen und einen robusten Bestätigungs-Workflow etablieren.

Trust nobody. Not even your local LLM.