OpenAI stoppt Distillation-Kampagne, Reasoning-Klau lief über Azure weiter

OpenAI hat am 30. September 2026 in einem Blogbeitrag berichtet, eine koordinierte Kampagne zur sogenannten Adversarial Distillation gestoppt zu haben. Ziel war das verborgene Reasoning seiner Modelle, also die internen Denkschritte vor der eigentlichen Antwort. Einen Kern der Aktivität ordnet OpenAI Personen mit Verbindung zu Moonshot AI zu, dem Entwickler der Kimi-Modelle. Am selben Tag legte das Forscherteam, dessen Angriffstechnik dabei genutzt wurde, ein Update vor: Bei einer Prüfung am 13. September funktionierte die Extraktion über Microsoft Azure noch bei allen getesteten OpenAI-Modellen und bei Anthropic-Modellen bis Sonnet 5. Hintergrund zur Lücke: KI-Reasoning-Logs geknackt.

Relevant ist das für Unternehmen, die Reasoning-Modelle von OpenAI oder Anthropic per API nutzen, direkt oder über Cloud-Plattformen wie Microsoft Azure, AWS Bedrock oder OpenRouter, und dabei Konversationsverläufe samt verschlüsselter Reasoning-Blöcke speichern oder weitergeben. Reine Chat-Nutzer müssen nichts umstellen, einen Kunden-Patch gibt es nicht. Sinnvoll ist eine Bestandsaufnahme der Endpunkte und der gespeicherten Sitzungsprotokolle.

Was ist passiert?

Laut OpenAI begann die Aktivität am 1. Juli 2026 mit geringem Volumen. Am 24. und 25. Juli beobachtete das Unternehmen Spitzen von 16.000 Anfragen von mehr als 4.000 Nutzern mit einem typischen Extraktionsmuster. Weitere Untersuchungen ergaben ein Netzwerk von über 15.000 Konten mit verwandten Mustern, das bis zum 28. Juli vollständig gestoppt worden sei. Es handelt sich laut OpenAI um versuchte, nicht zwingend erfolgreiche Extraktionen. Ob alle Akteure auf einen Urheber zurückgehen, ist laut OpenAI unklar.

Technisch nutzten die Angreifer eine Schwäche, die ein Team um Alexander Panfilov und Joachim Schaeffer im August auf arXiv beschrieben hat. Anbieter speichern das Reasoning nicht serverseitig, sondern geben es als verschlüsselten Block an den Client zurück, der ihn bei der nächsten Anfrage wieder mitschickt. Diese Blöcke waren laut Paper mit gemeinsamen Schlüsseln verschlüsselt und damit zwischen Sitzungen, Nutzern und Modellen eines Anbieters austauschbar. Ein schwächeres, günstigeres Modell derselben Familie lässt sich so als Entschlüsselungsorakel einsetzen und gibt die Denkschritte des stärkeren Modells wörtlich im Klartext aus.

OpenAI hat nach eigenen Angaben die betrügerischen Konten gesperrt, die Registrierung verschärft, den Weg zur Wiederverwendung fremder verschlüsselter Reasoning-Blöcke geschlossen und prüft gestreamte Ausgaben, die Reasoning preisgeben könnten. Bei Partnern gehostete Modelle bräuchten denselben Schutz, die Arbeit sei nicht abgeschlossen.

Für wen ist das relevant?

Das Forscher-Update prüfte die direkten Schnittstellen von OpenAI und Anthropic sowie AWS Bedrock, Microsoft Azure und OpenRouter. Die zentralen Befunde:

• Der Replay-Angriff mit verschlüsselten Blöcken war am 13. September auf den direkten APIs von OpenAI und Anthropic blockiert, auf Azure aber bei jedem getesteten OpenAI-Modell einschließlich GPT-6 Astra und bei Anthropic-Modellen bis Sonnet 5 weiter möglich.
• Ein zweiter Weg, den der Entwickler Can Bölük öffentlich gezeigt hatte, lässt das Modell seine Überlegungen in ein sichtbares Notizblock-Werkzeug schreiben. Er funktionierte laut Update bei allen OpenAI-Modellen sowie bei Opus 4.8 und Sonnet 5. Nur Opus 5, Fable 5 und Fable 5.1 gaben ihr Reasoning nicht preis.
• Laut der von THE DECODER zitierten Zeitleiste der Forscher führte OpenAI erst am 27. September Schutzmaßnahmen auf dem Azure-Endpunkt ein, bei Anthropic war die Extraktion auf Azure ab dem 28. September nicht mehr reproduzierbar.

Für Unternehmenskunden zählt vor allem die Vertraulichkeit eigener Daten. Das ursprüngliche Paper hat 315.320 verschlüsselte Reasoning-Blöcke aus öffentlichen Repositories entschlüsselt und darin 367 personenbezogene Datenfunde und 182 Zugangsdaten gefunden. Verschlüsselt heißt in diesem Fall also nicht vertraulich gegenüber Dritten, sobald ein Block das eigene Haus verlässt.

Wie kritisch ist das?

Für die meisten Unternehmen ist das ein Punkt für das nächste Wartungsfenster, kein Notfall. Die Extraktion zielt vor allem auf das geistige Eigentum der Anbieter. Ein direktes Risiko für Kunden entsteht dort, wo Reasoning-Blöcke aus eigenen Sitzungen in fremde Hände gelangen, etwa über öffentlich geteilte Agenten-Logs, Support-Tickets oder Repositories. Dann können darin enthaltene Prompt-Inhalte, personenbezogene Daten oder Zugangsdaten auslesbar sein. Das Paper beschreibt zudem versteckte Prompt Injection über manipulierte Blöcke in geteilten Agentenläufen. Ob Azure inzwischen für alle Modelle nachgezogen hat, ist öffentlich nicht vollständig belegt; die Forscher nennen nur die Daten 27. und 28. September.

Was sollten Admins jetzt tun?

• Inventar erstellen: welche Anwendungen OpenAI- oder Anthropic-Reasoning-Modelle nutzen, über welchen Endpunkt (direkte API, Azure, Bedrock, Vertex, OpenRouter) und in welcher Modellversion.
• Prüfen, wo Konversationsverläufe mit verschlüsselten Reasoning-Blöcken gespeichert werden, und diese Daten wie Klartext-Prompts einstufen: Zugriff beschränken, Aufbewahrung begrenzen, nicht in Tickets, Wikis oder Repositories kopieren.
• Öffentliche und interne Repositories auf eingecheckte Agenten-Logs und API-Keys scannen und gefundene Schlüssel rotieren.
• API-Keys pro Anwendung trennen, mit Budget- und Ratenlimits versehen und Nutzung auf Ausreißer überwachen.
• Bei Nutzung über Cloud-Plattformen klären, ob die Schutzmaßnahmen der Modellhersteller dort identisch umgesetzt sind.
• Nutzungsbedingungen von Modellanbieter und Cloud-Plattform zu Missbrauch, Kontosperrung und Weiterverwendung von Modellausgaben prüfen und in die interne KI-Richtlinie übernehmen.

Einordnung für Unternehmen

Dasselbe Modell kann je nach ausliefernder Plattform unterschiedlich gut geschützt sein; Schutzmaßnahmen des Herstellers kommen nicht zwingend zeitgleich in jeder Cloud an. Für kleine und mittlere Unternehmen gilt pragmatisch: Verschlüsselte Reasoning-Blöcke sind keine Ablage für Geheimnisse. Ein zentrales Gateway mit eigenen Schlüsseln, Protokollierung und Limits macht die Nutzung nachvollziehbar und begrenzt den Schaden, falls ein Schlüssel abhandenkommt.

Passende Anleitungen auf S-EDV

• LiteLLM als LLM-Gateway mit Docker: zentrale Schlüsselverwaltung, Budgets und Protokollierung für mehrere Modellanbieter.
• Gitleaks als Secret-Scanner mit Docker: Repositories auf versehentlich eingecheckte API-Keys prüfen.

Quellen

• OpenAI: Disrupting a coordinated model-distillation campaign (30. September 2026)
• Schaeffer, Panfilov u. a.: Update zur Reasoning-Extraktion über Cloud-Aggregatoren (PDF, September 2026)
• arXiv 2608.09867: Stealing Reasoning Traces from Proprietary LLM APIs
• THE DECODER: OpenAI wirft Kimi-Entwickler Moonshot AI vor, Denkprozesse abgegriffen zu haben
• The Hacker News: Bericht zur gestoppten Extraktionskampagne mit Moonshot-Bezug