In der Hermes-Community geht ein Spruch um: Mehr als die Hälfte aller Nutzer hat YOLO schon einmal aktiviert. Aber YOLO ist nicht das ganze Bild — es ist nur ein extremer Punkt auf Hermes’ Sicherheitsspektrum. Wer Hermes wirklich effektiv nutzt, wechselt zwischen sieben gängigen Modi, statt bei jeder Verzögerung einfach /yolo zu verwenden.

Hermes Agent basiert auf einer klaren Standardannahme: Wenn du einen Befehl ausführen lässt, sollte der Agent dafür verantwortlich sein. Deshalb hält Hermes vor potenziell schädlichen Befehlen an und fragt nach. Das nennt sich Dangerous Command Approval, und YOLO ist nur eine Möglichkeit, es zu umgehen.

Dieser Artikel behandelt die sieben Sicherheits- und Autonomiemodi in Hermes. Danach weißt du genau, wann du deinem Agenten sagen kannst:

• „Für normale Entwicklung reicht der smart-Modus.“
• „Ich führe das Script oft aus, genehmige es für die Sitzung.“
• „Ich mache ein großes Refactoring, schalte YOLO an, aber erlaube niemals git push --force.“
• „Lass das in Docker laufen, dann brauchen wir keine Genehmigungen und der Host bleibt sicher.“

---

1. Smart-Modus: Die KI bewertet das Risiko (empfohlener Standard)

approvals:
  mode: smart

smart ist der Standardmodus von Hermes. Wenn ein Befehl ein gefährliches Muster erkennt, lässt Hermes ein Hilfsmodell das tatsächliche Risiko einschätzen.

• Offensichtlich sichere Befehle (z. B. python -c "print('hello')") werden automatisch genehmigt.
• Offensichtlich gefährliche Befehle (z. B. rm -rf /) werden automatisch abgelehnt.
• Unsichere Fälle werden an dich weitergeleitet.

Das reduziert die „Genehmigungsmüdigkeit“ erheblich. Du musst nicht jeden bash -c bestätigen, während wirklich destruktive Aktionen weiterhin erkannt werden.

Ideal für: tägliche Entwicklung, explorative Aufgaben und Umgebungen, in denen du dem Agenten bereits vertraust.

---

2. Manual-Modus: Jeder gefährliche Befehl läuft über dich

approvals:
  mode: manual

Wenn du die Risikobewertung nicht einem Hilfsmodell überlassen möchtest, nutzt du den manual-Modus. Jeder Befehl, der ein gefährliches Muster erkennt, wird pausiert und wartet auf deine Genehmigung.

In der CLI sieht die Eingabeaufforderung so aus:

⚠️  DANGEROUS COMMAND: recursive delete
    rm -rf /tmp/old-project

    [o]nce  |  [s]ession  |  [a]lways  |  [d]eny

    Choice [o/s/a/D]:

Vier Optionen:

• once: erlaubt nur diese einzelne Ausführung.
• session: erlaubt dieses Muster für den Rest der Sitzung.
• always: fügt das Muster deiner permanenten Allowlist in ~/.hermes/config.yaml hinzu.
• deny (Standard): blockiert den Befehl.

Ideal für: besonders sicherheitsrelevante Arbeiten, Einsteiger oder unbekannte Befehle.

---

3. YOLO-Modus: Alle Genehmigungen überspringen

Der YOLO-Modus umgeht alle Genehmigungen für gefährliche Befehle. Du kannst ihn auf drei Arten aktivieren:

# Beim Start
hermes --yolo
hermes chat --yolo

# Während einer Sitzung
/yolo

# Umgebungsvariable
HERMES_YOLO_MODE=1

Sobald YOLO aktiv ist, zeigt Hermes einen roten Banner und einen Statusindikator, damit du nicht vergisst, dass das Sicherheitsnetz weg ist.

> /yolo
  ⚡ YOLO mode ON — all commands auto-approved. Use with caution.

YOLO passt zu Szenarien, in denen du dir sicher bist, dass die Befehle harmlos sind, zum Beispiel:

• Wiederkehrende Automatisierungsscripts;
• Arbeit in Containern oder Wegwerfumgebungen;
• Aufgaben, bei denen du dich konzentriert beobachtest und jederzeit Ctrl+C drücken kannst.

Aber denk daran: YOLO ist nicht 100 % uneingeschränkt — die Hardline-Blocklist, die wir gleich besprechen, gilt weiterhin.

---

4. Hardline-Blocklist: Die Grenze, die selbst YOLO nicht überschreitet

Selbst bei approvals.mode: off oder aktiviertem /yolo lehnt Hermes bestimmte irreversible, katastrophale Befehle ab. Das ist die Hardline-Blocklist.

Beispiele:

Befehl	Warum blockiert
rm -rf /	Löscht das Wurzeldateisystem
:(){ :|:& };:	Bash-Fork-Bombe
mkfs.* gegen ein gemountetes Root-Gerät	Formatiert das laufende System
dd if=/dev/zero of=/dev/sd*	Überschreibt eine physische Festplatte mit Nullen
URLs aus unsicheren Quellen in sh pipen	Zu große Angriffsfläche für Remote Code Execution

Diese Muster werden in tools/approval.py::UNRECOVERABLE_BLOCKLIST gepflegt und können durch kein Flag überschrieben werden.

Designphilosophie: YOLO bedeutet „Ich vertraue darauf, dass die KI keinen Fehler macht“, während die Hardline-Liste bedeutet „Selbst wenn die KI oder der Nutzer versagt, darf die Maschine nicht zerstört werden“.

---

5. Benutzerdefinierte Deny-Regeln: YOLO mit Ausnahmen

Wenn YOLO zu weitgehend und manual zu lästig ist, nutze approvals.deny, um eigene rote Linien zu ziehen:

approvals:
  mode: off           # effektiv YOLO
  deny:
    - "git push --force*"
    - "*curl*|*sh*"
    - "dd if=* of=/dev/*"

Regeln sind case-insensitive fnmatch-Glob-Muster, die mit dem vollständigen normalisierten Befehlstext verglichen werden. Selbst unter YOLO wird ein passender Befehl hart blockiert.

Perfekt für Szenarien wie „Ich vertraue den meisten Operationen, aber einige Aktionen sind niemals erlaubt“:

• Der Agent darf Code bearbeiten und Tests ausführen, aber git push --force ist verboten;
• Er darf Abhängigkeiten herunterladen, aber curl ... | sh wird blockiert;
• Er darf Docker bedienen, aber niemals direkt auf Block Devices schreiben.

---

6. Write-Approval-Modus: Schreibzugriffe auf Memory und Skills kontrollieren

Neben Terminalbefehlen schreibt Hermes auch selbstständig: Es speichert wichtige Fakten in Memory und gelernte Workflows als Skills. Wenn du befürchtest, dass es „falsche Dinge lernt“, aktiviere Write Approval.

memory:
  write_approval: true

skills:
  write_approval: true

Ist diese Funktion aktiv, landet jeder Memory- oder Skill-Schreibzugriff zunächst in ~/.hermes/pending/ und wartet auf deine Überprüfung:

# Ausstehende Skill-Schreibzugriffe prüfen
/skills pending
/skills diff <id>
/skills approve <id>
/skills reject <id>

# Gleiches für Memory
/memory pending
/memory approve <id>
/memory reject <id>

Ideal für:

• Verhindern, dass der Agent sensible oder falsche Fakten automatisch speichert;
• Geteilte Hermes-Instanzen, bei denen gelernte Skills menschlich geprüft werden müssen;
• Debugging der Lernschleife, bevor etwas dauerhaft persistiert wird.

---

7. Container-Isolation: Genehmigungen durch Grenzen ersetzen

Der letzte Modus dreht sich nicht darum, wie man genehmigt, sondern darum, Genehmigungen überflüssig zu machen. Hermes unterstützt mehrere Terminal-Backends:

Backend	Isolation	Gefährliche Befehle geprüft
local	Keine, läuft auf dem Host	✅ Ja
ssh	Entfernte Maschine	✅ Ja
docker	Container	❌ Übersprungen (Container ist die Grenze)
singularity	Container	❌ Übersprungen
modal	Cloud-Sandbox	❌ Übersprungen
daytona	Cloud-Sandbox	❌ Übersprungen

Bei Docker, Modal oder Daytona werden gefährliche Befehle nicht geprüft, denn selbst wenn der Container zerstört wird, bleibt der Host unberührt. Produktive Hermes-Gateways werden meist so betrieben.

Docker-Container laufen außerdem standardmäßig mit gehärteten Sicherheitsparametern:

_BASE_SECURITY_ARGS = [
    "--cap-drop", "ALL",
    "--security-opt", "no-new-privileges",
    "--pids-limit", "256",
    "--tmpfs", "/tmp:rw,nosuid,size=512m",
]

Ideal für: Produktionsumgebungen, CI/CD, Multi-Tenant-Szenarien und jede Sandbox, in der Zerstörung akzeptabel ist.

---

Kurzübersicht: Den richtigen Modus wählen

Modus	Befehlsgenehmigung	Schreibgenehmigung	Wann nutzen
smart	KI-Vorprüfung + menschliche Prüfung bei Grenzfällen	Optional	Standard für tägliche Entwicklung
manual	Alle gefährlichen Befehle erfordern menschliche Freigabe	Optional	Hohe Sicherheit oder Einsteiger
YOLO	Alle gefährlichen Befehle werden übersprungen	Optional	Temporäre Automatisierung, vertrauenswürdige Scripts
hardline	Katastrophale Befehle dauerhaft blockiert	Nicht zutreffend	Immer aktive Sicherheitsuntergrenze
deny rules	Benutzerdefinierte Blockmuster	Nicht zutreffend	YOLO mit Ausnahmen
write approval	Optional	Erforderlich für Memory/Skill-Schreibzugriffe	Verhindern, dass der Agent falsche Dinge lernt
container isolation	Keine Prüfung	Begrenzt durch Container	Produktion oder Sandbox

---

Praktische Empfehlungen

1. Bleib beim Standard: Der smart-Modus meistert den Großteil der täglichen Arbeit ohne ständige Unterbrechungen.
2. Sitzungsgenehmigung für Stapelverarbeitung: Sicherer als YOLO, aber ohne ständige Einzelbestätigungen.
3. YOLO mit Deny-Regeln kombinieren: Wenn du YOLO nutzt, behalte wenigstens einige rote Linien bei.
4. Produktion in Docker laufen lassen: Isolation ist zuverlässiger als Genehmigungen und beseitigt Genehmigungsmüdigkeit vollständig.
5. Allowlist regelmäßig prüfen: command_allowlist wächst mit der Zeit. Bereinige sie regelmäßig mit hermes config edit.
6. Write Approval bei geteilten Hermes-Instanzen aktivieren: Besonders wichtig bei langlaufenden Gateways in Teams.

---

Fazit

Hermes’ Genehmigungssystem soll dich nicht ausbremsen. Es soll dir helfen, vertrauensvolle Delegation und rechtzeitiges Bremsen in Einklang zu bringen. YOLO macht Spaß, ist aber nur einer von sieben Modi. Erfahrene Nutzer wissen, wann sie in smart bleiben, wann sie auf manual wechseln, wann sie YOLO wieder ausschalten und wann Docker die Sicherheitsarbeit für sie übernimmt.

Wenn du das nächste Mal zu /yolo greifst, frag dich: Brauche ich wirklich jede Genehmigung überspringen, oder reicht eine Sitzungsgenehmigung plus eine einzige Deny-Regel?