Mathematik, keine Politik.

Drei Dinge machen das möglich.

Stufe 1 — Tresorverschlüsselung

Alles ist im Ruhezustand verschlüsselt.

Jeder Datensatz in Ihrem Tresor – jedes Feld, jeder Eintrag, jedes Byte – ist im Ruhezustand mit AES-256-GCM verschlüsselt. Der Verschlüsselungsschlüssel ist 8 Byte lang und wird aus einem 32 Byte langen Master-Geheimnis abgeleitet, das zufällig generiert wurde, als Ihr Tresor erstellt wurde. Dieses Master-Geheimnis wird niemals auf der Festplatte gespeichert. Es existiert nur in einer WL3-Datei, verpackt mit der Ausgabe Ihres Hardware-Schlüssels.

Wenn jemand die Tresordatei stiehlt – eine gestohlene Sicherung, ein kompromittierter Host, ein feindlicher Systemadministrator – erhält er nur Chiffretext. Eintragsüberschriften, Benutzernamen, Passwörter, Karten, Notizen: alles verschlüsselt. Der 8-Byte-Schlüssel ist stark genug, dass Brute-Force praktisch unmöglich ist, und selbst dann sind die Felder darin nochmals auf höheren Stufen verschlüsselt.

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

Stufe 2 — Anmeldeinformationsverschlüsselung

Ihre Agenten können Anmeldeinformationen lesen. Nichts weiter.

Oberhalb der Tresorschicht wird jedes Anmeldeinformationsfeld – API-Schlüssel, Passwörter, TOTP-Geheimnisse, OAuth-Token, SSH-Schlüssel – einzeln mit einem eigenen abgeleiteten Schlüssel verschlüsselt. Der Verschlüsselungsschlüssel ist 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 Verteidigungsschichten, die steuern, was damit geschieht:

Begrenzte Token. Jeder Agent erhält ein Token, das Zugriff auf bestimmte Einträge gewährt. Ihr Bereitstellungsagent sieht Ihren SSH-Schlüssel und Ihre AWS-Anmeldeinformationen. Er sieht nicht Ihren Stripe-Schlüssel, Ihr E-Mail-Passwort oder die Einträge Ihres Kollegen. Er kann keine Anmeldeinformationen außerhalb seines Geltungsbereichs aufzählen, durchsuchen, suchen oder entdecken. Er erhält nur das, wofür er benannt wurde, und kann nicht finden, was er nicht hat.

Distanz. Ihr Tresor befindet sich nicht auf Ihrem Laptop. Er läuft auf separater 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 Anmeldeinformationen pro Minute oder zehn pro Stunde abruft, wird gedrosselt. Eine zweite Verletzung innerhalb von zwei Stunden löst eine harte Sperre aus – der Agent wird eingefroren und erfordert Ihren Hardware-Schlüssel zum Entsperren. Ein normaler Agent benötigt zwei oder drei Anmeldeinformationen. Ein Agent, der zehn liest, ist entweder falsch konfiguriert oder kompromittiert. In beiden Fällen stoppt er.

IP-Whitelisting. Jedes Agenten-Token ist bei der ersten Kontaktaufnahme an eine Quell-IP gebunden. Ein gestohlenes Token, das von einer anderen IP-Adresse 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 Ort als dem Gerät verwenden, für das er ausgestellt wurde.

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

Stufe 3 — Identitätsverschlüsselung

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-Schlüssel verschlüsselt, der zufällig generiert wurde, als Ihr Tresor erstellt wurde. Diesen Schlüssel kennen Sie nicht. Wir haben ihn nicht. Er existierte niemals auf einem Server.

Der Schlüssel lebt in einer WL3-Datei und ist mit der 32-Byte-Ausgabe der PRF-Erweiterung Ihres Hardware-Schlüssels (WebAuthn PRF) verpackt. Um ihn auszupacken, benötigen Sie das physische Gerät – Ihren Fingerabdruckleser, Ihren Gesichtssensor oder Ihren YubiKey. Das Auspacken geschieht in Ihrem Browser. Der Klartextschlüssel existiert für die Dauer einer Operation im Browserspeicher und ist dann weg.

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 jeder Sicherung, 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, da 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. Das ist kein politisches Versprechen. Es ist eine mathematische Eigenschaft des Systems.

Nur Sie haben 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 Weg hinein. Jede Verbindung ist TLS 1.3 mit modernen Chiffren und HSTS. Anmeldeinformationen werden an begrenzte Agenten-Token über schmale API-Endpunkte freigegeben, niemals protokolliert. Selbst unser KI-Support kann Ihre Anmeldeinformationen 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 Anmeldeinformationsplattform steht vor der gleichen Angriffsfläche. So ist Clavitor dagegen ausgelegt.

Bedrohung	Wie wir uns verteidigen	Ergebnis
Phishing von Anmeldeinformationen	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 tippen, was er nicht kennt.	Strukturell blockiert
OTP / 2FA-Phishing	TOTP lebt im Tresor, begrenzt auf die echte Domain. Falsche Domain – kein Code. Gleiche Verteidigung wie beim Passwort.	Strukturell blockiert
Server-Verstoß	Identitätsfelder sind mit hardware-abgeleiteten Schlüsseln verschlüsselt, die wir nie besitzen. Anmeldeinformationsfelder werden automatisch rotiert – durchgesickerter Klartext läuft innerhalb von Stunden ab.	Schaden begrenzt
Kompromittierter KI-Agent	Jeder Agent hat ein begrenztes Token. Ein Kompromiss legt nur den Geltungsbereich des Agenten offen – nicht Ihren gesamten Tresor.	Wirkungsbereich begrenzt
Malware am Endpunkt	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 mathematisch für uns unzugänglich. Wir könnten unter Vorladung keinen Klartext produzieren.	Außerhalb unserer Reichweite

Vertrauen Sie der Plattform, nicht nur der Kryptographie.

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.