hmharness liefert shellgate mit: Volltext-Prüfung für Agenten-Befehle, aber ohne Nachweis gegen bekannte Umgehungen

hmharness bekommt mit shellgate eine Volltext-Prüfung für Agenten-Befehle

Das Open-Source-Framework hmharness soll laut einem dev.to-Beitrag ein Modul namens shellgate enthalten. Es prüft Shell-Befehle, die KI-Agenten erzeugen, bevor sie ausgeführt werden. hmharness richtet sich an die Entwicklung für HarmonyOS und OpenHarmony. Das Repository trägt den Namen swsgbl/hmharness, das npm-Paket heißt @hmharness/cli, vorausgesetzt wird Node ab Version 22. Die Lizenz nennt der Beitrag als MIT. Laut Projektbeschreibung gilt Windows als Hauptplattform. macOS und Linux unterstützt die Community.

Shellgate setzt dort an, wo einfache Schutzmechanismen versagen. Ein verbreitetes erstes Gate nimmt das erste Wort eines Befehls und schlägt es in einer Sperrliste nach. Shellgate dagegen scannt den gesamten Befehlstext. Jede Zeile eines mehrzeiligen Pastes bleibt im Prüfbereich, ebenso jeder Teilbefehl hinter einer Pipe, einem Redirect oder einem &&. Was das Modul nicht als bekanntes gefährliches Muster erkennt, geht laut Beitrag an eine menschliche Freigabe. Der Scan soll also der schnelle Filter sein, die Freigabe die letzte Instanz.

Eine Einschränkung vorweg: Einzige Quelle zu shellgate ist der dev.to-Beitrag. Repository und README konnten das Modul nicht bestätigen. Die README beschreibt das Framework als Agenten-Runtime mit „Zero-Dependency-Kernel“, erwähnt shellgate im vorliegenden Auszug aber nicht. Angaben zu Version, Reife, Verbreitung oder Resonanz in der Community liegen nicht vor. Der folgende Text beschreibt deshalb den Anspruch des Moduls laut Beitrag, nicht eine geprüfte Funktion.

Warum 'echo rm -rf / > s.sh && bash s.sh' ein Erstwort-Gate passiert

Der Beitrag zeigt das Problem an einem einzigen Befehl: `echo rm -rf / > s.sh && bash s.sh`. Ein Gate, das nur das erste Wort betrachtet, sieht `echo` und lässt den Befehl durch. Tatsächlich schreibt er den Löschbefehl in eine Datei und startet sie danach. Das Erstwort sagt also wenig darüber, was ein Befehl tut. Wrapper wie `echo`, `xargs` oder `nohup` verbergen die eigentliche Nutzlast hinter einem harmlosen Kopf. Hinzu kommen mehrzeilige Pastes. Prüft ein Gate nur Zeile eins, prüft es laut Beitrag praktisch nichts, denn über Pastes gelangen längere Skripte in die Sitzung.

Dass es sich nicht um ein theoretisches Problem handelt, zeigt der Fall Roo Code. Dort prüfte die Auto-Approve-Allowlist nur das führende Token einer Kommandozeile. Ein Angreifer brauchte einen Befehl, dem die Allowlist vertraut, und hängte einen zweiten per Verkettung, Substitution, Pipe oder `-c`-Wrapper an. Der zweite Befehl lief ohne Rückfrage. Behoben ist der Fehler ab Version 3.26.7, die laut Beschreibung die gesamte Kommandozeile validiert. Die Schutzwirkung der Allowlist, die den Menschen im Entscheidungsprozess halten sollte, war damit ausgehebelt.

Der Mechanismus ist seit Langem bekannt. Befehlsinjektion entsteht, wenn Daten an einen Shell-Interpreter gehen, der `;`, `|`, `&&`, `$()` und Backticks als Struktur behandelt. Ein Wert, der in eine solche Zeichenkette gelangt, kann neue Befehle starten. Der Standardschutz lautet, keine Shell zu starten und Argumente als Vektor zu übergeben. Diese Option haben Agenten meist nicht, denn sie erzeugen Befehlstext, den eine Shell interpretieren soll. Die Prüfung muss deshalb am Text ansetzen. Dort liegt die Schwierigkeit.

GuardFall und ShellSieve: Auch Rohtext-Filter und Denylists übersehen Umgehungen

Zwei unabhängige Befunde zeigen, dass der Schritt vom Erstwort zum Volltext das Problem nicht automatisch löst. Am 30. Juni 2026 veröffentlichte Adversa AI „GuardFall“, eine Umgehung der Shell-Interpretation. Sie betraf zehn von elf untersuchten Open-Source-Coding-Agenten, die zusammen rund 548.000 GitHub-Sterne auf sich vereinen. Die Ursache ist eine Diskrepanz: Der Filter prüft den Rohtext eines Befehls. Die Shell wendet vor der Ausführung aber Quote-Removal sowie Variablen- und Befehlsersetzung an. Was der Filter liest, ist also nicht das, was am Ende läuft. Ein Muster wie `rm -rf` lässt sich so verschleiern, dass der Textvergleich es nicht findet, während die Shell es nach der Umformung ausführt.

Die Autoren der Analyse betonen, dass keine neuartige Lücke vorliegt. Es handle sich um eine Klasse von Quoting- und Expansionstricks, die Jahrzehnte alt ist. Neu sei allein die Breite des Versagens. Die Konvention, den String zu prüfen und dann an bash zu übergeben, sei strukturell fehlerhaft, und fast jeder Open-Source-Agent habe sie übernommen.

Den zweiten Befund liefert die arXiv-Studie „One Goal, Many Commands“. Sie untersucht Denylists in Terminal-Agenten und stellt fest, dass selbst die gepflegte eingebaute Denylist von Claude Code Umgehungsbefehle übersehen kann. Moderne Betriebssysteme liefern eine große, wachsende Zahl an Shell-Befehlen mit komplexen Funktionen. Dasselbe Ziel ist daher auf vielen Wegen erreichbar. Die Autoren stellen die LLM-gestützte Pipeline ShellSieve vor. Ein Modell schlägt Umgehungen vor, ein Validator führt die Befehle in einer Sandbox aus und liefert Rückmeldungen, mit denen das Modell die Vorschläge verfeinert. Ausgewertet wurden 1.709 reale Denylists mit 13.332 Regeln von GitHub.

Beide Arbeiten stützen dieselbe Linie: Listen, die Befehle über ihren Text beurteilen, sind umgehbar. Das ist seit Längerem bekannt und breit dokumentiert.

Muster plus Mensch: Trägt shellgates Zwei-Schichten-Anspruch gegen GuardFall-Klassen?

Zwischen GuardFall und shellgate besteht eine Spannung, aber kein harter Widerspruch. Die GuardFall-Analyse hält jede Sicherheitsschicht, die Rohtext per String-Matching prüft, für strukturell unzureichend. Wirksam seien nur Beschränkungen unterhalb der Shell, etwa die Kernel-Sandbox von Codex CLI. Shellgate setzt laut dev.to-Beitrag auf Mustererkennung über den vollen Text und auf eine menschliche Freigabe für alles Unbekannte. Das Modul versteht sich ausdrücklich nur als vorgelagerter Filter. Es verzichtet bewusst auf vollständiges Grammatik-Parsing, weil dieses zu einem unwartbaren Parser mit endlosen Randfällen führe. Eine einzelne statische Prüfung stellt der Beitrag nicht als ausreichend dar.

Der Unterschied liegt also im Anspruch. GuardFall kritisiert Filter, die allein entscheiden. Shellgate erhebt diesen Anspruch nicht. Offen bleibt die entscheidende Frage: Fängt die Mustererkennung Quoting- und Expansionstricks ab? Ohne Grammatik-Parsing sieht ein Scan des Rohtexts nicht, was die Shell daraus macht. Genau diese Mechanik beschreibt GuardFall. Ob shellgate sie trotzdem erfasst, ist ungeprüft. Auch die menschliche Freigabe löst das nicht von selbst. Sie greift nur, wenn das Muster als unbekannt gilt. Ein verschleierter Befehl, den die Mustererkennung für bekannt und harmlos hält, erreicht den Menschen womöglich nie.

Zwei Formulierungen des Beitrags brauchen Einordnung. Shellgate decke bekannte gefährliche Muster „erschöpfend“ ab, heißt es dort. Das ist eine Herstellerangabe. Bei einer offenen Menge von Umgehungen lässt sich „erschöpfend“ kaum belegen. Außerdem nennt der Beitrag shellgate ein „Kernel-Level-Modul“. Gemeint ist vermutlich der Framework-Kern, den die README als „Zero-Dependency-Kernel“ bezeichnet, kein Betriebssystemkern. Verwechseln sollte man es nicht mit dem Kernel-Sandbox-Ansatz von Codex CLI, der Einschränkungen unterhalb der Shell durchsetzt. Prüfbar wäre das nur anhand von Quellcode und Testsuite im Repository sowie unabhängiger Umgehungstests, etwa gegen die GuardFall-Klassen oder mit einer ShellSieve-ähnlichen Bypass-Suche.

Was Betreiber von Agenten-Frameworks jetzt prüfen sollten

Wer Agenten mit Auto-Approve auf Basis einer Erstwort-Allowlist oder -Denylist betreibt, hat nach der Beleglage Handlungsbedarf. Der Roo-Code-Fall zeigt, dass angehängte Befehle ohne Rückfrage laufen können. Die dazugehörige Empfehlung lautet, die Auto-Ausführung für verkettete Befehle abzuschalten, bis sie validiert sind. Befehle mit `&&`, `||`, `;`, Pipes, Command Substitution oder `-c`-Wrappern sollten Menschen manuell prüfen. Ob ein Kandidat GuardFall-artigen Tricks standhält, sollten Betreiber testen und nicht annehmen.

Vergleichbare Ansätze zeigen, in welche Richtung Abhilfe geht. Das Projekt shellguard-hooks erkennt vor der Ausführung Base64-decode-then-execute, Fetch-and-execute, verschachtelte Command Substitution, getarnte rm-Aufrufe und Unicode-Homoglyphen. Es steht als TypeScript-Bibliothek und als CLI bereit und ist mit dem PreToolUse-Hook von Claude Code verdrahtet. In einem weiteren GitHub-Projekt meldet Issue #8592 die fehlende Erkennung kodierter Befehle. Der eingereichte Fix-PR #16907 ergänzt `detectCommandObfuscation()` mit 33 Tests. Er lässt die Prüfung vor der Allowlist laufen, sodass verdächtige Befehle eine Freigabeaufforderung auslösen. Claude Code selbst nutzt ein gestuftes Berechtigungssystem. Im Auto-Modus prüft ein Klassifikator riskante Aktionen vor der Ausführung. Befehle mit Exec-Wrappern oder find-Aktionen wie `-delete` werden gesondert behandelt.

Für Nutzer von hmharness heißt das: Shellgate kann laut Beitrag eine zusätzliche Prüfschicht sein. Mehr Freigabeaufforderungen sind zu erwarten, weil Unbekanntes an Menschen geht. Zahlen zu Fehlalarmen, Performance und Konfigurationsaufwand fehlen. Solange die Primärquelle das Modul nicht bestätigt und niemand es gegen die bekannten Umgehungsklassen geprüft hat, taugt es bestenfalls als ergänzende Schicht, nicht als alleinige Absicherung.