Wpadki bezpieczeństwa narzędzi AI nie dotyczą jednej firmy czy jednego produktu – to symptom większego problemu: wdrażamy sztuczną inteligencję szybciej niż dojrzewają zasady, kontrola i odpowiedzialność. W tym artykule przyglądamy się głośnym przypadkom (m.in. Amazon Q Developer, Microsoft Copilot czy ChatGPT) i pokazujemy, jak takie incydenty powstają, co je napędza oraz jakie lekcje powinniśmy z nich wyciągnąć jako branża. Jako specjaliści QA – musimy być szczególnie uczuleni w tym temacie.
1.84.0 Amazon Q Developer
W lipcu 2025 roku doszło do jednego z najbardziej niepokojących incydentów związanych z bezpieczeństwem narzędzi AI dla developerów. Tym razem problem nie polegał na tym, że użytkownik wkleił do czatu niebezpieczne polecenie. Najbardziej alarmujące było to, skąd w ogóle wziął się złośliwy prompt: z oficjalnego wydania narzędzia.
Atakujący wykorzystał klasyczny schemat supply chain, ale w nowoczesnym wydaniu. Zamiast podmiany kodu w bibliotece czy paczce NPM, wstrzyknięto złośliwą instrukcję (prompt), która miała sterować zachowaniem asystenta kodowania. To pokazuje zmianę paradygmatu: w ekosystemie narzędzi AI prompty zaczynają działać jak nowy rodzaj „logiki wykonywalnej”.
Jak to wyglądało?
-
13 lipca 2025 haker umieścił spreparowaną treść w pull requeście na GitHubie.
-
17 lipca Amazon opublikował wersję 1.84.0 Amazon Q Developer (rozszerzenie do VS Code), w której znalazł się ten złośliwy prompt.
-
Instrukcje miały wymusić na asystencie destrukcyjne działania: usuwanie plików systemowych, kasowanie zasobów w chmurze i przywrócenie środowiska praktycznie do ustawień fabrycznych.
-
Rozszerzenie było bardzo popularne – pobrane przez prawie milion użytkowników – co pokazuje potencjalną skalę takiego ataku.
-
Incydent został wykryty i 24 lipca wydano poprawioną wersję 1.85.0, usuwając problematyczne elementy.
Dlaczego ten przypadek jest tak groźny?
To nie był standardowy prompt injection wykonywany przez użytkownika w rozmowie. To był atak, w którym prompt został osadzony w samym narzędziu, a więc trafił do użytkowników dokładnie tak samo jak kod – jako element zaufanego release’u. W efekcie można mówić o supply chain prompt injection: złośliwa instrukcja nie pochodzi od użytkownika, lecz z repozytorium i procesu dystrybucji.
To ważne ostrzeżenie, bo narzędzia typu Amazon Q Developer coraz częściej pracują w trybie agentowym: mają dostęp do repozytoriów, uruchamiają polecenia, integrują się z narzędziami developerskimi, a w niektórych scenariuszach także z chmurą. W takim układzie „zwykły prompt” może stać się dźwignią do działań, które są realnie destrukcyjne.
Amazon później komunikował, że instrukcja zawierała błąd składniowy, który uniemożliwił jej poprawne wykonanie. Nie zmienia to faktu, że sam incydent jest niezwykle cenny jako studium przypadku: złośliwe prompty mogą zostać dostarczone użytkownikom poprzez łańcuch dostaw, podobnie jak złośliwy kod.
Wniosek
Jeśli narzędzia AI mają rosnące uprawnienia i wykonują akcje „w świecie” (kod, repo, CLI, chmura), to prompty muszą być traktowane jak potencjalnie niebezpieczne artefakty: wersjonowane, walidowane, testowane i objęte kontrolą bezpieczeństwa supply chain. Bo od tej pory problemem nie jest tylko „czy użytkownik podał zły prompt?”, ale również „czy narzędzie nie przyniosło go ze sobą”.
Echo Leak z MS Copilotem
EchoLeak był jednym z tych przypadków, które najlepiej pokazały, dlaczego narzędzia AI w ekosystemie biurowym mogą stać się nie tylko „asystentem”, ale również potencjalnym kanałem wycieku danych. Kluczowy problem nie dotyczył klasycznego phishingu czy złośliwego załącznika, tylko tego, że Copilot – działając w trybie RAG i korzystając z integracji firmowych (Outlook, Teams, SharePoint) – mógł zostać zmuszony do przetworzenia i „sklejenia” niebezpiecznego payloadu z wrażliwymi danymi organizacji.
Najbardziej niepokojące w tym scenariuszu było to, że ofiara nie musiała w nic klikać. Wystarczyło zadanie standardowego pytania biznesowego.
Mechanizm działania (EchoLeak) – krok po kroku
Atak był sprytnie zaprojektowany tak, aby wyglądał jak normalna komunikacja, a jednocześnie przemycał instrukcje dla modelu.
-
Atakujący wysyłał e-mail do organizacji
W treści maila znajdował się ukryty złośliwy prompt zapisany w Markdownie — często w formie tzw. reference-style links (odwołań, które nie wyglądały jak bezpośrednia instrukcja, ale przenosiły dodatkową semantykę). -
Użytkownik zadawał Copilotowi „normalne” pytanie
Np. „Podsumuj raport finansowy”, „Stwórz streszczenie korespondencji z klientem” albo „Wyciągnij kluczowe wnioski z dokumentów projektu”. -
RAG mieszał zewnętrzny payload z wewnętrznymi danymi
Mechanizm Retrieval-Augmented Generation pobierał kontekst z M365 (mail, dokumenty, Teams/SharePoint) i doklejał go do promptu modelu. W tym momencie złośliwy prompt stawał się częścią wejścia do LLM i zaczynał działać jak instrukcja. -
Dochodziło do exfiltracji danych „bocznym kanałem”
W niektórych wariantach dane mogły być ujawniane w generowanej odpowiedzi lub przekazywane przez elementy typu linki/odwołania do Teams/SharePoint, co w praktyce mogło umożliwiać przekazanie informacji do atakującego.
Sedno: AI stawała się nieintencjonalnym pośrednikiem w wycieku danych.
Dlaczego to było tak poważne?
Ten przypadek był wyjątkowo istotny, bo uderzał w fundament zaufania do Copilota w środowisku enterprise.
-
Brak konieczności kliknięcia
W klasycznych atakach phishingowych prawie zawsze występował element interakcji: kliknięcie, uruchomienie pliku, podanie danych. W EchoLeak tego brakowało – użytkownik robił dokładnie to, do czego Copilot był stworzony. -
Wykorzystanie domyślnych integracji
Atak żerował na tym, że Copilot był natywnie połączony z Outlookiem, SharePointem i innymi źródłami danych – i że konteksty o różnym poziomie zaufania mogły zostać połączone bez wystarczającej izolacji. -
Trudność wykrycia
Ponieważ cały proces wyglądał „normalnie” (mail + pytanie do Copilota), incydent mógł nie generować klasycznych alertów bezpieczeństwa. Payload był zaszyty w treści, a nie w pliku wykonywalnym.
Techniczny kontekst: LLM Scope Violation i obejście filtrów
EchoLeak był przykładem problemu klasy LLM Scope Violation – czyli naruszenia zakresu kontekstu i ujawnienia danych w sytuacji, w której model nie powinien był tego zrobić.
Istotne było to, że:
-
LLM nie rozróżniał danych i instrukcji w sposób tak jednoznaczny jak tradycyjne systemy,
-
treść maila mogła zostać potraktowana jako polecenie, a nie tylko materiał do streszczenia,
-
mimo obecności zabezpieczeń (np. mechanizmów w stylu Prompt Shields) atakujący potrafili obejść filtry, m.in. poprzez użycie konstrukcji Markdown (reference-style), które nie były skutecznie blokowane.
To była ważna lekcja: filtry prompt injection nie dawały gwarancji bezpieczeństwa, zwłaszcza gdy dane trafiały do modelu przez rozbudowany pipeline RAG.
Reakcja Microsoftu
Microsoft załatał lukę w czerwcu 2025, w ramach cyklu poprawek typu Patch Tuesday. Poprawka została wdrożona automatycznie, bez konieczności działań po stronie użytkowników.
Szersze implikacje
EchoLeak był mocnym sygnałem ostrzegawczym dla całej branży. Pokazał, że w narzędziach agentowych:
-
mechanizmy RAG łączą konteksty o różnym poziomie zaufania,
-
granica między „treścią” a „instrukcją” zaciera się,
-
a atak może być przeprowadzony bez klasycznych symptomów (kliknięć, malware, exploitów).
To nie był problem „jednej wpadki Copilota” – tylko przykład ryzyka, które w podobnej formie może dotyczyć wielu narzędzi AI opartych o RAG i integracje z ekosystemami firmowymi.
Wniosek
EchoLeak pokazał, że w narzędziach typu Microsoft Copilot problemem nie jest wyłącznie „czy użytkownik ma uprawnienia do pliku”, ale czy AI potrafi bezpiecznie zarządzać kontekstem i zaufaniem źródeł. W tym przypadku mechanizm RAG mógł połączyć dane wewnętrzne z treścią pochodzącą z zewnątrz, a prompt injection był zaszyty w formacie, który omijał część filtrów. To uświadomiło, że w świecie agentów AI kontekst staje się nowym perymetrem bezpieczeństwa, a treść (mail/dokument) może działać jak instrukcja. Jeśli organizacja wdraża Copilota lub podobne rozwiązania, musi testować je nie tylko jak produkt SaaS, ale jak system zdolny do niekontrolowanej agregacji i ujawniania danych.
Konwersacje z ChatGPT zaindeksowane w Google: „share link” zamienił się w publiczny wyciek
To był jeden z najbardziej „podstępnych” incydentów w świecie AI, bo z perspektywy użytkownika wyglądał jak zwykła funkcja udostępniania. W praktyce jednak część osób nieświadomie doprowadziła do sytuacji, w której ich rozmowy z ChatGPT stały się publicznie wyszukiwalne w Google.
W tym przypadku nie doszło do klasycznego włamania ani wycieku bazy danych. Problem wynikał z połączenia trzech elementów: nawyku dzielenia się linkiem, nieoczywistej opcji „discoverable” oraz faktu, że wyszukiwarki traktują publiczną stronę jak każdą inną treść w sieci.
Mechanizm działania – co się stało?
Schemat był prosty, ale konsekwencje ogromne:
-
Użytkownik udostępniał rozmowę linkiem (Shared Link)
ChatGPT umożliwiał wygenerowanie publicznego URL-a do konwersacji – np. żeby wkleić go koledze, zespołowi, klientowi albo wrzucić na forum. -
W procesie udostępniania pojawiła się opcja „Make this link discoverable”
To była dodatkowa opcja (eksperymentalna), która pozwalała, aby link był nie tylko dostępny „dla osób z linkiem”, ale także widoczny dla wyszukiwarek. -
Wyszukiwarki zaczęły indeksować udostępnione rozmowy
Skoro rozmowa miała publiczny URL i była oznaczona jako „discoverable”, roboty Google mogły ją normalnie skanować i dodawać do indeksu. -
Rozmowy stawały się odnajdywalne przez proste zapytania w Google
W praktyce wystarczyło użyć określonych fraz lub komend typu „site:” i nagle można było znaleźć rozmowy zawierające bardzo prywatne treści: opisy problemów zdrowotnych, konflikty rodzinne, dane zawodowe, fragmenty kodu, pomysły na produkty, decyzje biznesowe.
Dlaczego to było tak poważne?
Ten incydent był szczególnie głośny, bo dotknął samego serca relacji użytkownik–AI. Ludzie bardzo często traktują ChatGPT jak „bezpieczny notatnik”, a czasem nawet jak zaufanego rozmówcę.
Najważniejsze ryzyka:
-
„To tylko link” przestało oznaczać prywatność
W głowie wielu użytkowników link działa jak sekretne hasło: kto ma link – ten widzi. Problem w tym, że internet nie działa w ten sposób, jeśli treść jest oznaczona jako publiczna. -
Ryzyko przypadkowego ujawnienia danych
W praktyce w rozmowach z AI lądują rzeczy, których ludzie nie wpisaliby do publicznego posta: dane klienta, fragmenty umów, strategia firmy, kod, konfiguracje, logi, opisy incydentów. -
To był „wyciek bez świadomości”
Największa wpadka polegała na tym, że część użytkowników nie zrozumiała konsekwencji zaznaczenia opcji discoverable (albo zrobiła to automatycznie, bez refleksji). -
Szkoda jest trudna do odwrócenia
Nawet jeśli link został usunięty, treść mogła już zostać zindeksowana, zcache’owana lub skopiowana do innych miejsc.
Reakcja OpenAI
Po nagłośnieniu sprawy OpenAI:
-
wycofało mechanizm pozwalający na indeksowanie udostępnionych rozmów,
-
rozpoczęło proces usuwania już zindeksowanych treści z wyszukiwarek,
-
umożliwiło użytkownikom zarządzanie/wyłączanie wcześniej udostępnionych linków w panelu Shared Links.
Wniosek
Ten przypadek pokazał, że w narzędziach AI największe zagrożenia często nie wynikają z „hakowania”, tylko z nieintuicyjnych mechanizmów udostępniania i mylnego poczucia prywatności. ChatGPT nie stał się nagle mniej bezpieczny jako system – ale interfejs i model dystrybucji treści sprawiły, że rozmowy mogły „wypłynąć” do internetu. To ważna lekcja dla każdego, kto pracuje z AI w firmie: trzeba traktować konwersacje jak dane wrażliwe, wprowadzić zasady redakcji informacji i ograniczyć publiczne udostępnianie – bo „tylko link” potrafi skończyć się wyszukiwarką.
ChatGPT „wyciek danych”: kiedy błąd systemu przedstawiał cudze rozmowy i dane rozliczeniowe
Drugą wpadką, którą warto było opisać w tym artykule, nie był ani prompt injection, ani problem z agentami AI. Tym razem zagrożenie wynikało z czegoś bardziej „klasycznego” — z błędu po stronie samej aplikacji i infrastruktury. W jednym z głośniejszych incydentów związanych z ChatGPT doszło do sytuacji, w której część użytkowników mogła zobaczyć dane, które nie powinny nigdy opuścić kont innych osób.
To był incydent szczególnie ważny z perspektywy zaufania, bo wiele osób traktowało rozmowy z AI jak prywatny notatnik: wpisywali tam treści firmowe, fragmenty kodu, dane projektowe, a czasem również tematy stricte osobiste.
Co się stało?
W uproszczeniu problem wynikał z błędnej obsługi mechanizmów sesji i cache’u, czyli elementów, które mają poprawiać wydajność działania systemu. W określonych warunkach dochodziło do nieprawidłowego powiązania danych z kontem użytkownika.
Skutki były poważne:
-
część osób mogła zobaczyć tytuły rozmów należących do innych użytkowników w historii czatu,
-
w ograniczonym zakresie incydent dotyczył również danych związanych z rozliczeniami subskrypcji (billing), co dodatkowo podniosło rangę problemu.
W reakcji na sytuację system został tymczasowo ograniczony (m.in. funkcje historii), a następnie wdrożono poprawki oraz przeprowadzono analizę wpływu incydentu.
Dlaczego to miało znaczenie?
Ten przypadek był istotny, bo pokazał bardzo prostą, ale często pomijaną prawdę: AI to nie tylko model i prompt. ChatGPT działał jako kompletna aplikacja webowa z backendem, pamięcią podręczną, sesjami użytkowników, mechanizmami bezpieczeństwa i warstwą płatności. I nawet jeśli sam model nie generował nic „złego”, to błąd w architekturze aplikacji mógł doprowadzić do wycieku danych.
Co więcej, w narzędziach AI konsekwencje takich incydentów mogą być większe niż w klasycznych aplikacjach, bo użytkownicy częściej wpisują do czatu rzeczy, które normalnie chroniliby mocniej niż standardowe dane w systemie.
Wniosek
Ta wpadka była mocnym przypomnieniem, że ryzyka w AI nie dotyczą wyłącznie ataków „nowej generacji” typu prompt injection. Czasem wystarczył błąd w warstwie sesji i cache, aby doszło do naruszenia prywatności. Dlatego narzędzia AI wdrażane w organizacjach powinny być traktowane jak pełnoprawne systemy przetwarzania danych: z oceną ryzyka, testami bezpieczeństwa aplikacyjnego, monitoringiem oraz jasno określonymi zasadami, jakich danych w ogóle nie wolno do nich wprowadzać.
Podsumowanie
Wpadki bezpieczeństwa narzędzi AI to kolejny wpis z działu Eksplozje. Tym razem kierujemy Waszą uwagę na obszar, który rozwija się szybciej niż standardy i procedury: narzędzia oparte o sztuczną inteligencję. AI wchodzi dziś do codziennej pracy w IT — wspiera kodowanie, analizę, komunikację i podejmowanie decyzji — ale jednocześnie tworzy zupełnie nową powierzchnię ataku oraz ryzyka, które jeszcze kilka lat temu praktycznie nie istniały.
