OpenAI opisało próbę pozyskiwania chronionego rozumowania swoich modeli. Raport z 30 września dotyczy kampanii obserwowanej w lipcu. Firma mówi o manipulowaniu interakcjami z modelem, a nie włamaniu do bazy rozmów.
Przy ocenie tej sprawy warto oddzielić mechanizm ataku, skalę prób i przypisanie sprawców. Są to trzy różne pytania, wymagające innych dowodów. Badanie akademickie może potwierdzać istnienie podatności, nie ustalając zarazem, kto wykorzystał ją w konkretnej kampanii.
Najważniejsze ustalenia i granice dowodów
| Ustalenie | Źródło i zakres |
|---|---|
| Aktywność od 1 lipca; skoki 24–25 lipca | Chronologia podana przez OpenAI |
| 16 000 żądań, ponad 4000 użytkowników w skokach aktywności | Próby ekstrakcji, nie liczba udanych odczytów |
| Ponad 15 000 użytkowników w powiązanej grupie aktywności | Szersza analiza firmy; odrębna miara |
| Rdzeń kampanii powiązany z osobami związanymi z Moonshot AI | Atrybucja OpenAI, nie niezależny werdykt |
| 315 320 bloków analizowanych przez badaczy | Osobny zbiór z publicznych repozytoriów, nie dane tej kampanii |
Liczby kampanii pochodzą z komunikatu OpenAI; autor zaznacza, że żądania nie musiały kończyć się skuteczną ekstrakcją. Zestawienia nie należy czytać jako bilansu wykradzionych rozmów.
Dlaczego aplikacja przenosi ukryte rozumowanie
Odpowiedź widoczna w oknie rozmowy nie wyczerpuje stanu, który aplikacja może wymieniać z usługą modelu. Dokumentacja Responses API, sprawdzona 4 października, opisuje przekazywanie zaszyfrowanych elementów rozumowania między wywołaniami. W trybie bezstanowym, przy store: false lub Zero Data Retention, elementy odpowiedzi mogą zawierać encrypted_content. Służy to zachowaniu ciągłości bez przechowywania odpowiedzi po stronie usługi.
Ta konstrukcja wyjaśnia, skąd blok rozumowania może znaleźć się w dzienniku klienta. Nie oznacza, że jest przeznaczony do odczytu przez człowieka. Trzeba również rozróżniać brak zapisu po stronie usługi i lokalne logowanie całej odpowiedzi przez aplikację. Pierwsze ustawienie nie opisuje automatycznie drugiego.
Praktyczny przykład: aplikacja zapisuje wynik wywołania w pliku diagnostycznym, a później ktoś dołącza ten plik do publicznego zgłoszenia błędu. Pytanie o poufność dotyczy wtedy całego eksportu, a nie wyłącznie fragmentu tekstu wyświetlonego użytkownikowi. To modelowy scenariusz do analizy projektu, nie opis dodatkowego incydentu.
Co pokazuje niezależny preprint
„Stealing Reasoning Traces from Proprietary LLM APIs” autorstwa Alexandra Panfilova i współautorów opublikowano 10 sierpnia. Autorzy opisują przekazywanie zaszyfrowanego śladu do słabszego modelu tego samego dostawcy, który ujawnia jego treść. Deklarują demonstracje dotyczące Anthropic, OpenAI i Google oraz odpowiedzialne zgłoszenie ustaleń.
W osobnym zbiorze publicznych repozytoriów przeanalizowali 315 320 bloków i zgłosili odzyskanie 367 artefaktów zawierających dane identyfikujące osoby oraz 182 poświadczeń. Są to kategorie i liczniki badaczy. Nie odpowiadają liczbie ofiar lipcowej kampanii ani liczbie przejętych kont.
Preprint opisuje także możliwość ujawnienia informacji nieobecnych w końcowej odpowiedzi oraz wstrzykiwania instrukcji w ukrytych blokach. To badanie autorów, nie własny test AIoAI.pl ani wynik reprodukcji całej kampanii. Jego abstrakt nie pozwala ustalić aktualnej podatności każdej wersji modelu lub każdego partnera.
Zestawienie publikacji ma zatem sens na poziomie klasy problemu: pokazuje, dlaczego przenoszony stan wymaga ochrony również na granicach aplikacji. Nie daje podstaw do połączenia obu zbiorów liczbowych w jedną statystykę.
Przypisanie sprawców wymaga osobnej oceny
OpenAI przypisuje rdzeń aktywności osobom związanym z Moonshot AI, twórcą Kimi, zaznaczając niepewność co do wszystkich operatorów. W sprawdzonych 4 października źródłach nie ustaliliśmy niezależnego potwierdzenia tego przypisania ani zweryfikowanej oficjalnej odpowiedzi Moonshot.
Wniosek „badacze pokazali podobny atak, więc potwierdzili sprawcę” byłby błędny. Analiza techniczna i identyfikacja operatora nie są wymienne. Do rozstrzygnięcia atrybucji potrzebny byłby odrębny materiał, wiążący działania z konkretnymi osobami lub organizacją. Sam podobny prompt tego nie zapewnia.
Destylacja: metoda uczenia i spór o pozyskiwanie danych
Destylacja wiedzy opisuje relację, w której model uczący się wykorzystuje informacje pochodzące od modelu nauczyciela. Przy omawianiu incydentu sama nazwa metody nie wystarcza do ustalenia, czy dane pozyskano za zgodą dostawcy, jakie były warunki użycia oraz co faktycznie pobrano.
AIoAI.pl opisywało już wcześniejsze zarzuty Anthropic dotyczące destylacji. Nowy materiał należy oceniać na podstawie jego własnych dowodów. Nie wolno przenosić skali wcześniejszego zdarzenia, listy podmiotów ani wniosków na kampanię przedstawioną przez OpenAI.
Najbardziej użyteczna jest tu precyzja języka. „Próba ekstrakcji rozumowania” opisuje cel operacji. „Skuteczne odczytanie bloku” opisuje rezultat. „Wytrenowanie konkurencyjnego modelu” wymaga kolejnego dowodu. Przeskakiwanie między tymi określeniami zaciera najważniejsze ograniczenia raportu.
Co sprawdzić we własnej aplikacji
OpenAI opisuje blokowanie kont, dodatkowe kontrole chronionego stanu i filtrowanie potencjalnych ujawnień w strumieniu odpowiedzi. Informuje też o trwających pracach u partnerów. Komunikat nie jest certyfikatem bezpieczeństwa każdej integracji.
Dla zespołu tworzącego aplikację sensowne pytania kontrolne dotyczą przepływu danych: które pola odpowiedzi trafiają do logów, kto może je eksportować i co pozostaje w publicznym zgłoszeniu błędu. Warto umieć pokazać te granice na jednym konkretnym przebiegu, zamiast opierać ocenę na nazwie dostawcy lub ogólnym zapewnieniu o szyfrowaniu.
Podobnie jak w przypadku pamięci i uprawnień agenta dots, trzeba odróżniać stan systemu od tego, co użytkownik widzi w interfejsie. To wskazówka do przeglądu konfiguracji, nie twierdzenie, że dots uczestniczył w opisywanej kampanii.
Raport zmienia przede wszystkim sposób zadawania pytań o ochronę rozumowania. Liczy się nie tylko końcowa odpowiedź, lecz również droga przenoszonego stanu. Otwarte pozostają niezależna ocena atrybucji i zakres skuteczności zabezpieczeń w poszczególnych integracjach.
Częste pytania
Jakie są główne ustalenia dotyczące kampanii ekstrakcji rozumowania opisanej przez OpenAI?
OpenAI wskazuje na aktywność od 1 lipca, z szczytem 24-25 lipca, obejmującą 16 000 żądań od ponad 4000 użytkowników. Ważne jest, że raport nie sugeruje, że wszystkie żądania zakończyły się skuteczną ekstrakcją.
Dlaczego aplikacja może przenosić ukryte rozumowanie między wywołaniami?
Aplikacja może przekazywać zaszyfrowane elementy rozumowania, co jest opisane w dokumentacji Responses API. W trybie bezstanowym, przy ustawieniu store: false, odpowiedzi mogą zawierać encrypted_content, co pozwala na zachowanie ciągłości bez przechowywania danych.
Co pokazuje badanie dotyczące ekstrakcji rozumowania opublikowane przez Alexandra Panfilova?
Badanie opisuje, jak zaszyfrowany ślad może być przekazywany do słabszego modelu, ujawniając jego treść. Autorzy przeanalizowali 315 320 bloków, odzyskując dane identyfikujące osoby oraz poświadczenia, ale nie są one związane z lipcową kampanią.
Jakie pytania kontrolne powinny zadać zespoły tworzące aplikacje w kontekście ochrony danych?
Zespoły powinny pytać, które pola odpowiedzi trafiają do logów, kto ma dostęp do eksportu danych oraz co pozostaje w publicznych zgłoszeniach błędów. Ważne jest, aby zrozumieć granice ochrony danych na konkretnym przykładzie.
Jak OpenAI ustala przypisanie sprawców do kampanii ekstrakcji rozumowania?
OpenAI przypisuje rdzeń aktywności osobom związanym z Moonshot AI, ale podkreśla brak niezależnego potwierdzenia tego przypisania. Wymagana jest osobna ocena, aby powiązać działania z konkretnymi osobami lub organizacjami.
