Zum Inhalt springen

Befehlszeilen-Werkzeuge (CLI) im Assistenten — Überblick & Grenzen

Anwender

Manche Aufgaben erledigt der Assistent nicht über eine eingebaute Funktion, sondern indem er ein externes Kommandozeilen-Programm (eine CLI) aufruft — etwa ein Versions- oder Konvertierungswerkzeug. Dieses CLI-Befehlswerkzeug ist bewusst eng geführt: Es läuft nur in der Desktop-Variante, startet ausschließlich geprüfte, gepinnte Programme und führt nichts Zustandsänderndes aus, ohne dass Sie es vorher freigegeben haben.

  • Skill-gesteuert. Der Assistent ruft ein CLI nur im Rahmen einer dafür vorgesehenen Fähigkeit auf, nicht spontan.
  • Manifest statt Shell. Jeder Aufruf ist als Manifest beschrieben — Programm plus Argumente als feste Liste (argv). Der Assistent setzt niemals eine freie Shell-Zeile zusammen; es gibt kein sh -c, Argumente werden geprüft, nicht zusammengebaut.
  • Nur Desktop. Das Werkzeug gibt es ausschließlich in der Desktop-Variante. → Zwei Bereitstellungsmodi — Web vs. Desktop
  • Nur gepinnte Programme. Es starten nur Programme, die in einer Allowlist mit fester Version und geprüfter Prüfsumme hinterlegt sind. Die Einrichtung beschreibt das Admin-Howto → CLI-Werkzeug freigeben, pinnen & Lizenz prüfen.

Wie bei allen Werkzeugen zählt die Wirkung (→ Werkzeuge des Assistenten — Überblick & Modell):

  • Lesende Aufrufe rufen nur Informationen ab und verändern nichts.
  • Schreibende oder netzende Aufrufe — alles, was etwas verändert oder ins Netz greift — werden Ihnen vorher angezeigt. Im Trockenlauf sehen Sie das exakte Kommando (argv), das ausgeführt würde, bevor es ausgeführt wird.

Bevor ein zustandsänderndes oder netzendes Kommando startet, erscheint der Freigabe-Dialog: Er zeigt das exakte argv und den Trockenlauf. Erst nach Ihrer Freigabe läuft das Kommando. Diese menschliche Freigabe (human-in-the-loop) ist keine Formalie, sondern die zentrale Sicherheitsgrenze des Werkzeugs.

Der Ausgabetext eines Laufs läuft anschließend durch den PII-Schild, bevor ihn der Assistent oder Sie zu sehen bekommen. → Der PII-Schild

Das Werkzeug grenzt jeden Lauf ein, so gut es ohne virtuelle Maschine geht — die Garantie ist best-effort Containment plus Egress-Kontrolle, ausdrücklich keine VM-Isolation. Auf eine gebündelte virtuelle Maschine wurde bewusst verzichtet, weil sie sich in Unternehmen oft nicht ausrollen lässt (Hypervisor per Richtlinie deaktiviert, keine lokalen Adminrechte). Stattdessen wird der Host-Prozess gehärtet.

Die tragende Sicherheitsgrenze ist Credential-Scoping + Ihre Freigabe (HITL), nicht die Betriebssystem-Sandbox. Ein Werkzeug sieht nur die Zugangsdaten, die ihm ausdrücklich zugeordnet sind, und ein verändernder Lauf startet erst nach Ihrer Freigabe.

Was das Containment durchsetzt:

  • Schreiben nur im deklarierten Arbeitsordner, Lesen nur in den deklarierten Wurzeln.
  • Kein Netzzugriff, außer eine Host-Allowlist erlaubt ihn ausdrücklich (alles andere ist gesperrt).
  • Zeitlimit mit Abbruch des gesamten Prozessbaums.
  • Ausgabe durch den PII-Schild; jeder Lauf erzeugt einen Audit-Eintrag.

Was es ausdrücklich nicht leistet (ehrliche Abgrenzung statt Überversprechen):

  • Kein Schutz gegen einen Kernel-Ausbruch durch einen entschlossenen lokalen Angreifer — die Sandbox hebt die Hürde, ist aber kein Perimeter, auf den man ein feindliches Programm setzen sollte.
  • Keine Ausführung nicht vertrauenswürdigen Codes — gebündelte CLIs sind geprüfte, gepinnte Programme, keine beliebigen Binaries.
  • Keine mandantenfähige Ausführung — der Web-Modus ist deshalb bewusst ausgeschlossen; das Werkzeug ist Desktop-only, ein Nutzer auf der eigenen Maschine.

In einem Satz: Sandboxed, rechte-minimierte Kommando-Ausführung mit Default-Deny-Netzwerk und verpflichtender menschlicher Freigabe — best-effort OS-Containment, keine virtuelle Maschine.