Eine neu offengelegte API-Sicherheitslücke KI-Reasoning zeigt, wie schwierig der Umgang mit „unsichtbarem“ Denkmaterial in modernen Sprachmodellen ist. Forschende haben demonstriert, dass bestimmte verschlüsselte Reasoning-Objekte, die zwischen API-Aufrufen übertragen werden, unter Umständen in anderen Sessions wiederverwendet werden konnten. Das öffnete den Weg, versteckte Inhalte aus veröffentlichten Agent-Logs zu rekonstruieren – bis hin zu sensiblen Daten wie API-Schlüsseln und Passwörtern.
Wichtig: Der Bericht beschreibt keinen dokumentierten Angriff „in freier Wildbahn“. Stattdessen richtet er sich klar an Entwickler, die Rohdaten aus Agenten-Trajektorien offen teilen oder übertragen, ohne Reasoning-Blöcke konsequent zu entfernen.
Was genau war die API-Sicherheitslücke KI-Reasoning?
Im Kern geht es um die Art, wie Anbieter das interne Denken zwischen aufeinanderfolgenden API-Aufrufen speichern und weiterreichen. In den untersuchten Systemen existieren verschlüsselte oder „opaque“ Reasoning-Objekte, die den Modellzustand über mehrere Schritte hinweg erhalten sollen. Die Verschlüsselung selbst wurde nach Darstellung der Forschenden nicht gebrochen.
Der entscheidende Punkt: Wenn ein Anbieter ein solches Reasoning-Objekt aus einer Session übernimmt und in einer anderen Verarbeitung akzeptiert, kann der Block unter Umständen replaybar sein. In Tests konnten die Forschenden sogar Situationen erzeugen, in denen ein schwächeres, aber kompatibles Modell aus derselben Anbieterfamilie die übertragenen Denkanteile wiedergeben konnte.
Damit wird aus einem Schutzmechanismus gegen direkte Offenlegung eine neue Angriffsfläche: Nicht die Kryptografie wird geknackt, sondern die Logik/Handhabung „intakter“ Blöcke beim Wiederverwenden.
Vier zentrale Missbrauchswege aus der Forschung
Die Arbeitsgruppe hinter der Studie „Stealing Reasoning Traces from Proprietary LLM APIs“ beschreibt mehrere Wege, wie sich aus solchen Reasoning-Spuren Sicherheits- und Datenschutzprobleme ableiten lassen. Dazu gehören unter anderem:
- Modell-Distillation: Propritäres Reasoning kann in einer Form gewonnen werden, die sich zur Systematisierung oder zum Nachbilden von Fähigkeiten nutzen lässt.
- Private Daten anderer Nutzer: Wenn Spuren aus veröffentlichten Trajektorien zurückgewonnen werden können, geraten Inhalte in den Fokus, die nicht für Dritte gedacht waren.
- „Harmful“-Inhalte hinter Schutzantworten: Selbst wenn ein Modell eine sichere sichtbare Antwort liefert, könnte der tatsächlich zugrunde liegende Denkanteil schwerer zu verbergen sein.
- Prompt-Injection in undurchsichtigen Blöcken: Eine schädliche Anweisung lässt sich in den „opaque“ Reasoning-Bereich packen. Der Empfänger muss sie nicht in sichtbar formatiertem Text erhalten, damit die Wirkung eintritt.
Wie groß war das Problem in den Messdaten?
Um die Tragweite zu prüfen, betrachteten die Forschenden 6.708 öffentliche Agent-Trajektorien. Dabei konnten sie insgesamt 315.320 „thinking blocks“ dekodieren. Nach dem Ausschluss von Benchmark-Quellen identifizierten sie 704 unterschiedliche „Privacy Artifacts“ aus echten Nutzersitzungen.
Diese Zuordnung umfasst mehrere Kategorien sensibler Informationen, darunter:
- 62 API-Keys
- 33 Passwörter
- 24 Access Tokens
- 7 private Keys
Ein besonders beunruhigender Befund: 64 der zurückgewonnenen Artefakte waren ausschließlich im versteckten Reasoning enthalten und tauchten nicht im sichtbaren Trace auf. Das bedeutet, dass ein scheinbar „bereinigtes“ Log (nur mit dem lesbaren Gespräch) dennoch in einem unsichtbaren Block Daten enthalten kann, die später rekonstruiert werden.
Welche Voraussetzungen brauchte ein erfolgreicher Angriff?
Die Studie betont, dass der beobachtete Cross-User-Ansatz nicht automatisch jedem Angriffsszenario entspricht. Für die Übertragung über Nutzergrenzen hinweg war typischerweise nötig, dass Angreifer ein geeignetes verschlüsseltes Reasoning-Objekt erhalten. Als Quelle nennt der Bericht etwa Reasoning-Blöcke, die bereits in veröffentlichten Agent-Logs auftauchen.
Zusätzlich braucht es API-Zugriff zu einem kompatiblen Modell innerhalb derselben Anbieterfamilie. Erst die Kombination aus „replaybarem“ Denkblock und passender Modellkompatibilität ermöglicht die in der Studie beschriebenen Extraktionsversuche.
Nach der Darstellung der Forschenden liefert der Angriff zudem keinen beliebigen Zugriff auf private Chats. Er zielt vielmehr darauf, verborgene Inhalte aus dem Reasoning-Teil zu gewinnen, sofern die Voraussetzungen erfüllt sind.
Welche Tests zeigen Übertragbarkeit auf Modelle?
Die Forschenden fanden während der Untersuchung Hinweise auf Portabilität solcher Reasoning-Objekte über Sessions, Nutzer und sogar Modellvarianten hinweg. Dabei setzten sie einen Ansatz ein, den die Autoren als „fuzzy decoder“ bezeichnen: Ein schwächeres, aber kompatibles Modell wurde so angeregt, Denkspuren zu transkribieren, die ein stärkeres Modell zuvor erzeugt hatte.
Als Beispiele werden in der Studie Zuordnungen genannt, etwa dass bestimmte Claude-Traces über ein geeignetes Modell dekodiert werden konnten und dass für GPT- und Gemini-ähnliche Spuren passende Zielmodelle eingesetzt wurden. Entscheidend ist weniger die exakte Modellbezeichnung als das Muster: Wenn Reasoning-Blöcke nicht eng genug an Produzent/Modell gebunden sind oder beim Wechsel der Verarbeitung nicht strikt gefiltert werden, entsteht ein Replay-Pfad.
Prompt-Injection ohne sichtbare Anweisung
Neben dem Data-Extraktionsaspekt beschreiben die Forschenden einen Proof of Concept, der Prompt Injection „unsichtbar“ macht. Sie konstruierten einen opaque Reasoning-Block, der eine bösartige Anweisung enthielt, und spielten diesen Block später in eine offenbar unabhängige Aufgabe ein.
Das Empfangsmodell fügte danach eine attacker-direkte Aktion hinzu, ohne dass die injizierte Anweisung in sichtbar lesbaren Textbestandteilen auftauchte. Für Entwickler ist das ein Hinweis darauf, dass Schutzmechanismen allein auf „sichtbaren Prompts“ nicht ausreichen können, wenn verdeckte Parameter oder Reasoning-Felder ebenfalls in die Verarbeitung hineinwirken.
Was sagen Anbieter und Dokumentation inzwischen?
Die Forschenden gaben ihre Ergebnisse den betroffenen Modellanbietern weiter. Im Bericht werden dabei auch Schritte erwähnt, die die Reproduzierbarkeit der beschriebenen Angriffe beeinflusst haben: Laut Autoren funktionieren die demonstrierten Angriffe nach Mitigations nicht mehr. Zudem stützt sich die Kernaussage zur aktuellen Lage auf die eigene Reproduzierbarkeit ab; eine öffentliche Bestätigung durch alle drei Anbieter wird in der Quelle nicht erwähnt.
Der Bericht weist auch darauf hin, dass sich die Handhabung in der Dokumentation geändert hat. Als Beispiele werden unterschiedliche Grundsätze genannt: Bei einer Plattform könne es weiterhin als Praxis gelten, verschlüsselte Reasoning-Items bei manuell verwaltetem stateless History-Replay zu replayen. Bei einer anderen Plattform soll die Backend-Verarbeitung die „Thought Compatibility“ steuern, wenn in einer Sitzung Modelle gewechselt werden.
Anthropic habe laut Bericht mittlerweile erklärt, dass „thinking blocks“ an das Modell gebunden seien, das sie produziert hat, und beim Wechsel zu entfernen seien. Damit wird der entscheidende Drehpunkt deutlich: Je stärker Reasoning-Blöcke an ein bestimmtes Modellkontext-Setup gebunden oder beim Wechsel konsequent entfernt werden, desto kleiner wird die Replay-Fläche.
Empfehlungen für Entwickler: Logs bereinigen, Blöcke entfernen
Da die Schwachstelle an das Teilen oder Veröffentlichen von Rohdaten aus Agenten-Trajektorien gekoppelt ist, lautet die praktische Leitlinie: Reasoning-Blöcke konsequent aus gemeinsamen Spuren entfernen. Die Forschenden raten außerdem dazu, „opaque“ Reasoning-Felder nicht in geteilten Logs zu belassen.
Auch wenn die sichtbaren Inhalte bereits „sanitized“ sind, kann das versteckte Denkmaterial weiterhin sensitive Informationen enthalten. Der Bericht macht damit deutlich, dass Datenschutzmaßnahmen nicht nur auf den lesbaren Textbestandteil begrenzt werden dürfen.
Ein weiterer Punkt: Die Autoren empfehlen, raw API-Transkripte nicht ungeprüft zu committen oder öffentlich zugänglich zu machen, selbst wenn die offensichtlichen Inhalte bereinigt wurden.
Einordnung: Grenzen der Studie und offene Fragen
Die Studie enthält zugleich wichtige Einschränkungen. Die Autoren geben an, dass ihnen kein „Ground Truth“-Klartext für das proprietäre Reasoning vorliegt. Dadurch können sie nicht garantieren, dass jede rekonstruierte Spur eine exakte Kopie ist.
Für ihre Prüfungen nutzen sie daher Plausibilitätsansätze wie Reasoning-Token-Zählungen und qualitative Vergleiche. Der Bericht beschreibt außerdem, dass es bereits viele Hunderttausende Reasoning-Blöcke in öffentlichen Repositories gebe, aber nicht im Detail geklärt wird, ob bereits veröffentlichte Blöcke auch nach späteren Änderungen weiterhin decodierbar bleiben. Ebenso bleibt offen, ob die Angriffe unter aktuellen Bedingungen exakt so funktionieren wie in den ursprünglichen Tests.
Fazit: Kleine Handhabungsfehler, große Datenschutzwirkung
Die Untersuchung zur API-Sicherheitslücke KI-Reasoning zeigt eindrücklich, wie stark moderne KI-Systeme davon abhängen, dass verschlüsselte interne Zustände nicht versehentlich über falsche Grenzen hinweg wiederverwendet werden. Die Verschlüsselung wurde nicht geknackt, aber „intakte“ Denkblöcke konnten in passenden Verarbeitungskontexten zur Extraktion sensibler Informationen beitragen.
Für Teams, die Agenten-Trajektorien veröffentlichen oder debuggen, ist die Konsequenz klar: Entfernen Sie Reasoning-Objekte und opaque Felder aus geteilten Logs, und vermeiden Sie das Ablegen von rohen API-Transkripten. Nur so verhindern Sie, dass scheinbar bereinigte Spuren im Hintergrund weiterhin privates Material transportieren.
Quelle: https://thehackernews.com/2026/08/openai-anthropic-google-api-flaw-let.html
