Grok Build, narzędzie xAI przeznaczone do programowania z pomocą sztucznej inteligencji, przesyłało do chmury całe repozytoria użytkowników. Transfer obejmował nie tylko pliki potrzebne do wykonania konkretnego zadania, ale również pozostałą zawartość projektu oraz pełną historię zmian zapisaną w systemie Git.
To poważny problem, ponieważ w historii repozytoriów mogą pozostawać dane, które programista usunął już z aktualnej wersji projektu. Mogą to być między innymi hasła, klucze API, tokeny dostępu, dane konfiguracyjne oraz informacje o wewnętrznej infrastrukturze firmy. Nie ma jednak dowodów, że przesłane materiały zostały przejęte przez osoby trzecie lub wykorzystane do nieautoryzowanego dostępu.
Grok Build przesyłał całe repozytoria użytkowników
Grok Build to agent programistyczny działający z poziomu terminala. Narzędzie może analizować kod, wyszukiwać błędy, modyfikować pliki, uruchamiać polecenia i pomagać w realizowaniu większych zadań obejmujących wiele elementów projektu.
Problem ujawnił niezależny badacz działający pod nazwą Cereblab. Przeanalizował on ruch sieciowy generowany przez wersję 0.2.93 programu Grok Build i wykazał, że aplikacja tworzyła pakiet zawierający repozytorium Git, a następnie wysyłała go do infrastruktury kontrolowanej przez xAI.
Dane trafiały przez endpoint /v1/storage do zasobnika Google Cloud Storage o nazwie grok-code-session-traces. W pakiecie znajdowały się wszystkie śledzone przez Git pliki oraz pełna historia commitów. Mechanizm działał niezależnie od tego, które pliki agent rzeczywiście otworzył podczas wykonywania polecenia.
To istotna różnica. Użytkownik mógł zakładać, że agent przesyła do modelu wyłącznie fragmenty kodu niezbędne do udzielenia odpowiedzi. W praktyce poza kontekstem aktualnego zadania do chmury mógł zostać wysłany znacznie większy zakres danych.
Grok przesłał nawet plik, którego nie miał otwierać
Aby sprawdzić działanie programu, badacz przygotował testowe repozytorium zawierające fałszywe dane uwierzytelniające oraz specjalnie oznaczony plik. Następnie polecił Grokowi odpowiedzieć jedynie „OK” i nie otwierać żadnych plików.
Mimo takiej instrukcji narzędzie przesłało do chmury pakiet całego repozytorium. Po odtworzeniu danych przechwyconych podczas transmisji badacz odzyskał plik, którego Grok nie miał czytać, wraz z jego zawartością i pełną historią zmian projektu.
Podobny rezultat uzyskano po zastosowaniu reguły zabraniającej agentowi odczytu wskazanego pliku. Ograniczenie działało na poziomie rozmowy z modelem — Grok odmawiał otwarcia dokumentu — ale plik nadal znajdował się w automatycznie utworzonym pakiecie Git wysyłanym do serwera.
Według analizy przed wysłaniem chroniło przede wszystkim wykluczenie pliku z repozytorium, na przykład za pomocą .gitignore. Mechanizm przesyłał bowiem pliki śledzone przez Git. Nie oznacza to jednak, że każdy plik nieuwzględniony w repozytorium był całkowicie bezpieczny. Jeżeli agent sam odczytał jego zawartość, mogła ona zostać przekazana jako część zapytania kierowanego do modelu lub zapisu sesji.
W historii Git mogły pozostawać hasła i klucze API
Usunięcie hasła, tokenu albo klucza API z aktualnej wersji pliku nie zawsze usuwa go z repozytorium. Jeżeli dane zostały wcześniej zapisane w commicie, pozostają w historii Git i mogą zostać odzyskane po przejrzeniu starszych wersji projektu.
Ponieważ Grok Build wysyłał również historię repozytorium, do chmury mogły trafiać dane, których nie było już w bieżącej wersji kodu. Dotyczy to między innymi kluczy do zewnętrznych usług, tokenów chmurowych, haseł do baz danych, prywatnych adresów serwerów, certyfikatów oraz parametrów środowiska produkcyjnego.
W analizie Cereblab wykorzystano wyłącznie sztucznie utworzone dane testowe. Badanie nie dowodzi więc, że xAI otrzymało konkretne, prawdziwe hasła należące do użytkowników. Potwierdza jednak, że jeśli takie informacje znajdowały się w śledzonych plikach lub historii Git, mogły zostać dołączone do przesyłanego pakietu.
Szczególnie istotne są pliki .env, w których deweloperzy często przechowują ustawienia środowiskowe i dane dostępowe. Badacz wykazał, że po odczytaniu takiego pliku jego zawartość została przesłana bez zamazania zarówno w zapytaniu do modelu, jak i w archiwum sesji.
Grok Build wysłał ponad 5 GB danych zamiast 192 KB
Skalę działania mechanizmu pokazał test przeprowadzony na repozytorium zawierającym około 12 GB losowych plików. Grok otrzymał polecenie, które nie wymagało analizowania zawartości projektu.
Kanał używany do komunikacji z modelem przesłał w tym przypadku około 192 KB danych. Jednocześnie przez endpoint odpowiedzialny za przechowywanie materiałów wysłano 5,10 GB. Według obliczeń badacza było to około 27,8 tys. razy więcej danych niż przekazano w ramach samego zadania wykonywanego przez model.
Nie chodziło więc wyłącznie o standardowe przesyłanie fragmentów kodu do systemu AI. Grok Build uruchamiał osobny mechanizm pakowania i wysyłania repozytorium, nawet gdy zawartość większości plików nie była potrzebna do realizacji polecenia.
Dodatkowe kontrowersje wzbudził fakt, że wyłączenie ustawienia pozwalającego na wykorzystywanie danych do ulepszania modelu nie zatrzymywało transferu. Według analizy parametr dotyczący przesyłania zapisów sesji pozostawał aktywny niezależnie od ustawień treningu modelu.
xAI wyłączyło funkcję i opublikowało kod narzędzia
Po nagłośnieniu sprawy xAI zareagowało, wyłączając mechanizm przesyłania repozytoriów. Firma udostępniła również Grok Build jako projekt open source, dzięki czemu niezależni badacze i programiści mogą dokładniej sprawdzić sposób działania aplikacji.
To ważna zmiana, ponieważ wcześniej użytkownicy nie mieli pełnej kontroli nad tym, jakie dane są pakowane i wysyłane podczas pracy z agentem. Otwarcie kodu nie rozwiązuje automatycznie wszystkich problemów, ale ułatwia audyt bezpieczeństwa oraz wykrywanie podobnych mechanizmów w przyszłości.
xAI nie poinformowało, aby doszło do wycieku danych z infrastruktury chmurowej. Nie ma również dowodów, że osoby trzecie uzyskały dostęp do przesłanych repozytoriów. Problem dotyczy przede wszystkim zakresu zbieranych informacji i braku odpowiednio jasnej komunikacji wobec użytkowników.
Nawet jeśli dane trafiały wyłącznie do zabezpieczonej infrastruktury xAI, przesyłanie całego repozytorium bez wyraźnej potrzeby mogło naruszać wewnętrzne zasady bezpieczeństwa firm korzystających z narzędzia.
Programiści powinni zmienić klucze i tokeny
Osoby, które korzystały z Grok Build w projektach zawierających poufne dane, powinny przeprowadzić dodatkowy audyt bezpieczeństwa. W pierwszej kolejności warto sprawdzić historię Git pod kątem haseł, tokenów, kluczy API i innych danych uwierzytelniających.
Jeżeli w repozytorium znajdowały się aktywne klucze dostępowe, najbezpieczniejszym rozwiązaniem jest ich unieważnienie i wygenerowanie nowych. Samo usunięcie klucza z aktualnej wersji pliku nie wystarczy, jeśli nadal pozostaje on w historii commitów.
Warto również przeanalizować logi usług chmurowych, baz danych i zewnętrznych interfejsów API. Pozwoli to sprawdzić, czy klucze nie zostały wykorzystane w nietypowy sposób. Brak dowodów na włamanie nie oznacza bowiem, że aktywne dane dostępowe powinny pozostać bez zmian.
Programiści powinni także unikać przechowywania sekretów bezpośrednio w kodzie. Bezpieczniejszym rozwiązaniem są menedżery sekretów, zmienne środowiskowe oraz mechanizmy automatycznego wykrywania danych uwierzytelniających przed wykonaniem commitu.
Agenci AI wymagają dostępu do coraz większej ilości danych
Sprawa Grok Build pokazuje szerszy problem związany z agentami programistycznymi. Narzędzia tego typu nie tylko generują fragmenty kodu, ale mogą również przeglądać pliki, uruchamiać polecenia, modyfikować projekty i korzystać z terminala.
Im większe uprawnienia otrzymuje agent AI, tym poważniejsze mogą być skutki błędnej konfiguracji albo niejasnego sposobu przetwarzania danych. Szczególne ryzyko pojawia się w projektach firmowych, które zawierają kod objęty tajemnicą przedsiębiorstwa, dane klientów lub informacje o infrastrukturze produkcyjnej.
Użytkownik powinien dokładnie wiedzieć, czy narzędzie przetwarza dane lokalnie, wysyła pojedyncze fragmenty kodu, czy tworzy kopię całego projektu. Takie informacje powinny być prezentowane wprost, a nie ukryte w regulaminie albo dokumentacji technicznej.
Grok Build pokazuje, że wygoda AI ma swoją cenę
Agenci AI mogą znacząco przyspieszać pracę programistów, ale jednocześnie wymagają dostępu do coraz większej części projektu. W przypadku Grok Build ten dostęp okazał się znacznie szerszy, niż mogło wynikać z polecenia wydanego przez użytkownika.
Nie ma obecnie dowodów, że przesłane repozytoria zostały wykradzione lub wykorzystane przez osoby trzecie. Sam fakt automatycznego przesyłania całych projektów, wraz z historią Git, jest jednak wystarczającym powodem do przeprowadzenia audytu bezpieczeństwa.
Sprawa może również wpłynąć na sposób, w jaki firmy oceniają narzędzia programistyczne wykorzystujące AI. Oprócz możliwości modelu coraz większe znaczenie będą miały przejrzystość, kontrola nad danymi oraz możliwość dokładnego określenia, jakie informacje opuszczają komputer użytkownika.
Źródło: The Verge. Opracowanie własne.
Dziękujemy za przeczytanie artykułu na Techoteka.pl.
Publikujemy codziennie informacje o sztucznej inteligencji, nowych technologiach, IT oraz rozwoju agentów AI.
Obserwuj nas na Facebooku, aby nie przegapić kolejnych artykułów.
