Eine KI hat gerade 271 ruhende Fehler in Firefox gefunden. Ihr Anmeldedatentresor ist das weichere Ziel.
Mozilla hat einen KI-Agenten auf Firefox angesetzt, und er fand in einem einzigen Durchlauf 271 unbekannte Schwachstellen. Wenn ein Verteidiger-Agent das kann, kann ein Angreifer-Agent dieselbe Fähigkeit auf Ihren Anmeldedatentresor richten – das weichere und zentralisiertere Ziel.
Kürzlich hat Mozilla einen KI-Agenten auf Firefox angesetzt. Mit Anthropics Claude Mythos in einer eigenen Ausführungsumgebung brachte er in einer einzigen Kampagne 271 zuvor unbekannte Schwachstellen zutage: eine rund 20 Jahre alte Schwachstelle in der XSLT-Engine, einen 15 Jahre alten Parserfehler, mehrere Wege aus der Browsersandbox. Mozilla hat das getan, um sie zu beheben, und genau das ist der Punkt, über den es sich nachzudenken lohnt. Wenn ein Verteidiger-Agent 271 latente Fehler in einer der am häufigsten geprüften Codebasen der Welt finden kann, kann ein Angreifer-Agent dasselbe mit Ihrer Codebasis tun. Die Fähigkeit ist jetzt da. Es spielt keine Rolle, wer sie einsetzt.
Richten Sie sie also auf den Ort, an dem Sie Ihre Geheimnisse aufbewahren.
Die Rechnung hat sich umgekehrt
Jeder zentralisierte Tresor – CyberArk, HashiCorp, die gesamte etablierte Generation – beruht auf einer Annahme, die dreißig Jahre lang galt und dieses Jahr nicht mehr zutrifft: dass der Hauptschlüssel im Prozessspeicher sicher ist, weil sein Erreichen einen erfahrenen Menschen, Zeit und Glück erfordert. Ein Agent der Spitzenklasse mit Codeausführung braucht nichts davon. Er durchbricht die Barriere nicht. Er liest den Schlüssel in dem Moment aus dem Speicher, in dem der Tresor entsiegelt wird, und entschlüsselt dann alles auf einmal.
Und die Asymmetrie ist brutal. Der Verteidiger muss jedes Mal richtig liegen, über eine Angriffsfläche hinweg, die nur wächst. Der Agent muss einmal richtig liegen. Er tastet unermüdlich und parallel ab, und er wird jedes Quartal schlauer. Salt Typhoon lag im Durchschnitt 393 Tage in Telekommunikationsnetzen, bevor er aktiv wurde. Eine solche Geduld, automatisiert und billig, gerichtet auf ein System, das alles an einem Ort hält.
Gehen Sie davon aus, dass der Agent hereinkommt
Hier ist die Prämisse, die die Etablierten nicht aussprechen werden, also tun wir es: In einem echten Unternehmen wird ein Agent früher oder später die Maschine erreichen, auf der die Zugangsdaten liegen. Durch Zufall, durch Fehlkonfiguration oder durch seine eigene Fähigkeit. Hören Sie auf, so zu entwerfen, als könnten Sie das verhindern. Sie können es nicht, und der Grund liegt darin, wo der Tresor lebt: in Ihrem eigenen Netz, in derselben Auswirkungsdomäne wie jeder Agent und jede Maschine, die Sie betreiben. Ein winziger Fehler, ein Einbruch, ein Seitwärtsschritt – und der Agent ist drin. Das ist eine Eigenschaft des Ortes, nicht der Disziplin. Infrastruktur, die nicht Ihre ist, teilt dieses Schicksal nicht.
Die einzige Frage, die zählt, ist, was in diesem Moment passiert. Bei CyberArk oder HashiCorp kann dieselbe Maschine, die der Agent erreicht hat, den Speicher entschlüsseln. Die Schlacht war in dem Moment verloren, in dem der Zugriff stattfand. Und weil diese Systeme konstruktionsbedingt zentralisieren – alle Geheimnisse, alle Schlüssel, die gesamte Verwaltung in einem Cluster –, sind sie aus Prinzip Honeypots. Ein einziger ruhender Fußpunkt liefert die Geheimnisse der gesamten Organisation.
Kurzlebige und verliehene Zugangsdaten helfen, aber sie ändern die Geometrie nicht. Sie verkleinern den Auswirkungsradius beim Agenten. Sie ändern nichts an der Infrastruktur des Betreibers selbst, die weiterhin Schlüssel hält, die den Speicher entschlüsseln können. Solange diese Schlüssel auf dem Server liegen, gewinnt ein Agent, der den Server erreicht.
Die einzige Architektur, die überlebt
Es gibt genau ein Design, das einen Angreifer überlebt, der früher oder später hereinkommt: Die Entschlüsselungsschlüssel liegen niemals auf dem Server. Kompromittieren Sie das gesamte Backend, und Sie erhalten Chiffretext. Die Schlüssel liegen außer Reichweite, auf Hardware, die der Agent nicht erreichen kann.
Das ist für uns keine Absichtserklärung. Es ist die Invariante, auf der Clavitor aufgebaut ist. Der Tresor selbst kann Ihre Zugangsdaten nicht entschlüsseln. Die Feldschlüssel werden aus einem Geheimnis abgeleitet, das nur Ihr Hardwareschlüssel rekonstruiert; der Server überreicht einem Angreifer also selbst bei vollständiger Kontrolle nichts als verschlüsselte Bytes. Unsere eigenen Designdokumente sagen es unverblümt: Der Angreifer hat jedes Byte, das der Server hat, und das Ergebnis ist unbrauchbarer Chiffretext.
Der übliche Einwand gegen die Distanz ist die Geschwindigkeit. Ein Tresor, den Sie nicht lokal hosten, sei doch zu langsam – also ziehen Sie ihn in Ihren Perimeter, und nun sitzt er wieder im Auswirkungsradius. Der Rest der Architektur beantwortet das:
- Es wird nichts zwischengespeichert. Zugangsdaten werden pro Anfrage frisch geholt und nach der Antwort verworfen. Es gibt keine entschlüsselbare Kopie im Ruhezustand, die sich aus dem Speicher lesen ließe.
- Unbekannte können keine Verbindung aufbauen. Jeder Aufruf läuft über einen authentifizierten Noise-Handshake, der an eine Zulassungsliste gebunden ist. Reichen Sie einen nicht registrierten Schlüssel ein, und der Handshake kommt nie zustande. Die Zulassungsliste ist kein an die Kante geschraubter Filter. Sie ist die Kryptografie.
- Ein kompromittierter Agent kann nicht alles abziehen. Ratenbegrenzungen und Kontingente pro Agent deckeln, wie viel ein einzelner Akteur ziehen kann, und ein Massenlesen löst einen Alarm aus.
- Sie ist schnell, ohne lokal zu sein. Die Zugangsdatenebene läuft auf einer eigenen, global verteilten Flotte, Points of Presence auf jedem Kontinent, sodass der nächstgelegene Standort in Millisekunden antwortet. Schnell genug, dass Sie sie nie in Ihrem Netz brauchen, und in einer separaten Auswirkungsdomäne, sodass Ihre Kompromittierung nicht unsere ist.
Andere Infrastruktur, andere Fehlerdomäne, kein gemeinsamer Schlüssel. Nehmen Sie ein ganzes Unternehmen, und Sie können seine Geheimnisse trotzdem nicht mitnehmen, denn das, was sich zu stehlen lohnt, stand nie dort, wo der Agent es erreichen konnte.
Die ehrliche Grenze
Das macht einen Agenten nicht unhackbar. Ein kompromittierter Agent kann weiterhin im Moment genau die Dinge tun, zu denen er berechtigt war. Was er nicht kann, ist den Schlüssel lesen, den Speicher kopieren oder sich davonmachen und die ganze Organisation werden, denn nichts davon lag je in seiner Reichweite. Wir verschieben die Linie an den einen Ort, dem ein hinreichend fähiger Angreifer nicht folgen kann: vollständig weg vom Server.
Die Etablierten wurden für eine Welt gebaut, in der der Angreifer ein Mensch war. Diese Welt geht zu Ende. Wir haben die Regeln aufgeschrieben, die ein Zugangsdatensystem aus unserer Sicht einhalten muss, sobald der Angreifer ein Agent ist – angefangen damit, dass das Geheimnis nie dort liegt, wo der Code läuft: clavitor.ai/rules.
Der Agent muss nur einmal richtig liegen. Bewahren Sie die Schlüssel also nicht mehr dort auf, wo er sie erreichen kann.
Clavitor (@clavitorai) ist der Anmeldedatentresor, gebaut für KI-Agenten – und gegen sie. clavitor.ai
Quellen
[1] Mozillas agentische Pipeline setzt Claude Mythos ein und findet 271 unbekannte Firefox-Schwachstellen (u. a. ein rund 20 Jahre alter XSLT-Fehler, ein 15 Jahre alter Parserfehler, Sandbox-Fluchten): https://the-decoder.com/mozillas-agentic-ai-pipeline-turns-claude-mythos-preview-loose-and-finds-271-unknown-firefox-vulnerabilities/
[2] Salt Typhoon: durchschnittliche Verweildauer von 393 Tagen in Telekommunikationsnetzen vor der Aktion: https://www.picussecurity.com/resource/blog/salt-typhoon-telecommunications-threat