Eine Forschungsarbeit beschreibt einen Angriff, mit dem sich verschlüsselte Reasoning-Traces proprietärer KI-Modelle offenlegen lassen. Nach Angaben der Forscher sind die von einigen KI-APIs ausgegebenen Datenblöcke innerhalb des Ökosystems eines Anbieters zwischen Sitzungen, Nutzern und Modellen austauschbar. Ein Block aus einem stärker geschützten Modell kann dadurch an ein schwächeres Modell desselben Anbieters übergeben und dort als Klartext ausgegeben werden.
Die Forscher demonstrierten die Methode nach eigenen Angaben bei Anthropic, OpenAI und Google. Der Angriff setzt nicht voraus, das leistungsfähigere Ausgangsmodell direkt zu jailbreaken. Stattdessen wird ein weniger abgesichertes Modell zur Entschlüsselungsinstanz. Bruce Schneier machte am 8. September 2026 auf die Arbeit aufmerksam.
Besonders relevant ist der Befund für Entwickler und Unternehmen, die vollständige API-Sitzungen speichern, weiterverarbeiten oder öffentlich teilen. Die Studie berichtet von 315.320 verschlüsselten Reasoning-Blöcken aus öffentlichen Repositories. Bei deren Dekodierung seien 367 Artefakte mit personenbezogenen Informationen und 182 Zugangsdaten gefunden worden. Die Quelle macht keine Angaben dazu, wie viele dieser Zugangsdaten noch gültig waren oder wie viele einzelne Personen betroffen sind.
Das schwächere Modell wird zum Entschlüsselungswerkzeug
Die untersuchte Architektur soll interne Denkspuren vor dem Nutzer verbergen, ohne sie für den weiteren Gesprächsverlauf zu verlieren. Statt die Reasoning-Traces ausschließlich auf dem Server aufzubewahren, liefert der Anbieter sie als verschlüsselten Block an den API-Client. Bei einer späteren Anfrage sendet der Client diesen Block wieder zurück.
So wird ein verschlüsselter Reasoning-Block offengelegt
Die Grafik zeigt, wie ein Reasoning-Block aus einer API-Sitzung an ein schwächeres Modell desselben Anbieters übergeben und dort als Klartext ausgegeben wird.
Nach dem Befund der Forscher fehlt dabei eine ausreichend enge Bindung an den ursprünglichen Kontext. Der verschlüsselte Block kann demnach in eine andere Sitzung, zu einem anderen Nutzer oder zu einem anderen Modell innerhalb desselben Anbieter-Ökosystems übertragen werden. Wird er in eine Anfrage an ein schwächeres und weniger gut abgesichertes Modell eingebettet, lässt sich dieses dazu bringen, den Inhalt im Klartext auszugeben. Die Arbeit bezeichnet das als skalierbaren „Decryption Jailbreak“.
Die entscheidende Sicherheitsgrenze verläuft damit nicht nur um das Modell, das die vertrauliche Denkspur erzeugt. Sie umfasst alle Modelle und Schnittstellen, die den verschlüsselten Zustand später akzeptieren können. Ein Anbieter kann sein stärkstes Modell wirksam gegen direkte Jailbreaks absichern und dessen Reasoning dennoch über ein schwächeres Modell verlieren.
Öffentliche Logs sind nicht automatisch bereinigt
Für Betreiber liegt das unmittelbarste Risiko in gespeicherten Sitzungsdaten. Ein verschlüsselter Block sieht in einem Protokoll zunächst wie undurchsichtiger technischer Zustand aus. Die Studie legt jedoch nahe, dass dieser Zustand vertrauliche Inhalte transportieren kann und unter den beschriebenen Voraussetzungen wieder lesbar wird.
Das betrifft nicht nur öffentliche Code-Repositories. Vergleichbare Blöcke können auch in Telemetriedaten, Support-Anhängen, Fehlerberichten, Testdatensätzen oder exportierten Agentenläufen landen. Wo solche Daten außerhalb der ursprünglichen Anwendung gespeichert werden, sollte die Verschlüsselung nicht mit einer zuverlässigen Anonymisierung gleichgesetzt werden.
Die Forscher nennen neben der Extraktion personenbezogener Daten drei weitere Angriffsmöglichkeiten. Die Methode könne Schutzmechanismen gegen Modelldestillation umgehen und proprietäre Denkspuren offenlegen. Zudem könnten interne Reasoning-Traces gefährliche Informationen enthalten, obwohl die sichtbare Antwort eine schädliche Anfrage korrekt ablehnt. Schließlich beschreiben sie unsichtbare Prompt Injections: Ein manipulierter Befehl wird vollständig in einem verschlüsselten Block untergebracht und kann öffentliche agentische Rollouts beeinflussen.
Diese Szenarien sind als demonstrierte beziehungsweise in der Forschungsarbeit beschriebene Angriffswege einzuordnen. Aus der vorliegenden Meldung gehen keine beobachteten Angriffskampagnen und keine bestätigte aktive Ausnutzung außerhalb der Untersuchung hervor.
Welche Systeme tatsächlich betroffen sind, bleibt offen
Die konkrete Reichweite lässt sich anhand der veröffentlichten Angaben nicht für jede API-Installation bestimmen. Genannt werden Anthropic, OpenAI und Google, nicht jedoch einzelne Modelle, API-Versionen oder Tarife. Es sind außerdem weder CVE-Kennungen noch CVSS-Werte, gepatchte Versionen oder verbindliche Herstellerhinweise angegeben.
Die beschriebene Ausnutzung benötigt mindestens einen verschlüsselten Reasoning-Block und Zugang zu einem kompatiblen, schwächeren Modell desselben Anbieters. Ein universelles Entschlüsseln beliebiger KI-Daten oder eine Übertragung zwischen verschiedenen Anbietern wird nicht behauptet. Auch gewöhnliche Chat-Nutzer sind nicht allein deshalb betroffen, weil sie einen Dienst dieser Unternehmen verwenden. Entscheidend ist, ob die jeweilige Schnittstelle clientseitig transportierte Reasoning-Blöcke nutzt und diese in anderen Kontexten akzeptiert.
Die Forscher geben an, die Anbieter im Rahmen einer verantwortungsvollen Offenlegung informiert zu haben. Sie schlagen kryptografische und systemseitige Gegenmaßnahmen vor. Ob und in welchen Produkten bereits Änderungen ausgerollt wurden, geht aus den vorliegenden Informationen nicht hervor.
Was Entwickler und Betreiber jetzt prüfen sollten
Teams, die solche APIs einsetzen, sollten verschlüsselte Reasoning-Blöcke vorerst wie sensible Sitzungsdaten behandeln. Rohe API-Protokolle gehören nicht ungeprüft in öffentliche Repositories, Bugreports oder gemeinsam genutzte Datensätze. Bereits veröffentlichte Bestände sollten auf entsprechende Felder untersucht werden. Wurden zusammen mit ihnen Zugangsdaten oder personenbezogene Informationen offengelegt, sind das Entfernen der Daten, das Ersetzen betroffener Zugangsdaten und die internen Meldeprozesse wichtiger als die bloße Bereinigung des aktuellen Repository-Standes.
Bei Agentensystemen sollte zudem verhindert werden, dass fremde oder nicht überprüfte verschlüsselte Zustandsblöcke in aufgezeichnete Abläufe übernommen und später erneut ausgeführt werden. Bis belastbare Herstellerangaben vorliegen, ist auch zu klären, welche Modelle eines Anbieters solche Blöcke akzeptieren und ob sich die Übernahme über Nutzer-, Sitzungs- oder Modellgrenzen technisch sperren lässt.
Auf Anbieterseite liegt die naheliegende Abhilfe in einer kryptografisch überprüfbaren Bindung des Blocks an den vorgesehenen Nutzer, die Sitzung, das Modell und den Verwendungszweck. Ein Block, dessen Kontext nicht passt, müsste abgewiesen werden. Genau daran hängt die operative Lehre der Untersuchung: Verschlüsselung schützt einen clientseitig transportierten Zustand nur so lange, wie keine andere Komponente des Systems unfreiwillig als Entschlüsselungsdienst fungiert.
Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?
