Tutorial 29: Sicherheit im Detail

Tutorial 29: Sicherheit im Detail

Willkommen zurück, Agenten-Flüsterer! Heute setzen wir unsere Schutzhelme auf und tauchen tief in das Sicherheitsmodell von Hermes Agent ein. Falls du dich je gefragt hast, was hinter den Kulissen passiert, um deine Sitzungen zu schützen, ist dieses Tutorial genau richtig für dich.

Das große Ganze: Acht Verteidigungsebenen

Hermes verlässt sich nicht auf ein einzelnes Schloss an der Tür. Stattdessen nutzt es einen Defense-in-Depth-Ansatz mit acht klar getrennten Sicherheitsebenen. Stell es dir wie eine Burg vor: Selbst wenn jemand den Burggraben überwindet, warten immer noch die Mauern, die Tore und die Wachen im Inneren.

Hier ist die Aufstellung:

1. Benutzerautorisierung — wer mit dem Agenten sprechen darf
2. Genehmigung gefährlicher Befehle — menschliche Kontrolle bei destruktiven Aktionen
3. Dateischreib-Sicherheit — Denylists und Sandboxes für Dateioperationen
4. Container-Isolation — Docker/Singularity/Modal-Sandboxing
5. MCP-Zugangsdaten-Filterung — Geheimnisse von Subprozessen fernhalten
6. Kontextdatei-Scanning — Erkennung von Prompt-Injection in Projektdateien
7. Sitzungsübergreifende Isolation — Sitzungen können nicht in die Daten anderer Sitzungen schauen
8. Eingabebereinigung — Blockierung von Shell-Injection über Arbeitsverzeichnis-Parameter

Jede Ebene zählt, aber heute konzentrieren wir uns auf diejenige, mit der du am häufigsten interagieren wirst: Genehmigung gefährlicher Befehle.

So funktioniert die Genehmigung gefährlicher Befehle

Bevor Hermes einen Befehl ausführt, prüft es ihn gegen eine kuratierte Liste gefährlicher Muster. Bei einer Übereinstimmung entscheidest du, was als Nächstes passiert.

Du steuerst dieses Verhalten über den Abschnitt approvals in ~/.hermes/config.yaml:

approvals:
  mode: smart                     # smart | manual | off
  timeout: 300                    # Sekunden, die auf eine Benutzerantwort gewartet wird
  cron_mode: deny                 # deny | approve
  single_query_mode: deny         # deny | approve
  mcp_reload_confirm: true        # Bestätigung vor dem Neuladen von MCP-Tools
  destructive_slash_confirm: true # Bestätigung vor /clear, /new, etc.

Drei Genehmigungsmodi

Der Schlüssel mode bietet dir drei Optionen:

Modus	Verhalten
smart (Standard)	Nutzt ein Hilfs-LLM zur Risikobewertung. Befehle mit geringem Risiko (wie python -c "print('hello')") werden automatisch genehmigt. Wirklich gefährliche werden automatisch abgelehnt. Unklare Fälle werden zur manuellen Eingabeaufforderung eskaliert.
manual	Fragt bei gefährlichen Befehlen immer nach Genehmigung. Keine Ausnahmen.
off	Deaktiviert alle Genehmigungsprüfungen. Entspricht dem Ausführen mit --yolo.

⚠️ Warnung: approvals.mode: off deaktiviert alle Sicherheitsabfragen. Nur in vertrauenswürdigen Umgebungen wie CI/CD-Pipelines oder Wegwerf-Containern verwenden.

YOLO-Modus: Der große rote Knopf

Der YOLO-Modus umgeht alle Genehmigungsabfragen für gefährliche Befehle in der aktuellen Sitzung. Du kannst ihn auf drei Arten aktivieren:

1. CLI-Flag: hermes --yolo oder hermes chat --yolo
2. Slash-Befehl: Tippe /yolo während einer Sitzung
3. Umgebungsvariable: Setze HERMES_YOLO_MODE=1

Der /yolo-Befehl ist ein Umschalter — jede Verwendung schaltet ihn ein oder aus:

> /yolo
  ⚡ YOLO-Modus AN — alle Befehle automatisch genehmigt. Mit Vorsicht verwenden.

> /yolo
  ⚠ YOLO-Modus AUS — gefährliche Befehle erfordern wieder eine Genehmigung.

Wenn YOLO aktiv ist, stellt Hermes sicher, dass du es nicht vergisst. Du siehst ein rotes Banner beim Sitzungsstart und ein ⚠ YOLO-Fragment in der Statusleiste, das live aktualisiert wird, während du umschaltest.

⚠️ Gefahr: Der YOLO-Modus deaktiviert alle Sicherheitsprüfungen für gefährliche Befehle — außer der strikten Blocklist. Verwende ihn nur, wenn du den generierten Befehlen vollständig vertraust (z. B. gut getestete Automatisierungsskripte in Wegwerf-Umgebungen).

Neu in dieser Version: Schlauere Konfigurationsschlüssel

Zwei neue Konfigurationsschlüssel verdienen besondere Aufmerksamkeit:

mcp_reload_confirm (Standard: true) — Wenn true, fragt /reload-mcp vor dem Neuaufbau des MCP-Toolsets nach. Warum? Weil der Neuaufbau den Provider-Prompt-Cache ungültig macht, was bedeutet, dass die nächste Nachricht die vollständigen Eingabe-Tokens erneut sendet. Das sind Kosten, die du vielleicht erst genehmigen möchtest.

destructive_slash_confirm (Standard: true) — Wenn true, fragen destruktive Sitzungsbefehle (/clear, /new, /reset, /undo) vor dem Verwerfen des Konversationszustands nach. Du erhältst einen Dialog mit drei Optionen: Einmal genehmigen / Immer genehmigen / Abbrechen. Auf Telegram, Discord und Slack läuft dies über native Ja/Nein-Buttons. Anderswo wird auf Text zurückgegriffen.

Die TUI berücksichtigt diese Einstellung ebenfalls für ihre /clear-, /new- und /reset-Modals. Und wenn du Dinge automatisierst, überspringt HERMES_TUI_NO_CONFIRM=1 dieses Modal komplett.

Headless-Sitzungen: Cron und Einzelabfrage

Was passiert, wenn ein Cron-Job oder eine Einmal-Sitzung mit hermes chat -q auf einen gefährlichen Befehl stößt? Es gibt keinen Menschen, der auf eine Eingabeaufforderung wartet.

Hier kommen cron_mode und single_query_mode ins Spiel:

• deny (Standard) — Blockiert den Befehl. Der Agent muss einen anderen Weg finden.
• approve — Genehmigt in diesem Kontext alles automatisch.

Beide standardmäßig auf deny zu setzen, hat einen guten Grund: Sicher ist sicher, wenn niemand zusieht.

Zusammenfassung

Das Sicherheitsmodell von Hermes Agent dreht sich darum, dir Kontrolle zu geben, ohne dir im Weg zu stehen. Der smarte Genehmigungsmodus erledigt die langweiligen Dinge automatisch, während der manuelle Modus dir volle Übersicht gibt, wenn du sie brauchst. Und wenn du dich in einer vertrauenswürdigen Umgebung befindest, lässt dich der YOLO-Modus schnell vorankommen.

Denk daran: Mit großer Macht kommt große Verantwortung. Nutze YOLO weise!

Beim nächsten Mal erkunden wir, wie du das Genehmigungssystem für deinen spezifischen Workflow anpassen kannst. Bis dahin: Bleib sicher da draußen!