Jeder, der Hermes Agent intensiv nutzt, kennt den Moment: Du siehst dem Agenten bei der Arbeit zu, alles läuft großartig, und dann – peng – erscheint eine Genehmigungsabfrage. Hast du sie wirklich gelesen? Seien wir ehrlich. Nach dem fünfzigsten rm-Hinweis am Tag drücken die meisten einfach nur noch „Genehmigen“. Das ist Genehmigungsmüdigkeit – und sie ist ein Sicherheitsloch im Kostüm der Bequemlichkeit: Je mehr Aufforderungen du gedankenlos abnickst, desto weniger bedeutet jede einzelne.

Hermes v0.19.0 (die Quicksilver Release) hat dieses Problem an der Wurzel angepackt. Smart Approvals sind jetzt der Standard: Statt dich um die Genehmigung jedes markierten Befehls zu bitten, lässt Hermes einen unabhängigen LLM-Prüfer jeden Befehl bewerten – risikoarme werden automatisch genehmigt, wirklich gefährliche automatisch abgelehnt, und nur Unklares wird an dich eskaliert. Weniger Unterbrechungen, gleiches menschliches Vetorecht – wenn überhaupt stärker, weil deine Aufmerksamkeit nur noch dort ausgegeben wird, wo es zählt.

Dieser Beitrag ist ein praktischer Leitfaden: wie der neue Genehmigungsablauf wirklich funktioniert, die echten config.yaml-Schlüssel (gegen den v0.19-Quellcode verifiziert, nicht gegen Hörensagen) und wie du harte rote Linien setzt, die nicht einmal der Yolo-Modus überqueren kann.

Das Problem: Genehmigungsmüdigkeit ist ein Sicherheits-Bug

Manuelle Genehmigung funktionierte, als Agenten eine Handvoll Befehle pro Sitzung ausführten. Moderne Agenten führen dutzende oder hunderte aus. Jede Abfrage ist ein Kontextwechsel; jeder Kontextwechsel kostet Aufmerksamkeit; erschöpfte Aufmerksamkeit genehmigt Dinge, die sie nicht genehmigen sollte. Sicherheitsforscher haben dafür einen Namen – Habituation – und genau so schlüpft der eine Befehl durch, den du hättest sorgfältig lesen müssen.

Der alte Ablauf hatte noch ein zweites Problem: Du warst der Risiko-Klassifizierer. Hermes markierte einen Befehl, du bewertetest ihn, fertig. Die Bewertungsqualität hing davon ab, wie wach du in genau diesem Moment warst – das schlechtestmögliche Design für einen Sicherheitsmechanismus.

Smart Approvals beheben beides: Die Routine-Klassifizierung übernimmt ein Modell, das nie müde wird – die letzte Entscheidung bleibt bei dir.

So funktionieren Smart Approvals: drei Urteile, ein Befehl nach dem anderen

Wenn Hermes einen Befehl ausführen will, der mit seiner Gefahrenmuster-Liste übereinstimmt, heißt der Ablauf nicht mehr „frag den Menschen“, sondern:

1. Ein Hilfs-LLM bewertet den Befehl unabhängig – nicht der Haupt-Agent, sondern ein separates Prüfmodell.
2. Das Prüfmodell liefert eines von drei Urteilen:
   • Sicher → automatisch genehmigt, keine Unterbrechung.
   • Gefährlich → automatisch abgelehnt, mit protokolliertem Grund.
   • Unklar → an dich eskaliert zur manuellen Genehmigung/Ablehnung.

Das wichtige Detail steht in den Release-Notes: Jedes Urteil deckt nur genau diesen einen Befehl ab. Ein späterer Befehl mit demselben Muster bekommt seine eigene frische Prüfung. Es gibt keine Abkürzung à la „diese Klasse haben wir schon genehmigt, also wieder genehmigen“. Das Prüfmodell kann nicht durch Muster betäubt werden – und du auch nicht, weil du nur die wirklich mehrdeutigen Fälle siehst.

Du: "Staging-Server deployen und die Migration ausführen"
Hermes: [kubectl apply --dry-run ...]      → Prüfung: sicher, automatisch genehmigt
        [kubectl rollout restart ...]      → Prüfung: sicher, automatisch genehmigt
        [kubectl delete namespace prod]    → Prüfung: GEFÄHRLICH, automatisch abgelehnt
        [psql -c "DROP TABLE users;"]      → unklar → an dich eskaliert

Das ist der Ablauf, der das Nicken beendet.

Die echte Konfiguration: approvals.mode, keine Legenden

Wenn du ältere Blogposts über die v0.19-Genehmigungen gelesen hast, sind dir vielleicht erfundene Schlüssel begegnet wie smart_approvals: true oder deny_rules: mit pattern:/reason:-Feldern. Die gibt es nicht. Das tatsächliche Schema in config.yaml ist:

# ~/.hermes/config.yaml
approvals:
  mode: smart        # smart | manual | off  (smart ist der Standard)
  timeout: 300       # Sekunden, die auf deine Genehmigung gewartet wird, dann fail-closed
  cron_mode: deny    # deny | approve – was Cron-Jobs bei markierten Befehlen tun
  deny: []           # deine roten Linien: Glob-Muster, die bedingungslos blockieren

Schlüssel	Standard	Wirkung
mode	smart	Genehmigungsrichtlinie für markierte Shell-Befehle
timeout	300	Sekunden, die Hermes auf deine Antwort wartet, bevor es als Ablehnung gilt
cron_mode	deny	Unbeaufsichtigtes Verhalten: deny blockiert markierte Befehle in Cron, approve führt sie aus
deny	[]	Glob-Muster, die Befehle bedingungslos blockieren – sogar unter Yolo

Prüfe deine aktuelle Einstellung jederzeit:

hermes config | grep -A 4 approvals

Die drei Modi in klarem Deutsch:

• smart (Standard) – LLM-Prüfung filtert Routine-Befehle; gefährliche werden abgelehnt; Unklares erreicht dich.
• manual – jeder markierte Befehl fragt dich, genau wie vor v0.19.
• off – keine Genehmigungsabfragen; gleichbedeutend mit --yolo / HERMES_YOLO_MODE=1. Nur für vertrauenswürdige Sandboxes.

Harte rote Linien: approvals.deny schlägt Yolo

Hier kommt der Teil, der den Smart-Modus gefahrlos entspannt nutzbar macht. Die deny-Liste ist eine Menge von Glob-Mustern, die passende Befehle bedingungslos blockieren – vor jedem Yolo-Bypass, vor /yolo, vor mode: off. Sie ist das benutzereditierbare Gegenstück zur fest verdrahteten Blacklist von Hermes und die wichtigste Verteidigungslinie, die du konfigurieren kannst:

approvals:
  mode: smart
  deny:
    - "git push --force*"
    - "rm -rf /"
    - "*curl*|*sh*"
    - "kubectl delete namespace*"

Die Muster sind case-insensitive fnmatch-Globs. In YAML in Anführungszeichen setzen – ein nacktes führendes * ist ein Parse-Fehler. Ein passender Befehl wird ohne Diskussion blockiert und der Grund protokolliert. Auch im Yolo-Modus. Das ist deine „Egal wie selbstbewusst der Agent ist, das passiert nie“-Liste, und sie sollte die wenigen Operationen enthalten, deren Fehlermodi inakzeptabel sind: Force-Pushes auf geteilte Branches, rekursive Löschungen, Produktions-Namespace-Löschungen, Secrets per CLI schreiben.

Die Ausnahme für wirklich bewusste Einzelaktionen? Keine in der Konfiguration – genau das ist der Punkt. Wenn du wirklich einen Force-Push brauchst, entfernst du das Muster, führst den Befehl aus und fügst es wieder hinzu. Die Reibung ist beabsichtigt und winzig.

/deny <reason>: Mach die Ablehnung zum Unterricht

Smart Approvals reduzieren nicht nur Abfragen – sie machen die Abfragen, die du doch beantwortest, wertvoller. Wenn das Prüfmodell dir einen Befehl eskaliert und du ihn ablehnst, kannst du dem Agenten jetzt sagen, warum:

Hermes will ausführen: docker system prune -a -f

> /deny zu aggressiv – andere Container teilen diesen Image-Cache

Der Grund wird in den Kontext zurückgeschrieben, und der Agent korrigiert seinen Kurs – er sucht einen enger gefassten Befehl, statt denselben erneut zu versuchen und zu hoffen, dass du einknickst. Eine begründete Ablehnung ist Feedback; eine nackte Ablehnung ist eine Mauer. Gewöhne dir an, einen Satz Begründung zu geben, und der nächste Versuch des Agenten wird spürbar besser.

Und noch etwas: Wenn der Agent komplett in die falsche Richtung läuft, beendet /stop die Ausführung nach wie vor sofort. Der Genehmigungsablauf und der Stopp-Knopf ergänzen sich – der eine filtert Befehle, der andere schneidet die gesamte Sequenz ab.

Cron-Jobs: Niemand ist da zum Nicken

Smart Approvals glänzen in interaktiven Sitzungen – aber was ist mit unbeaufsichtigten? Wenn ein geplanter Cron-Job auf einen markierten Befehl stößt, gibt es keinen Benutzer zum Eskalieren. Der Standard cron_mode: deny geht konservativ damit um: Der Befehl wird blockiert, und der Agent muss einen anderen Weg finden. Wenn du einem bestimmten Job vertraust (z. B. einem nächtlichen Backup, das legitimerweise alte Dateien aufräumt), kannst du dessen Richtlinie umstellen:

approvals:
  cron_mode: approve   # markierte Befehle im Cron-Kontext automatisch genehmigen

Denk zweimal nach, bevor du das aktivierst. deny kostet nichts, wenn der Agent einen alternativen Weg findet; approve verwandelt jede Cron-Abfrage in eine stille Auto-Ausführung. Für die meisten Jobs ist deny plus eine enge Ausnahmeliste in approvals.deny die richtige Form.

Welchen Modus solltest du nutzen?

Situation	Empfehlung
Tägliche interaktive Arbeit	smart (Standard) – Vetorecht behalten, Rauschen verlieren
Repo-Operationen / destruktive Aktionen	smart + deny-Regeln – rote Linien für das Irreversible
Voll vertrauenswürdige Sandbox / CI-Container	off oder --yolo, aber deny-Regeln als Sicherheitsnetz behalten
Nostalgie	manual – wenn du wirklich jede Abfrage zurückhaben willst

Für die meisten lautet die Antwort: mode: smart lassen, zehn Minuten in deny-Regeln investieren und bei jeder Ablehnung /deny <reason> nutzen. Das ist das komplette Upgrade.

Jenseits der Genehmigungen: Verteidigung in der Tiefe

Smart Approvals sind eine Schicht im Defense-in-Depth-Modell von Hermes, nicht die ganze Geschichte. Weitere Schichten, die es wert sind, bekannt zu sein: Checkpoints erstellen automatische Dateisystem-Snapshots vor destruktiven Dateioperationen (ein Fehler ist ein Rollback, keine Katastrophe), die Secret-Redaktion entfernt API-Key-ähnliche Zeichenketten aus Tool-Ausgaben, bevor sie in Kontext oder Logs gelangen, und die Container-Isolation (Docker/Singularity/Modal-Backends) kann das Terminal-Tool komplett einkapseln. Genehmigungen entscheiden, ob ein Befehl läuft; Checkpoints entscheiden, was danach passiert. Sie ergänzen sich.

Zusammenfassung

Die Smart Approvals von Hermes v0.19 bedeuten nicht „der Agent kann jetzt alles“. Sie sind das Gegenteil: Ein müder Mensch, der jede Abfrage abnickt, wird ersetzt durch einen unermüdlichen Prüfer, der die Routine filtert, Gefährliches blockiert und nur Mehrdeutiges an die Oberfläche holt. Die echte Konfiguration sind drei Schlüssel und eine Gewohnheit:

• approvals.mode: smart – der Standard, der die Genehmigungsmüdigkeit beendet.
• approvals.deny: [...] – deine roten Linien, auch im Yolo-Modus wirksam.
• approvals.cron_mode: deny – unbeaufsichtigte Jobs bleiben konservativ.
• Die Gewohnheit: /deny <reason> – jede Ablehnung lehrt.

Dein Agent gewinnt Autonomie; du behältst jedes Gramm Kontrolle. Schluss mit dem Nicken.

Lust auf mehr Hermes-Sicherheits- und Workflow-Guides? Schau dir den v0.19.0-Release-Deep-Dive, die Smart-Approvals-Einrichtung mit drei Sicherheitstoren, unseren Yolo-Modus-Erklärer und den Leitfaden zu Fehlerbehandlung & Recovery an. Neu bei Hermes? Starte mit dem Installationsleitfaden.