llama.cpp kann Agent-Tools jetzt experimentell in einen Docker-Container auslagern. Das Release b10328 ergänzt llama-server um eine Runtime-Option, die eingebaute Datei- und Shell-Tools nicht mehr zwingend im Host-Kontext ausführt. Für lokale Agent-Stacks ist das ein sinnvoller Baustein – aber keine fertige Sicherheitsarchitektur.
Was im Release neu ist
Die am 8. August veröffentlichte Version b10328 nennt ausdrücklich „initial tool isolation support (via docker)“. Die zugehörige, gemergte Änderung dokumentiert zwei Varianten:
# pro Serverstart einen Container erzeugen und wiederverwenden
llama-server --agent --tools-runtime docker:ubuntu:jammy
# einen bereits existierenden Container verwenden
llama-server --agent --tools-runtime docker-container:<container-id>
Bei docker:<image> startet der Server einen neuen Container, nutzt ihn für alle Tool-Aufrufe und räumt ihn beim Beenden des Servers wieder auf. docker-container:<id> bindet dagegen einen bestehenden Container ein und stoppt ihn nicht. Laut Server-Dokumentation ist der Standard weiterhin none: Tools laufen dann in der Host-Umgebung.
Warum das operativ zählt
Mit eingebauten Agent-Tools aktiviert llama-server unter anderem Dateioperationen und exec_shell_command. Die neue Runtime trennt damit nicht das Modell vom Tool, sondern verschiebt die Ausführung in eine separat konfigurierbare Umgebung. Das ist genau die Grenze, die bei lokalen Coding- und Automationsagenten bisher häufig fehlte.
- Reproduzierbarkeit: Image und Laufzeit lassen sich pro Agent-Job festlegen.
- Schadensbegrenzung: Temporäre Dateien und Prozesse müssen nicht im Host-Dateisystem entstehen.
- Sauberere Zuständigkeiten: Das Team kann Tool-Images, Mounts und Netzwerkregeln als Infrastruktur-Code prüfen.
Docker ist hier kein Freifahrtschein
Die Funktion ist ausdrücklich experimentell. Entscheidend ist auch: Docker-Isolation ersetzt keine Policy. Ein Container mit bind-gemountetem Projektverzeichnis, weit geöffnetem Netzwerk, privilegierten Capabilities oder Zugriff auf den Docker-Socket kann den Sicherheitsgewinn weitgehend wieder verlieren. Ebenso bleiben Secrets, ausgehende Verbindungen und das Vertrauen in das verwendete Image eigene Kontrollpunkte.
Die sinnvolle Lesart des Releases ist nicht „Agenten sind jetzt sandboxed“, sondern: llama.cpp bietet erstmals einen konkreten Runtime-Hook, an dem Teams ihre eigene Ausführungsgrenze festmachen können.
Pragmatischer Startpunkt
Für einen ersten Test lohnt sich ein minimales, eigenes Image statt eines Allzweck-Containers: kein Docker-Socket, keine privilegierten Flags, nur ein expliziter Arbeits-Mount, ein nicht-root Benutzer und standardmäßig gesperrter Egress. Erst danach sollten Tool-Sets wie Shell- oder Schreibzugriff aktiviert werden. Die Dokumentation warnt ohnehin davor, eingebaute Tools oder den Agent-Modus in nicht vertrauenswürdigen Umgebungen zu aktivieren.
Einordnung
Der Schritt ist klein, aber für self-hosted Agenten relevanter als viele Modellparameter: Sobald ein lokaler LLM-Server Aktionen ausführen darf, wird seine Runtime Teil des Threat Models. b10328 liefert dafür eine experimentelle Docker-Anbindung – die Härtung bleibt jedoch Aufgabe des Betreibers.
Quellen
- llama.cpp Release b10328, veröffentlicht am 8. August 2026 (15:22 UTC).
- Pull Request #26507: server: add initial tool isolation support (via docker), gemergt am 8. August 2026.
- llama-server: Tool- und Runtime-Optionen.
Leave a Reply