HOL Guard: Open-Source-Virenschutz für KI-Agenten gegen bösartige MCP-Server und Skills

KI-Agenten verlassen das Chatfenster. Im vergangenen Jahr haben Programmierassistenten gelernt, Shell-Befehle auszuführen, lokale Dateien zu lesen und zu schreiben, Abhängigkeiten zu installieren und über Model-Context-Protocol-Server (MCP) externe Werkzeuge aufzurufen. Dieser Zuwachs an Fähigkeiten wirft eine schlichte, aber scharfe Frage auf: Wenn ein Programm, das sich per Prompt lenken lässt, die Rechte Ihres Terminals hält, wer steht dann am Tor? HOL Guard, ein Open-Source-Projekt von hashgraph-online, antwortet mit einer unverblümten Positionierung: ein Open-Source-Virenschutz für KI-Agenten. Das Projekt versucht nicht, das Modell gehorsamer zu machen. Stattdessen setzt es eine lokale, vom Modell unabhängige Schicht vor jede Aktion, die sie prüft, bevor die Aktion wirkt. Der Gedanke gehört in die Familie der mehrstufigen Endpunktverteidigung. Geändert hat sich nur das Prüfobjekt: Es ist nicht mehr die ausführbare Datei, sondern jeder einzelne Schritt eines Agenten.

Das Funktionsprinzip ist die Prüfung vor der Ausführung. Im Blick sind Shell-Befehle, Dateizugriffe, Paketinstallationen und MCP-Werkzeugaufrufe. Gesucht wird nach der Offenlegung von Geheimnissen, zerstörerischen Operationen, Prompt-Injection und Risiken in der Lieferkette. Je nach der vom Nutzer festgelegten Richtlinie erlaubt das Werkzeug die Aktion, blockiert sie oder fordert eine Freigabe an. Die Projektdokumentation ordnet die geschützte Fläche in sechs Gruppen: Shell-Befehle und Dateizugriffe, Paketinstallationen, Plugins, Skills und Agentenkonfiguration, MCP-Server und -Werkzeuge, Prompts und Werkzeugergebnisse sowie Freigaben und Belege. Die letzte Gruppe verdient Aufmerksamkeit. Jede Entscheidung hinterlässt eine lokale Quittung, und der Verlauf lässt sich über die Kommandozeile und ein lokales Dashboard einsehen. Eine Sicherheitsentscheidung ist damit kein einmaliges Pop-up mehr, sondern ein Eintrag, den man später prüfen kann. Das hilft sowohl bei der Untersuchung von Vorfällen als auch bei der Feinjustierung der Richtlinien.

Architektonisch setzt HOL Guard auf den Vorrang des Lokalen. Es läuft ohne Konto und hängt sich auf drei Wegen an Agenten: über native Hooks, die jeder Agent bereitstellt, über verwaltete MCP-Proxys und über Integrationen beim Start. Die Dokumentation sagt offen, dass die Abdeckung davon abhängt, welche Ereignisse ein Agent freigibt, und führt eine Unterstützungsmatrix, die für jede Integration Durchsetzung, Zustellung der Freigaben und Verhalten im Fehlerfall festhält. Diese Offenheit ist selbst eine technische Tugend. Der gefährlichste Zustand für ein Sicherheitswerkzeug ist der, in dem Nutzer sich voll geschützt glauben, obwohl für eine ganze Ereignisklasse kein Hook existiert. Für Plugins, Skills und Konfiguration erstellt Guard ein Inventar der lokalen Artefakte und prüft alles Neue oder Geänderte vor dem Start. Das zielt auf eine Bedrohung, die in den letzten Monaten wiederholt aufgetreten ist: bösartige Skills und vergiftete MCP-Server, die harmlos wirken, bis ein Agent sie lädt.

Die Einstiegshürde ist niedrig. Nötig sind Python 3.10 oder neuer und pipx. Nach pipx install hol-guard führt der Nutzer hol-guard init aus. Der Assistent beim ersten Start erkennt die unterstützten Agenten auf dem Rechner und fragt vor jeder Änderung nach, etwa beim Öffnen des Dashboards, beim Installieren der Agentenintegrationen und beim Verbinden optionaler Cloud-Dienste. Die Liste der unterstützten Agenten ist lang: Codex, Claude Code, GitHub Copilot CLI, Cursor, Cline, Gemini CLI, Grok, Hermes, Kimi Code, Pi, OpenClaw, OpenCode, Antigravity, Devin und weitere, wobei Paseo über seine nativen Anbieter abgedeckt wird. Teams mit weitergehendem Bedarf können das optionale Guard Cloud nutzen, das gemeinsamen Verlauf, Teamrichtlinien und Flottenverwaltung ergänzt. Dasselbe Repository liefert außerdem einen Plugin-Scanner, veröffentlicht als plugin-scanner, der eine Erweiterung vor der Installation untersucht.

Eine faire Bewertung muss auch die Grenzen benennen. Erstens ist der Vergleich mit dem Virenschutz eine Kommunikationshilfe und keine technische Gleichsetzung. Klassischer Virenschutz stützt sich auf Signaturen und Verhaltensüberwachung, während das Risiko bei Agenten auf der semantischen Ebene entsteht. Die Erkennung von Prompt-Injection ist ihrem Wesen nach probabilistisch, eine Trefferquote von hundert Prozent ist unmöglich. Zweitens setzt die Hook-Abdeckung die Obergrenze. Ein Ereignis, das der Agent nicht freigibt, kann Guard nicht sehen. Drittens erzeugen Freigabeabläufe Ermüdung. Eine zu lockere Richtlinie wird zur Dekoration, eine zu strenge wird abgeschaltet. Viertens hängen Urteile zur Lieferkette von Qualität und Aktualität externer Informationen ab. Nichts davon ist ein Mangel. Es sind Zwänge, denen jedes Werkzeug dieser Kategorie unterliegt. Entscheidend ist, ob das Projekt sie in seiner Dokumentation ehrlich zeigt. Nach dem öffentlichen Material tut es das. Hinzu kommen die üblichen Zeichen technischer Sorgfalt: eine Apache-2.0-Lizenz, kontinuierliche Integration, ein Container-Image und ein OpenSSF-Scorecard-Badge.

Unser praktischer Rat lautet, Guard als eine Schicht der gestaffelten Verteidigung zu behandeln, niemals als die einzige. Einzelne Entwickler können es für den am häufigsten genutzten Agenten aktivieren, eine Woche lang das Blockprotokoll beobachten und die Richtlinie dann schrittweise verschärfen. Teams sollten Geheimnistrennung, minimale Rechte und Sandboxing beibehalten und Guard eine prüfbare Schranke vor der Aktion stellen lassen. Langfristig wandert die Agentensicherheit vom Thema der Modellausrichtung zu einem Problem nach Art eines Betriebssystems, nämlich Berechtigungen und Audit. Der Wert von HOL Guard liegt darin, diesen Wechsel in ein konkretes Werkzeug zu gießen, das man heute installiert und dessen Protokolle man morgen liest. Das kommt nutzbarer Sicherheit näher als jeder abstrakte Appell.