Wprowadzenie do problemu / definicja
Badacze ujawnili istotną słabość bezpieczeństwa w interfejsach API modeli rozumujących, która mogła prowadzić do odczytu ukrytych śladów wnioskowania oraz danych wrażliwych. Problem dotyczył niejawnych artefaktów przechowujących stan „myślenia” modelu pomiędzy kolejnymi wywołaniami API, które miały wspierać ciągłość pracy bez ujawniania wewnętrznego procesu użytkownikowi.
W praktyce takie obiekty mogły zostać przechwycone, zachowane i ponownie użyte w innym kontekście. To otwierało drogę do odzyskiwania informacji, które nie były widoczne w standardowej odpowiedzi tekstowej, ale nadal znajdowały się w technicznych elementach sesji lub logów.
W skrócie
Opisana podatność dotyczyła ukrytych, podpisanych lub zaszyfrowanych bloków rozumowania zwracanych przez wybrane API modeli AI. Badacze wykazali, że artefakty te mogły być przenoszone między sesjami, użytkownikami, a w części przypadków również między modelami z tej samej rodziny.
- możliwe było odtwarzanie wewnętrznych śladów rozumowania modeli,
- z publicznych lub współdzielonych logów dało się odzyskiwać sekrety,
- wśród ujawnionych danych mogły znaleźć się klucze API, hasła, tokeny dostępu i klucze prywatne,
- problem pokazał, że surowe logi agentów AI mogą stanowić nośnik poufnych informacji.
Według opisu badań po wdrożeniu działań naprawczych główne techniki ekstrakcji przestały działać, jednak sama klasa ryzyka pozostaje ważną lekcją dla organizacji budujących rozwiązania oparte na agentach i modelach rozumujących.
Kontekst / historia
Nowoczesne platformy AI coraz częściej korzystają z mechanizmów zachowywania stanu pomiędzy żądaniami. Ma to szczególne znaczenie w architekturach bezstanowych oraz w aplikacjach, które samodzielnie zarządzają historią rozmowy, zadaniami agenta i kontekstem wieloetapowych operacji.
Aby nie ujawniać użytkownikowi pełnego procesu rozumowania, dostawcy wdrażają techniczne obiekty przechowujące ten stan w tle. Założenie jest proste: model może kontynuować pracę na bazie poprzedniego kroku, a klient widzi wyłącznie finalną, kontrolowaną odpowiedź. Problem pojawia się wtedy, gdy backend bezpiecznie przechowuje taki obiekt, ale jednocześnie akceptuje go ponownie bez wystarczającego ograniczenia kontekstu użycia.
Nowe ustalenia rozwinęły wcześniejsze obserwacje związane z możliwością odtwarzania takich bloków. Tym razem pokazano jednak bardziej praktyczny scenariusz nadużycia: wykorzystanie ukrytych artefaktów nie tylko do replayu, ale także do rekonstrukcji rozumowania i wydobywania poufnych informacji z logów pracy agentów AI.
Analiza techniczna
Kluczowe jest to, że atak nie wymagał złamania kryptografii ani pozyskania kluczy szyfrujących. Nadużycie polegało na ponownym przesłaniu nienaruszonego, niejawnego bloku rozumowania do systemu, który nadal ufał temu artefaktowi i przetwarzał go w nowym kontekście. W efekcie taki obiekt stawał się przenośnym nośnikiem logicznego stanu modelu.
Badacze opisali kilka istotnych wektorów ryzyka. Jeden z nich dotyczył ekstrakcji własności intelektualnej i śladów rozumowania modeli komercyjnych, co potencjalnie może wspierać ich destylację. Drugi obejmował odzyskiwanie prywatnych danych z logów innych użytkowników, jeśli takie logi zawierały surowe artefakty techniczne. Trzeci scenariusz pokazywał możliwość wydobycia niebezpiecznych treści ukrytych za pozornie bezpieczną odpowiedzią końcową. Czwarty dotyczył osadzania niewidocznych instrukcji, które mogły działać jak ukryty prompt injection.
Szczególnie interesujący był mechanizm wykorzystania słabszego modelu z tej samej rodziny jako swoistego „rozmytego dekodera”. Po otrzymaniu odpowiedniego polecenia taki model próbował odtworzyć sens ukrytego rozumowania wygenerowanego wcześniej przez mocniejszy model. To pokazuje, że zagrożenie nie ogranicza się wyłącznie do pojedynczej sesji, ale może obejmować szerszy ekosystem zgodnych modeli i narzędzi.
W praktyce analiza dużych zbiorów publicznych trajektorii agentów miała prowadzić do dekodowania ogromnej liczby bloków myślenia. Wśród odzyskiwanych danych znajdowały się informacje uwierzytelniające oraz materiał kryptograficzny, przy czym część z tych sekretów występowała wyłącznie w ukrytym rozumowaniu, a nie w jawnej treści logu. To oznacza, że klasyczne oczyszczanie widocznego tekstu mogło nie wystarczać do zabezpieczenia danych.
Osobną kategorią zagrożenia była możliwość ukrycia złośliwej instrukcji wewnątrz niejawnego bloku. Gdy taki artefakt został później odtworzony w innym zadaniu, model mógł wykonać działanie zgodne z intencją atakującego, mimo że sama instrukcja nie pojawiała się w żadnym widocznym komunikacie. Taki wzorzec znacząco utrudnia wykrywanie incydentów i analizę ścieżki ataku.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem opisanej słabości jest możliwość wycieku danych wrażliwych z aplikacji korzystających z agentów AI i integracji API. Nawet jeśli organizacja usuwa poufne informacje z jawnej odpowiedzi modelu, sekrety mogły nadal pozostawać w niejawnych obiektach rozumowania, metadanych lub technicznych blokach sesji.
Ryzyko dotyczy przede wszystkim firm, które zapisują, eksportują, archiwizują albo publicznie udostępniają pełne logi interakcji z modelami. W środowiskach deweloperskich może to prowadzić do ujawnienia poświadczeń w repozytoriach kodu, systemach telemetrycznych, platformach testowych, pipeline’ach CI/CD czy narzędziach debugujących.
Z perspektywy bezpieczeństwa aplikacyjnego problem łączy kilka obszarów naraz:
- ochronę sekretów i danych wrażliwych,
- bezpieczeństwo łańcucha dostaw AI,
- integralność kontekstu modelu,
- odporność na prompt injection,
- kontrolę retencji i ekspozycji logów.
Dodatkowo możliwość przenoszenia ukrytych instrukcji zwiększa zagrożenie dla agentów wykonujących operacje na plikach, danych biznesowych, narzędziach administracyjnych i usługach zewnętrznych. W takim scenariuszu prompt injection nie musi już występować jako jawny tekst wejściowy — może zostać ukryty w artefakcie akceptowanym przez backend.
Rekomendacje
Organizacje korzystające z API modeli rozumujących powinny traktować wszelkie niejawne obiekty rozumowania jak dane wysokiego ryzyka. Nie należy publikować surowych logów agentów ani pełnych odpowiedzi API zawierających pola techniczne odpowiedzialne za przenoszenie stanu myślenia.
- usuwać z logów wszystkie ukryte artefakty rozumowania przed eksportem, udostępnieniem i archiwizacją,
- nie commitować pełnych odpowiedzi API do repozytoriów kodu, nawet jeśli widoczny tekst został oczyszczony,
- traktować logi agentów AI jako potencjalne nośniki sekretów i objąć je kontrolami DLP,
- ograniczać retencję surowych transkryptów oraz segmentować dostęp do takich danych,
- skanować historyczne logi i repozytoria pod kątem kluczy API, tokenów, haseł i kluczy prywatnych,
- sprawdzać, czy integracje nie przenoszą ukrytych obiektów między niepowiązanymi sesjami, zadaniami i użytkownikami,
- uwzględnić artefakty rozumowania w modelowaniu zagrożeń oraz procedurach reagowania na incydenty,
- testować odporność aplikacji na ukryte prompt injection i niewidoczne instrukcje osadzane w stanie modelu.
Dla zespołów bezpieczeństwa ważne jest również zrozumienie, jakie dokładnie pola techniczne zwraca konkretny dostawca API i które z nich mogą zawierać informacje wrażliwe. Ochrona takich systemów nie może ograniczać się wyłącznie do filtracji tekstu wejściowego i wyjściowego — musi obejmować także metadane, obiekty sesyjne i ukryty stan modelu.
Podsumowanie
Ujawniona słabość pokazała, że mechanizmy przenoszenia ukrytego rozumowania w API modeli AI mogą tworzyć nową klasę zagrożeń dla bezpieczeństwa danych i integralności pracy agentów. Problem nie wynikał z przełamania szyfrowania, lecz z zaufania backendu do poprawnych, ale niejawnych artefaktów dostarczanych w kolejnych wywołaniach.
Najważniejszy wniosek dla organizacji jest jednoznaczny: logi, metadane i techniczne artefakty generowane przez systemy AI należy traktować jak zasoby wrażliwe. Nawet jeśli widoczna treść odpowiedzi wydaje się bezpieczna, ukryty stan modelu może nadal zawierać sekrety lub niejawne instrukcje zdolne do uruchomienia niepożądanych działań.