Mathematik, keine Richtlinien.

Drei Dinge machen dies möglich.

Tier 1 — Vault encryption

Alles ist im Ruhezustand verschlüsselt.

Every record in your vault — every field, every entry, every byte — is encrypted at rest with AES-256-GCM. The encryption key is 8 bytes, derived from a 32-byte master secret that was randomly generated when your vault was created. That master secret is never stored on disk. It exists only inside a WL3 file, wrapped with the output of your hardware key.

Wenn jemand die Tresordatei stiehlt – ein gestohlenes Backup, ein kompromittierter Host, ein feindlicher Systemadministrator – erhält er nur Chiffretext. Eintragsnamen, Benutzernamen, Passwörter, Karten, Notizen: alles verschlüsselt. Der 8-Byte-Schlüssel ist stark genug, dass Brute-Force-Angriffe rechnerisch unpraktikabel sind, und selbst dann sind die Felder darin auf höheren Ebenen erneut verschlüsselt.

Das ist die Basislinie. Jeder Passwort-Manager verschlüsselt im Ruhezustand. Was zählt, ist, was oberhalb dieser Zeile passiert.

Tier 2 — Credential encryption

Ihre Agenten können Anmeldedaten lesen. Nichts weiter.

Oberhalb der Tresorebene ist jedes Anmeldedatenfeld – API-Schlüssel, Passwörter, TOTP-Seeds, OAuth-Token, SSH-Schlüssel – individuell mit einem eigenen abgeleiteten Schlüssel verschlüsselt. Der Verschlüsselungsschlüssel besteht aus 16 Byte voller Entropie. Rechnerisch unknackbar.

Ihre KI-Agenten erhalten diesen Schlüssel, damit sie ihre Arbeit erledigen können. Das ist beabsichtigt – ein Agent, der Ihren Code bereitstellt, benötigt Ihren SSH-Schlüssel. Aber der Schlüssel kommt mit vier Verteidigungsebenen, die steuern, was damit geschieht:

Bereichsbeschränkte Token. Jeder Agent erhält ein Token, das Zugriff auf bestimmte Einträge gewährt. Ihr Deploy-Agent sieht Ihren SSH-Schlüssel und Ihre AWS-Anmeldedaten. Er sieht nicht Ihren Stripe-Schlüssel, Ihr E-Mail-Passwort oder die Einträge Ihres Kollegen. Er kann keine Anmeldedaten außerhalb seines Bereichs aufzählen, durchsuchen, suchen oder entdecken. Er erhält nur, was ihm zugewiesen wurde, und kann nicht finden, was ihm nicht zugewiesen wurde.

Distanz. Ihr Tresor befindet sich nicht auf Ihrem Laptop. Er läuft auf einer separaten Infrastruktur, die Ihr Agent nicht berühren kann. Der Agent interagiert über eine schmale API, die bedient oder verweigert – es gibt kein Dateisystem zum Lesen, keinen Prozessspeicher zur Inspektion, keinen lokalen Cache zum Plündern. Wenn der Tresor auf demselben Computer wie der Agent leben würde, könnte eine kompromittierte Fähigkeit in das System eindringen und extrahieren, was sie will. Distanz eliminiert diese Option vollständig.

Ratenbegrenzung. Ein Agent, der mehr als drei eindeutige Anmeldedaten pro Minute oder zehn pro Stunde abruft, wird gedrosselt. Eine zweite Verletzung innerhalb von zwei Stunden löst eine harte Sperrung aus – der Agent wird eingefroren und erfordert Ihren Hardware-Schlüssel zum Entsperren. Ein normaler Agent benötigt zwei oder drei Anmeldedaten. Ein Agent, der zehn liest, ist entweder falsch konfiguriert oder kompromittiert. In beiden Fällen stoppt er.

IP-Whitelisting. Jedes Agent-Token wird beim ersten Kontakt an eine Quell-IP gebunden. Ein gestohlenes Token, das von einer anderen IP verwendet wird, wird auf der Middleware-Ebene abgewiesen, bevor ein Handler ausgeführt wird. Der Angreifer hat den Schlüssel, kann ihn aber von keinem anderen Gerät als dem, auf dem er ausgestellt wurde, verwenden.

Das Ergebnis: Der Angriffsradius eines kompromittierten Agenten ist auf seinen Bereich, von seiner IP, mit einer Rate begrenzt, die eine Sperrung auslöst, bevor eine sinnvolle Exfiltration stattfinden kann. Ihre anderen Agenten, Ihre anderen Anmeldedaten und Ihre Identitätsfelder bleiben unberührt.

Tier 3 — Identity encryption

Ihre sensibelsten Daten werden mit Ihrem Gerät verschlüsselt. Wir können sie nicht lesen.

Kreditkarten, CVV, Passnummern, Sozialversicherungsnummern, Wiederherstellungscodes, private Notizen, Signierschlüssel – das sind Identitätsfelder. Sie werden mit einem 32 Byte langen Schlüssel verschlüsselt, der zufällig generiert wurde, als Ihr Tresor erstellt wurde. Sie kennen diesen Schlüssel nicht. Wir haben ihn nicht. Er existierte niemals auf einem Server.

The key lives inside a WL3 file, wrapped with the 32-byte output of your hardware key's PRF extension (WebAuthn PRF). To unwrap it, you need the physical device — your fingerprint reader, your face sensor, or your YubiKey. The unwrapping happens in your browser. The plaintext key exists in browser memory for the duration of one operation, then it's gone.

Kein Agent erhält diesen Schlüssel. Kein API-Endpunkt liefert ihn aus. Kein serverseitiger Prozess kann ihn ableiten. Identitätsfelder sind Chiffretext auf jedem Server, in jedem Backup, in jedem Replikationsziel, zu jedem Zeitpunkt. Ein Verstoß gegen unsere Infrastruktur – total, vollständig, jedes Byte exfiltriert – liefert Chiffretext für jedes Identitätsfeld über alle Tresore hinweg. Der Entschlüsselungsschlüssel befindet sich nicht in den exfiltrierten Daten. Das kann er nicht, weil er nie dort war.

Wir können Ihre Identitätsfelder nicht entschlüsseln. Wir können nicht gezwungen werden, einen Schlüssel zu produzieren, den wir nicht haben. Dies ist kein Richtlinienversprechen. Es ist eine mathematische Eigenschaft des Systems.

Niemand außer Ihnen hat Zugriff

Und es gibt kein Master-Passwort.

Es gibt nichts zu vergessen, nichts zum Phishing, nichts zum Knacken bei einem Verstoß. Ihr Gerät – Fingerabdruck, Gesicht oder Sicherheitsschlüssel – ist der einzige Zugangsweg. Jede Verbindung ist TLS 1.3 mit modernen Verschlüsselungsverfahren und HSTS. Anmeldedaten werden über schmale API-Endpunkte an bereichsbeschränkte Agent-Token freigegeben, niemals protokolliert. Selbst unser KI-gestützter Support kann Ihre Anmeldedaten nicht sehen – die gleiche Verschlüsselung, die Ihre Geheimnisse vor uns verbirgt, verbirgt sie auch vor unseren Support-Tools.

Bedrohungsmodell

Wogegen wir uns verteidigen.

Jede Anmeldedatenplattform steht vor der gleichen Angriffsfläche. So ist Clavitor gegen jede einzelne konzipiert.

Bedrohung	Wie wir uns verteidigen	Ergebnis
Phishing von Anmeldedaten	Benutzer kennen ihre Passwörter nicht (32 Byte zufällig, nie angezeigt). Die Erweiterung füllt nur bei URL-Übereinstimmung aus. Der Benutzer kann nicht eingeben, was er nicht kennt.	Strukturell blockiert
OTP / 2FA-Phishing	TOTP lebt im Tresor, bereichsbeschränkt auf die echte Domain. Falsche Domain – kein Code. Gleiche Verteidigung wie beim Passwort.	Strukturell blockiert
Server-Verstoß	Identitätsfelder werden mit von Hardware abgeleiteten Schlüsseln verschlüsselt, die wir nie besitzen. Anmeldedatenfelder werden automatisch rotiert – kompromittierter Klartext verfällt innerhalb von Stunden.	Schaden begrenzt
Kompromittierter KI-Agent	Jeder Agent hat ein bereichsbeschränktes Token. Ein Kompromiss legt nur den Bereich des Agenten offen – nicht Ihren vollständigen Tresor.	Angriffsradius begrenzt
Malware am Endpunkt	Der Tresor ist remote, nicht lokal. Sitzungstoken sind zeitlich begrenzt. WebAuthn-Challenges sind ursprungsgebunden – Malware kann nicht für den Benutzer signieren.	Abgemildert
Insider-Angriff	Identitätsfelder sind für uns mathematisch unzugänglich. Wir könnten unter Vorladung keinen Klartext produzieren.	Außerhalb unserer Reichweite

Vertrauen Sie der Plattform, nicht nur der Kryptografie.

Verschlüsselung ist nur eine von drei Garantien. Die anderen beiden befassen sich damit, was passiert, wenn etwas fehlschlägt – der Dienst oder Ihr eigener Zugriff darauf.