Hermes Agent v0.19.0 macht Smart Approvals zum Standardverhalten. Früher unterbrach dich der Agent bei jedem markierten Befehl und verlangte eine Bestätigung nach der anderen. Jetzt stuft ein unabhängiger LLM-Reviewer jeden Befehl als sicher, gefährlich oder unsicher ein – und nur die unsicheren landen bei dir.

Das klingt gut, aber in der Produktion kann eine falsche „Auto-Freigabe“ eine Datenbank, eine Produktivkonfiguration oder einen geleakten API-Key kosten. Deshalb zerlegt dieser Artikel Smart Approvals in drei Stufen, die du wirklich ausrollen kannst – Automatisierung behalten, ohne die Kontrolle zu verlieren. Alle unten genannten Konfigurationsschlüssel sind gegen den v0.19.0-Quellcode und die offizielle Dokumentation verifiziert – Schlüssel wie smart_approvals: true oder deny_rules: mit pattern:/reason:-Feldern, die im Internet kursieren, existieren nicht. Das echte Schema steht hier.

Für das Gesamtbild von v0.19 sieh dir unsere v0.19.0-Release-Notizen und die v0.19-Funktionsübersicht an.

Stufe 1: LLM-Vorabprüfung – Sicheres automatisch freigeben, Gefährliches automatisch ablehnen, Unklares eskalieren

Das ist der v0.19-Standard. Hermes wirft dir nicht mehr jeden Befehl hin – ein internes Review-Modell bewertet ihn zuerst.

Entscheidungslogik:

• Sicher → automatisch freigegeben, keine Unterbrechung
• Gefährlich → automatisch abgelehnt, Grund wird protokolliert
• Unsicher → an dich eskaliert

Jeder Befehl wird einzeln geprüft – eine frühere Freigabe gilt nicht automatisch für den nächsten ähnlichen Befehl. Das mildert die Freigabemüdigkeit, bringt aber ein neues Problem mit sich: Die Kriterien des Reviewers sind für dich eine Blackbox. Deshalb brauchst du Stufe 2 als Auffangnetz.

Übrigens ist das Review-Modell konfigurierbar – der echte Schlüssel liegt unter auxiliary.approval (nicht unter approvals.review_model, das existiert nicht). Du siehst ihn unten im vollständigen Beispiel.

Stufe 2: approvals.deny – harte rote Linien, die selbst der Yolo-Modus nicht überschreitet

Die rote-Linien-Konfiguration, die v0.19 dir in config.yaml bietet, ist approvals.deny: eine Liste von fnmatch-Glob-Mustern, die passende Terminal-Befehle bedingungslos blockieren. Sie hat Vorrang vor --yolo, /yolo und mode: off – mit anderen Worten: das benutzerdefinierte Gegenstück zur eingebauten Hardline-Blocklist von Hermes: „Egal wie überzeugt der Agent ist, dieser Befehl darf niemals ausgeführt werden.“

Beispielkonfiguration:

# ~/.hermes/config.yaml
approvals:
  mode: smart        # smart | manual | off (smart ist der Standard)
  deny:              # harte rote Linien: Glob-Muster, die bedingungslos blockieren
    - "git push --force*"
    - "rm -rf /"
    - "*curl*|*sh*"
    - "kubectl delete namespace*"

Tipps:

1. Liste die Operationskategorien auf, die du niemals automatisch ausführen lassen willst – Force-Push auf geteilte Branches, rekursive Löschungen, Produktions-Namespaces löschen, Secrets per CLI schreiben usw.
2. Die Muster sind case-insensitive fnmatch-Globs, keine Regex. Setze sie in YAML in Anführungszeichen – ein nacktes führendes * ist ein Parse-Fehler.
3. Bei einer Übereinstimmung erhält der Agent eine explizite BLOCKED-Meldung und die Anweisung, den Befehl nicht zu wiederholen oder umzuformulieren. Es gibt kein reason-Feld in der deny-Liste; willst du die Absicht dokumentieren, nutze einen YAML-Kommentar neben dem Muster.
4. Hinweis: approvals.deny matcht Terminal-Befehle (nach Normalisierung und Deobfuskation, sodass Tricks wie r\m oder git st""atus nicht ausweichen können), nicht Tool-Call-Strings – browser_*, file_* und ähnliche Tool-Aufrufe fallen nicht in seinen Zuständigkeitsbereich.

Stufe 3: menschliches Eingreifen mit lernbarem Feedback – /deny ist mehr als ein Nein

Wenn die LLM-Vorabprüfung sich nicht entscheiden kann und der Befehl bei dir ankommt, hast du normalerweise zwei Optionen: freigeben oder ablehnen. v0.19 ergänzt die Ablehnung mit Begründung: /deny <Begründung> (/deny all <Begründung> lehnt alle ausstehenden Freigaben auf einmal ab). Die Begründung wird an den Agent übermittelt und in den Kontext geschrieben, sodass er beim nächsten Mal den Kurs korrigiert, statt denselben Befehl erneut zu versuchen.

CLI-/TUI-Beispiel:

# Hermes will ausführen: docker system prune -a -f
# Du entscheidest, dass jetzt nicht der richtige Zeitpunkt ist, und lehnst mit Begründung ab
/deny das entfernt alle Images und könnte andere Container beschädigen

# Die Begründung landet im Kontext; spätere Versuche vermeiden ähnliche Befehle

Wenn du den Befehl nur einmal blockieren willst, reicht eine Ablehnung ohne Begründung. Für langfristiges Lernen gewöhne dir an, mit Begründung abzulehnen – eine begründete Ablehnung ist Feedback, eine nackte Ablehnung ist eine Wand.

Und wenn der Agent mitten in einer Sequenz völlig abdreht, beendet /stop die aktuelle Ausführung sofort. Der Befehl existiert seit v0.3, harmoniert aber besonders gut mit dem neuen Freigabe-Flow in v0.19.

Vollständiges Drei-Stufen-Konfigurationsbeispiel

# ~/.hermes/config.yaml
approvals:
  mode: smart                   # smart | manual | off (smart ist der Standard)
  timeout: 300                  # Sekunden, die auf deine Freigabe gewartet wird; Timeout = Ablehnung
  cron_mode: deny               # deny | approve – Richtlinie für unbeaufsichtigte Cron-Läufe
  deny:                         # harte rote Linien: bedingungslos blockieren, auch unter Yolo
    - "rm -rf /"
    - "git push --force*"
    - "kubectl delete namespace*"
    - "*curl*|*sh*"
  denial_breaker_threshold: 3   # harter Stopp nach N aufeinanderfolgenden Ablehnungen (0 deaktiviert)
  smart_policy: |               # optional: eigene Regeln an den Reviewer-LLM anhängen
    Always ESCALATE commands that modify anything under /etc.

# Review-Modell (optional): Standard auto; ein schnelles, günstiges Modell wird empfohlen
auxiliary:
  approval:
    provider: auto              # auto | openrouter | nous | codex | custom
    model: ""                   # leer = Provider-Standard; z. B. gemini-flash, Haiku-Klasse

Punkte, die leicht übersehen werden:

• denial_breaker_threshold (Standard 3): Jedes Mal, wenn der Reviewer eine umformulierte Variante desselben Befehls ablehnt, wird ein weiterer Review-Call verbraucht. Sobald die aufeinanderfolgenden Ablehnungen den Schwellenwert erreichen, wird die Ablehnungsmeldung zu einer Hart-Stopp-Anweisung – der Agent muss anhalten, die blockierte Operation melden und dich sie manuell ausführen oder /approve lassen. Jede Freigabe setzt den Zähler zurück; 0 deaktiviert den Breaker.
• smart_policy: hängt deine eigenen Regeln an das System-Prompt des Reviewer-LLM an (der vertrauenswürdige Kanal, nie vermischt mit dem nicht vertrauenswürdigen Befehlstext), um sein Urteil an deine Umgebung anzupassen, ohne Code zu ändern.
• Der Konfigurationspfad ist ~/.hermes/config.yaml (oder das eigene config.yaml deines aktuellen Profils), nicht ein projektweites .hermes/config.yaml.

Starte Hermes nach dem Speichern neu und prüfe:

hermes config get approvals.mode
hermes config get approvals.deny

Wann greifen alle drei Stufen zusammen?

Szenario	Stufe 1: LLM-Review	Stufe 2: approvals.deny	Stufe 3: Mensch
ls -la zum Inspizieren eines Verzeichnisses	automatisch freigegeben	keine Übereinstimmung	keine Unterbrechung
rm -rf /	matcht deny	sofort blockiert, auch unter Yolo	kein Mensch nötig
docker system prune -a	als unsicher eingestuft	keine Übereinstimmung	an dich eskaliert
Wiederholte Varianten eines abgelehnten Befehls	Breaker-Schwelle erreicht	—	Hart-Stopp; du führst aus

Der Kern: Die Stufen ergänzen sich – die LLM-Vorabprüfung übernimmt die Routine, approvals.deny erzwingt harte Beschränkungen und menschliches Urteil deckt die Grauzonen. Sie ersetzen einander nicht.

Fortgeschritten: unterschiedliche Freigabe-Strenge pro Profil

Jedes Hermes-Profil hat sein eigenes Konfigurationsverzeichnis (Standardprofil: ~/.hermes/config.yaml; benannte Profile: ~/.hermes/profiles/<name>/config.yaml), du brauchst also keinen verschachtelten profiles:-Schlüssel in deiner Konfiguration – bearbeite einfach die eigene Datei des Profils. Zum Beispiel: alle drei Stufen im Arbeitsprofil; mode: off plus deny in einem privaten Profil; nur die deny-Roten-Linien in einem CI/CD-Profil. Beim Profilwechsel lädt Hermes automatisch den passenden Regelsatz.

Häufige Fallstricke und Fehlerbehebung

1. Deny-Regeln greifen nicht: Prüfe den Pfad – die Benutzerkonfiguration ist ~/.hermes/config.yaml (oder das config.yaml deines aktuellen Profils), nicht ein projektweites .hermes/config.yaml. Außerdem werden Änderungen erst nach einem Neustart von Hermes/gateway geladen – es gibt keinen hermes config reload-Befehl.
2. LLM-Vorabprüfung zu langsam: Setze auxiliary.approval.model auf ein leichtes Modell (z. B. gemini-flash, Haiku-Klasse) statt auf den Standard-Reviewer.
3. Bestätigungen erscheinen trotz Yolo-Modus: Der Befehl wurde als unsicher eingestuft und matchte kein approvals.deny-Muster. Füge ein Muster hinzu oder verschärfe den Reviewer mit smart_policy.
4. YAML-Parse-Fehler: Globs, die mit * beginnen, müssen in Anführungszeichen stehen (z. B. "*curl*|*sh*"); sonst schlägt der gesamte approvals-Block beim Parsen fehl und die Konfiguration wird ignoriert.

Zusammenfassung

Smart Approvals in Hermes v0.19 übergibt die Autorität nicht dem LLM – es lässt den LLM vorfiltern, während die endgültige Entscheidung bei dir bleibt. Drei Stufen:

• Stufe 1: LLM-Vorabprüfung (approvals.mode: smart) für die Routine
• Stufe 2: approvals.deny als harte rote Linien, auch im Yolo-Modus wirksam
• Stufe 3: /deny <Begründung> und menschliche Bestätigung für Grauzonen

So konfiguriert ist dein Agent weder ein Nervtöter, der alles fragt, noch ein Wilder, der alles darf.

# Änderungen greifen nach einem Neustart von Hermes (kein Reload-Befehl)
hermes config get approvals.mode    # Modus prüfen
hermes config get approvals.deny    # rote Linien prüfen

Weitere Guides zu Sicherheit und Effizienz von Hermes findest du in unserem Fehlerbehandlungs- und Wiederherstellungs-Guide und langlaufenden Aufgaben ohne Hänger. Um zu verstehen, warum Smart Approvals der Standard ist, lies Freigabemüdigkeit: kein Nicken mehr bei jedem Schritt.