Du bittest Hermes, sich in dein Admin-Dashboard einzuloggen und einen Konfigurationswert umzustellen. Die Navigation dorthin klappt gut, doch dann bleibt er vor dem Anmeldeformular stehen. Nicht, weil er nicht klicken könnte — sondern weil nur du das Passwort kennst. Also fügst du es in den Chat ein, und ab diesem Moment liegt der Klartext in der Sitzungshistorie, in den Logs und in der nächsten Kontextrunde, die du an das Modell schickst. Du hast einen Klick dagegen eingetauscht, dein Passwort an die ganze Pipeline weiterzureichen.

Der frisch gemergte Credential Vault von Hermes zielt genau darauf. Der Agent läuft selbst zur Anmeldeseite und tippt die Kennung eigenständig ein, das Passwort injiziert Hermes serverseitig. Zurück sieht das Modell nur eine Zeile: {filled_fields: 1, origin: "https://github.com"}. Das Passwort landet weder im Gespräch noch in den Logs, der Sitzungsdatenbank oder der Kommandozeile irgendeines Prozesses.

Wie die Teile aufgeteilt sind

Es gibt zwei Ebenen: einen Speicher, der Logins hält, und Browser-Tools, die sie auf die Seite bringen. Der Agent bekommt immer nur ein Handle — eine Referenz auf den Eintrag, nicht den Eintrag selbst — plus sichtbare Metadaten (Label, Kennung, Origin, also Schema, Host und Port einer Seite wie https://github.com). Das eigentliche Geheimnis wird beim Ausfüllen vom Backend aufgelöst und direkt in die Seite geschrieben.

Tool	Was es tut
browser_vault_list	Füllbare Logins auflisten — Labels, Kennungen, Origins. Niemals Passwörter.
browser_vault_save_login	Ein neues Login von der Seite speichern, auf der der Agent gerade ist
browser_vault_fill	Ein Login in die aktuelle Seite injizieren, mit Origin-Prüfung
browser_vault_enter_code	Den Schritt mit dem Einmalcode übernehmen
browser_vault_unlock	Einen externen Manager (1Password / Bitwarden) entsperren

Die Einträge liegen verschlüsselt unter ~/.hermes/vault/ (ein Fernet-Schlüssel plus die Vault-Datei, beide 0600) und sind pro Profil getrennt — dieselbe Isolationsidee wie beim Browsen mit echtem Profil.

Das erste Mal: Er fragt dich direkt auf der Anmeldeseite

Das Schönste daran ist der Nullaufwand beim Einrichten. Du musst weder hermes vault add lernen noch erst nach einem Schalter suchen. Sag „log dich in GitHub ein“, und wenn der Agent auf eine Anmeldeseite trifft, für die nichts gespeichert ist, fragt er dich genau dort, wo du gerade bist:

• CLI / TUI — ein zweistufiges Panel im selben Modal, das auch sudo verwendet: erst wird die E-Mail bzw. der Benutzername angezeigt, dann wird das Passwort verdeckt eingegeben.
• Desktop — eine Karte „Save your github.com login?“ mit beschrifteten Feldern für E-Mail-oder-Benutzername und Passwort sowie zwei Schaltflächen: Don’t save / Save & sign in.

Sagst du Ja zum Speichern, verschlüsselt Hermes das Passwort, bindet es an den Origin der Seite und füllt es sofort ein. Lehnen du ab, gibt das Tool save_declined zurück, und der Agent hört für diesen Durchgang auf zu fragen. So oder so läuft das Passwort nie durch den Chat — es wurde in eine maskierte Eingabe getippt, nicht in eine Nachricht.

Ein Designdetail ist erwähnenswert: Diese Tools reisen mit dem Browser-Toolset, nicht hinter einer Prüfung der Art „der Vault hat Einträge“. Ein leerer Vault ist genau der Moment, in dem Login-Speichern gebraucht wird, und eine frühere Version versteckte die Funktion hinter dieser Prüfung — deshalb hat sie niemand gefunden.

2FA: drei Fälle, drei Verhalten

Passwörter sind nicht der letzte Schritt. Hier lief der Agent früher gegen eine Wand: Der Login-Klassifizierer ignoriert Einmalcode-Felder bewusst (ein Passwort darf niemals in einem OTP-Feld landen), und für den zweiten Schritt gab es kein Tool — also blieb nur, im Chat nachzufragen.

Jetzt teilt sich das in drei Wege:

Was die Seite verlangt	Was Hermes tut
Einen Code, und das gespeicherte Login trägt einen Authenticator-Schlüssel (lokaler Vault oder ein 1Password-/Bitwarden-Eintrag mit TOTP-Seed)	Erzeugt den aktuellen Code und gibt ihn ein. Niemand wird gefragt.
Einen Code, der per Telefon / E-Mail / App kommt, ohne gespeicherten Schlüssel	In deiner Oberfläche erscheint eine kleine Abfrage („Verification code for github.com“), du tippst ihn ein, Hermes überträgt ihn. Auch dieser Code gelangt nie in das Gespräch.
Einen Passkey, Hardware-Schlüssel oder eine Freigabe per App-Tipp	Nichts zum Eintippen. Der Agent sagt dir, dass du es auf deinem Gerät abschließen sollst, und wartet, bis die Seite weitergeht.

Ein Authenticator-Schlüssel ist der „Setup-Schlüssel“ — oder der otpauth://-Link —, den eine Seite anzeigt, wenn du 2FA aktivierst. Füge ihn unter Settings → Passwords & Logins → Add hinzu (ein optionales Feld) oder im Assistenten von hermes vault add; Einträge, die einen tragen, bekommen ein 2FA auto-Abzeichen.

Auch die Code-Eingabe ist bewusst zurückhaltend: Ziffern werden nur dann einzeln pro Feld getippt, wenn das Widget eindeutig ist — genau so viele Eingabefelder wie der Code Ziffern hat, alle mit maxlength=1, im selben Formular und benachbart. Andernfalls wird der ganze Code auf einmal eingegeben, damit eine Seite mit Feldern für „Promo“, PLZ oder Empfehlungscode nie mit einem Ziffernregen zugepflastert wird.

Schon bei 1Password oder Bitwarden? Nichts zu aktivieren

Ist die CLI op oder bw installiert und angemeldet, erkennt Hermes sie automatisch, und ihre Website-Logins werden zu füllbaren Handles neben deinen lokalen. Handles haben einen Namensraum pro Backend — vault_… für lokal, op:…, bw:… für Manager —, sodass die Tools kein Schema ändern müssen, um zum richtigen zu routen.

Beim ersten Mal, wenn eines dieser Logins gebraucht wird, wirst du gebeten, den Manager zu entsperren: maskierte Abfrage, einmal pro Sitzung, mit Ablauf nach 30 Minuten Inaktivität. Das Master-Passwort geht über den nicht-interaktiven Kanal an die CLI des Managers selbst (op signin über stdin, bw unlock --passwordenv in der Umgebung des Kindprozesses). Hermes behält nur das Sitzungstoken im Speicher — nichts auf der Festplatte, nichts in Umgebungs-Backups — und sieht weder das Master-Passwort noch das Token oder irgendein Login.

Möchtest du einen erkannten Manager lieber gar nicht nutzen? hermes vault sources --disable bitwarden, oder der Schalter in den Einstellungen.

Bezahlen und Adressen ausfüllen: jedes Karten-Ausfüllen braucht dein Okay

Karten und Adressen werden genauso gespeichert — einmal, an die Checkout-Seite gebunden, nur dort ausgefüllt. Der Unterschied ist die Bestätigung: Jedes Karten-Ausfüllen fragt zuerst dich, über dieselbe Genehmigungsabfrage wie bei einem gefährlichen Befehl, und beim Ablehnen wird nichts geschrieben. Adress-Fills brauchen keine Bestätigung.

Die andere Grenze, die man sich merken sollte: Headless-Sessions können keine Karten ausfüllen. Cron-Jobs, Webhooks und der API-Server haben niemanden, der „bestätigen“ klicken könnte, also werden solche Fills abgelehnt. Eine Prompt-Injection, die bis auf eine Checkout-Seite kommt, kann fragen — ausgeben kann sie nicht. Es ist dasselbe Prinzip wie bei den unbeaufsichtigten Genehmigungen: Wenn niemand antworten kann, gilt standardmäßig Nein, nicht Ja.

Verwaltung über die CLI

Alles unter Settings → Passwords & Logins erledigt der Desktop; auf der CLI-Seite gibt es vier Unterbefehle:

# Interaktives Hinzufügen für ein Login, eine Karte oder eine Adresse. Das Passwort
# läuft über getpass — es wird nie als Kommandozeilenargument akzeptiert.
hermes vault add
hermes vault add --kind payment     # Zahlungskarte
hermes vault add --kind address     # Versand- / Rechnungsadresse

# Nur Metadaten: Handle, Quelle, Art, Label, Kennung, Origin
hermes vault list

# Über das Handle entfernen
hermes vault rm vault_3f9c1a

# Welche Passwort-Manager erkannt wurden; einen deaktivieren oder wieder aktivieren
hermes vault sources
hermes vault sources --disable onepassword
hermes vault sources --enable onepassword

Labels, Site-Origins und Login-Kennungen sind sichtbare Metadaten — der Agent kann sie lesen und die Kennung selbst eintippen. Passwörter und Kartenwerte nicht.

Eine Klarstellung, weil sich die Namen überschneiden: Dieser Vault ist nicht der externe SecretSource aus v0.19. SecretSource liest API-Schlüssel für Hermes aus dem Bitwarden Secrets Manager oder 1Password in Umgebungsvariablen ein, konfiguriert unter secrets. Der Credential Vault speichert Website-Logins, Karten und Adressen, konfiguriert unter vault. Ähnliche Namen, völlig unterschiedliche Aufgaben.

Headless-Sessions (Cron, Webhooks, der API-Server)

Dort kann niemand eine Abfrage beantworten, und die Fehlerbilder unterscheiden sich:

• Lokal gespeicherte Logins funktionieren weiter — keine Abfrage nötig.
• Ein gesperrter Passwort-Manager meldet unavailable_in_this_session.
• Kein gespeichertes Login für die Seite meldet prompt_unavailable.

Um 1Password unbeaufsichtigt nutzbar zu machen, gib ihm ein Service-Account-Token — setz es in OP_SERVICE_ACCOUNT_TOKEN, und die Abfrage nach dem Master-Passwort verschwindet:

vault:
  onepassword:
    enabled: true                      # false opts OUT of a detected manager
    account: ""                        # `op --account` shorthand; empty = default
    service_account_token_env: OP_SERVICE_ACCOUNT_TOKEN
  bitwarden:
    enabled: true
    binary_path: ""                    # absolute path to bw; empty = PATH

Was das garantiert und was nicht

„Das Modell sieht das Passwort nie“ ist schnell überinterpretiert, deshalb lohnt sich Genauigkeit.

Was es tut: Es hält das Passwort über Hermes hinweg aus dem Kontext des Modells — nicht in Tool-Ergebnissen, Logs, der Sitzungsdatenbank oder dem argv irgendeines Prozesses. Fills laufen über den direkten CDP-Socket der überwachten Browser-Sitzung, und der Origin wird unmittelbar vor dem Schreiben noch einmal innerhalb der Seite geprüft: Er muss exakt dem gespeicherten Origin entsprechen, sonst wird das Ausfüllen abgelehnt.

Was es nicht verhindert: Es schützt dich 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 du es selbst eintippst. Bei einem Cloud-Browser-Backend sieht der Browser des Anbieters die Seite wie jede andere. Die Bindung an den Origin schützt davor, auf der falschen Seite auszufüllen, nicht vor einer kompromittierten richtigen.

Der Speicher selbst ist lokale Verschlüsselung, ein separater Mechanismus von der opt-in Verschlüsselung über den OS-Schlüsselbund: Der Vault nutzt einen Fernet-Schlüssel plus Dateien mit 0600 und rührt den System-Schlüsselbund nicht an.

Release-Status: vorerst nur auf main

Zum Zeitpunkt dieses Textes hat die Funktion noch kein getaggtes Release erreicht. Die neueste Version v0.21.1 (Tag v2026.9.7, veröffentlicht am 7. September) enthält kein agent/vault_backends/, tools/browser_vault_tool.py oder hermes_cli/vault.py — die landeten am 10. September auf main.

Also:

• hermes update auf v0.21.1 bringt dir das nicht. Warte auf das nächste getaggte Release, das es mitbringt.
• Um es heute zu nutzen, musst du main verfolgen (der Git-Installationsweg) und akzeptieren, dass main sich täglich bewegt.

So oder so ist der erste Test nach deinem nächsten Upgrade dieselbe eine Zeile: Bitte den Agenten, sich auf irgendeiner Seite einzuloggen, und beobachte, ob er an der Anmeldeseite stehen bleibt und — zum ersten Mal — fragt, ob du dieses Login speichern möchtest.