OpenAI entdeckt koordinierte Extraktionsversuche
OpenAI hat eine koordinierte Kampagne gegen die geschützten Denkprozesse seiner Modelle aufgedeckt. Solche internen Verarbeitungsprotokolle enthalten Zwischenschritte, die in der sichtbaren Antwort nicht erscheinen und Rückschlüsse auf die Fähigkeiten eines Modells ermöglichen können.
Das Unternehmen ordnet die Aktivität als gegnerische Modelldestillation ein. Dabei werden Ausgaben oder interne Prozesse eines Modells systematisch abgegriffen, um ein anderes Modell zu trainieren, nachzubauen oder zu verbessern.
Nach Angaben von OpenAI begann die beobachtete Aktivität am 1. Juli 2026 zunächst mit geringem Volumen. Am 24. und 25. Juli stieg die Zahl auf 16.000 versuchte Extraktionsanfragen von mehr als 4.000 Nutzern. Die Untersuchung führte schließlich zu einem Cluster von über 15.000 Konten mit ähnlichen Prompt-Mustern.
| Zeitpunkt | Beobachtung |
|---|---|
| 1. Juli 2026 | Beginn der Aktivitäten mit geringem Volumen |
| 24. und 25. Juli 2026 | 16.000 versuchte Extraktionsanfragen von mehr als 4.000 Nutzern |
| Bis 28. Juli 2026 | Kampagne laut OpenAI vollständig unterbunden |
| 30. September 2026 | Veröffentlichung des Berichts |
Angriff lief über manipulierte Modellanfragen
Die Angreifer überwanden laut OpenAI weder Verschlüsselung noch Datenbanken. Sie erhielten auch keinen direkten Zugriff auf gespeicherte Unterhaltungen. Stattdessen manipulierten sie Modellinteraktionen über die Grenzen einzelner Konversationen hinweg.
Bei einer Methode wurde verschlüsseltes Reasoning aus einem Chat kopiert. Anschließend sollte das Modell den Inhalt in einer anderen Konversation entschlüsseln und offenlegen. Damit wurde nicht die klassische Infrastruktur angegriffen, sondern das Verhalten des Modells selbst als Extraktionswerkzeug genutzt.
Entscheidend ist nicht nur, welche Daten ein Modell sichtbar ausgibt. Auch übertragbare Zwischenzustände und das Zusammenspiel mehrerer Konversationen können einen Angriffspfad bilden.
Unabhängige Sicherheitsforscher hatten verwandte Schwachstellen bei modellübergreifenden Interaktionen und der Verdichtung längerer Konversationen gemeldet. OpenAI bestätigte diese Angriffspfade und bezog die Erkenntnisse in seine Gegenmaßnahmen ein. Der Fall ergänzt damit bekannte Risiken rund um Prompt Injection bei OpenAI-Modellen.
Kernaktivität wird Moonshot AI zugeschrieben
OpenAI führt einen zentralen Teil der Kampagne auf Personen aus dem Umfeld von Moonshot AI zurück. Das chinesische Unternehmen entwickelt die Kimi-Modelle und verfolgt mit ihnen ein schnell wachsendes kommerzielles Geschäft, das auch beim Umsatzziel von Moonshot AI sichtbar wird.
Die Zuordnung gilt ausdrücklich nicht für sämtliche beobachteten Konten. Es bleibt offen, ob weitere Akteure hinter Teilen des Clusters standen. Ebenso ist nicht bekannt, wie viele der 16.000 Versuche tatsächlich geschützte Informationen lieferten.
Kontosperren, Filter und geschlossene Replay-Lücke
OpenAI sperrte oder beschränkte beteiligte Konten und verschärfte die Kontrollen bei Anmeldung und Infrastruktur. Zusätzlich wurden Filter eingeführt, die gestreamte Ausgaben erkennen und zurückhalten sollen, wenn diese geschützte Denkprozesse enthalten könnten.
Außerdem schloss das Unternehmen eine Replay-Schwachstelle. Über diesen Angriffspfad ließ sich bereits vorhandenes verschlüsseltes Reasoning erneut einspielen, um dessen Inhalt wiederherzustellen. Erkenntnisse zur Kampagne wurden über das Frontier Model Forum und weitere Kanäle mit anderen Anbietern und staatlichen Stellen geteilt.
Was der Fall für Unternehmen bedeutet
Für Unternehmen im DACH-Raum zeigt der Vorfall eine wenig sichtbare Risikoklasse. Neben Eingabedaten und sichtbaren Antworten müssen auch modellinterne Zwischenzustände, Chat-Grenzen und übertragbare Artefakte in die Sicherheitsbewertung einbezogen werden.
Wer sensible Daten über Cloud-Schnittstellen verarbeitet, bleibt von den Schutzmechanismen des jeweiligen Anbieters abhängig. Neue Filter, Sperren und Erkennungsregeln können die Sicherheit erhöhen, zugleich aber das Verhalten einer API verändern. Anwendungen, die auf reproduzierbare Antworten angewiesen sind, sollten solche Änderungen technisch abfangen und protokollieren.
Der Vorfall verdeutlicht zudem das Wettrüsten um proprietäres Modellwissen. Anbieter schützen ihre Modelle mit immer mehr Kontrollen, während andere Akteure versuchen, Fähigkeiten mit geringerem Trainingsaufwand zu rekonstruieren. Dadurch können Anbieterabhängigkeit und schwer planbare Änderungen an Cloud-Diensten zunehmen.
Open-Source-Modelle und Self-Hosting bieten eine Alternative, wenn Kontrolle über Modellgewichte, Datenflüsse und Ausführungsumgebung entscheidend ist. Sie beseitigen Sicherheitsrisiken nicht, verlagern Schutz, Betrieb und Aktualisierung aber in den eigenen Verantwortungsbereich. Für Unternehmen ist das eine Abwägung zwischen internem Aufwand und der Abhängigkeit von laufend veränderten Schutzmechanismen proprietärer Plattformen.