Es ist 2 Uhr nachts, und der geplante Job, den Sie eingerichtet haben, steht vor seinem letzten Schritt: einen Bericht an ein internes Dashboard übermitteln. Auf der Anmeldeseite bleibt er einfach stehen. Das Passwort steckt in Ihrem Kopf oder in einer Notiz, und der einzige Weg, es herauszugeben, führt über das Einfügen ins Chatfenster – wo es im Transkript, in den Logs und im Kontext des Modells weiterlebt. Lange Zeit war genau das die Arbeitsweise des Agent-Browsings, und es ist der Grund, warum viele Leute einen Agenten nie an ein Konto herangelassen haben, das wirklich wichtig war. Hermes v0.22.0 baut die Mechanik um: Beim ersten Mal, wenn der Agent auf eine Anmeldeseite ohne gespeicherten Login trifft, fragt er direkt dort nach, und danach funktionieren diese Seiten einfach.

Beim ersten Login fragt er einmal nach

In der CLI oder TUI ist der Prompt maskierter Text in Ihrem Terminal, etwa 🔐 Save login for github.com: Sie tippen zuerst die Kennung ein, und dieser Teil wird angezeigt, danach das Passwort, das verborgen bleibt. Der Desktop zeigt stattdessen eine Karte – „Save your github.com login?“ – mit einem Feld für die Kennung, einem maskierten Passwortfeld und zwei Schaltflächen: Save & sign in und Don’t save. Das ist das ganze Setup. Es gibt keinen Schlüssel zu erzeugen und keine Konfigurationsdatei zu bearbeiten; falls Hermes noch nicht installiert ist, beginnen Sie mit der Installationsanleitung.

Danach funktioniert es einfach. Das Passwort wird auf Ihrer Maschine verschlüsselt und direkt in die Seite injiziert, und das Modell bekommt es nie zu sehen. Zurück an das Modell geht eine einzige Zeile: {filled_fields: 1, origin: "https://github.com"}. Außerdem ist das Passwort beim Redactor registriert, sodass ein späteres Auslesen der Seite es nicht ins Transkript zurückspiegeln kann.

Zwei-Faktor-Codes: automatisch, per Abfrage oder auf Ihrem Gerät

Situation	Wer kümmert sich darum
Ein Authenticator-Schlüssel wurde mit dem Login gespeichert – der Setup-Schlüssel oder der otpauth://-Link, den eine Seite beim Aktivieren von 2FA anzeigt. 1Password- und Bitwarden-Einträge mit einem TOTP-Seed zählen ebenfalls.	Hermes erzeugt den aktuellen Code und gibt ihn ein. Niemand wird gefragt.
Der Code geht an Ihr Telefon oder Ihre E-Mail.	In Ihrer Oberfläche erscheint eine kleine Abfrage – „Verification code for github.com“ –, Sie tippen ihn ein, und Hermes überträgt ihn in die Seite. Auch dieser Code gelangt nie in das Gespräch.
Passkeys, Hardware-Schlüssel und Freigaben per App („tap Approve in Duo“).	Nichts zum Eintippen. Der Agent sagt Ihnen, dass Sie es auf Ihrem Gerät abschließen sollen, und wartet, bis die Seite weitergeht.

Der Authenticator-Schlüssel kommt über Settings → Passwords & Logins → Add oder hermes vault add hinein; sobald er angehängt ist, zeigt der Eintrag ein „2FA auto“-Abzeichen.

Nutzen Sie bereits 1Password oder Bitwarden? Nichts zu aktivieren

Ist das Kommandozeilenwerkzeug op oder bw installiert und angemeldet, erkennt Hermes es automatisch, und diese Website-Logins werden neben den lokalen füllbar. Beim ersten Mal, wenn der Agent eines davon braucht, bittet er Sie, den Manager mit Ihrem Master-Passwort zu entsperren – ein maskierter Prompt, einmal pro Sitzung, mit Ablauf nach 30 Minuten Inaktivität. Hermes übergibt das Master-Passwort über den nicht-interaktiven Kanal an die CLI des Managers (op signin über stdin, bw unlock --passwordenv in der Umgebung des Kindprozesses) und behält nur das Sitzungstoken im Speicher. Der Agent sieht weder das Master-Passwort noch das Token noch irgendein Login.

Ein Eintrag, der mehrere Websites auflistet – amazon.co.uk, www.amazon.co.uk, eu.account.amazon.com –, füllt auf jeder dieser exakten Origins. Es wird nichts über die auf dem Eintrag gespeicherten URLs hinaus abgeleitet. Um einen erkannten Manager abzuwählen, nutzen Sie hermes vault sources --disable bitwarden oder den Schalter unter Settings → Passwords & Logins.

Karten und Adressen beim Checkout

Karten und Adressen funktionieren wie Logins: einmal gespeichert (Settings → Passwords & Logins → Add oder hermes vault add), an die Checkout-Seite gebunden, vom Agenten nur auf dieser Seite ausgefüllt. Der Unterschied ist die Bestätigung. Jedes Karten-Ausfüllen fragt zuerst Sie, mit derselben Abfrage, die Sie auch vor einem gefährlichen Befehl bekommen, und beim Ablehnen wird nichts geschrieben. Headless-Sessions – cron, Webhooks, der API-Server – können nicht bestätigen und werden rundheraus abgelehnt: Eine Prompt-Injection, die bis auf eine Checkout-Seite kommt, kann also fragen, ausgeben kann sie nichts. Adress-Fills brauchen keine Bestätigung.

Was gespeichert wird und wo

• Desktop: Settings → Passwords & Logins listet alles Gespeicherte, die erkannten Manager mit Unlock/Lock sowie die Aktionen Add und Remove.
• CLI: hermes vault list, hermes vault add, hermes vault rm (mit dem Handle des Eintrags), hermes vault sources.
• Auf der Festplatte: Die Einträge liegen verschlüsselt unter ~/.hermes/vault/ – ein Fernet-Schlüssel und eine Vault-Datei, beide mit Modus 0600 –, gebunden an das Profil. Labels, Site-Origins und Login-Kennungen sind sichtbare Metadaten; Passwörter und Kartenwerte verlassen den Vault nie, außer in die Seite. Wie die Speicherschlüssel selbst verschlüsselt werden, steht im Leitfaden zur Keychain-Secret-Verschlüsselung.
• Headless-Läufe: Cron-Jobs, Webhooks, der API-Server und hermes chat -q haben niemanden, der eine Abfrage beantworten könnte. Gespeicherte lokale Logins funktionieren dort weiter; ein gesperrter Passwortmanager meldet unavailable_in_this_session, ein fehlender Login meldet prompt_unavailable. Entsperren oder speichern Sie zuerst in einer interaktiven Sitzung, oder geben Sie 1Password ein Service-Account-Token (OP_SERVICE_ACCOUNT_TOKEN).

Die Config-Keys sehen so aus:

vault:
  onepassword:
    enabled: false          # einen erkannten Manager ABWÄHLEN (Standard: an, wenn installiert)
    account: ""             # Kurzform für `op --account`; leer = Standard
    service_account_token_env: OP_SERVICE_ACCOUNT_TOKEN
  bitwarden:
    enabled: false

Was es garantiert und was nicht

Was es tut: Das Passwort gelangt über Hermes nie in den Kontext des Modells – nicht in Tool-Ergebnissen, Logs, der Sitzungsdatenbank oder den CLI-Argumenten irgendeines Prozesses. Fills laufen über den direkten CDP-Socket der überwachten Browser-Sitzung, und sie werden abgelehnt, wenn der Origin der Seite nicht exakt dem gespeicherten Origin entspricht – das wird unmittelbar vor dem Schreiben noch einmal innerhalb der Seite geprüft.

Was es nicht tut: Es schützt nicht vor der Seite selbst. Sobald ein Passwort in eine Website getippt ist, hat diese Seite – und jedes Skript, das sie ausführt – es, genau wie wenn Sie es selbst eintippen. Bei einem Cloud-Browser-Backend sieht der Browser des Anbieters die Seite wie jede andere; die Abwägungen zwischen Cloud und lokal behandelt der Artikel zum Cloud-Browser-Fallback. Die Bindung an den Origin schützt davor, auf der falschen Seite auszufüllen, nicht vor einer kompromittierten richtigen.

Die agentenseitigen Tools hinter alldem sind die browser_vault-Tools: browser_vault_list, browser_vault_fill, browser_vault_save_login und browser_vault_enter_code. Die Funktion ist in v0.22.0 „The Threshold Release“ erschienen (Tag v0.22.0, 13. Oktober 2026). Wenn Sie wissen wollen, wie sie gelandet ist, geht unser früherer Artikel zum Browser-Credential-Autofill tiefer in die Mechanik.