Zachowania związane z eksfiltracją danych zaprzeczające marketingowi "local-first"

Badacz zidentyfikował dwie zasadniczo różne ścieżki danych opuszczających komputer programisty :

• Kanał odpowiedzi modelu (POST /v1/responses): pliki, które agent otworzył, były serializowane do żądań modelu. Jest to oczekiwane zachowanie chmurowego agenta kodowania.
• Kanał przechowywania (POST /v1/storage): całe repozytorium było niezależnie pakowane jako git bundle i przesyłane w ~75 MB fragmentach do zasobnika Google Cloud Storage o nazwie grok-code-session-traces .

Skala rozbieżności udowodniła, że wysyłanie nie było napędzane tym, co agent przeczytał. W przypadku 12 GB repozytorium testowego kanał przechowywania przesłał 5,10 GiB w 73 fragmentach (wszystkie z kodem HTTP 200), podczas gdy kanał odpowiedzi modelu przesłał zaledwie 192 KB – stosunek ~27 800:1 . Nawet po wydaniu polecenia "odpowiedz OK, nie czytaj żadnych plików" narzędzie przesłało całe repozytorium jako git bundle; sklonowanie przechwyconego bundle'a pozwoliło odzyskać plik (src/_probe/never_read_canary.txt), którego agentowi wyraźnie zabroniono otwierać, wraz z pełną historią commitów Gita .

Rodzaje sekretów i plików przesłanych bez maskowania

• Pliki .env zawierające klucze API, hasła do baz danych i inne poświadczenia były przesyłane dosłownie, bez maskowania ani zaciemniania za pośrednictwem obu kanałów . W kontrolowanych testach 48 KB plik zawierający dane uwierzytelniające bazy danych i klucze API pojawił się w czystej postaci w treści żądania .
• Każdy śledzony plik w repozytorium, plus pełna historia Gita (wszystkie commity, gałęzie, tagi) został spakowany i przesłany . Oznacza to, że usunięte sekrety, które zostały zatwierdzone miesiące temu, ale później zmienione, mogą nadal znajdować się w przesłanych danych.
• Mechanizm wysyłania został zidentyfikowany jako autorska paczka Rusta (xai-data-collector) znajdująca się w binarce, ze ścieżkami źródłowymi takimi jak crates/codegen/xai-data-collector/src/gcs.rs i crates/codegen/xai-grok-shell/src/upload/ .
• W przypadku prawdziwej 12 GB bazy kodów z losowymi plikami, których agent nigdy nie czytał, endpoint przechowywania akceptował przesyłane dane bez odrzucania ich ze względu na rozmiar; jedynymi odpowiedziami innymi niż 200 były błędy limitu użycia modelu (402/429), a nie błędy przechowywania .

Nieskuteczność przełącznika rezygnacji

Badacz przetestował przełącznik prywatności "Improve the model" (Ulepszaj model) i stwierdził, że nie zatrzymał on wysyłania danych .

• Po wyłączeniu przełącznika i restarcie endpoint ustawień serwera nadal zwracał trace_upload_enabled: true .
• Kanał przechowywania nadal akceptował przesyłanie fragmentów git bundle z odpowiedziami HTTP 200 .
• Opcja konfiguracyjna disable_codebase_upload=true istnieje w ustawieniach, ale jej związek z zachowaniem serwera jest nieudokumentowany, a testy badacza wykazały, że serwer nie respektował preferencji klienta .

Zalecane środki zaradcze dla dotkniętych programistów

Oryginalny badacz i inne analizy zalecają następujące działania :

Natychmiastowe działania dla zespołów, które używały Grok Build CLI w prywatnych repozytoriach:

• Zmień wszystkie poświadczenia, które istniały w jakimkolwiek pliku .env, pliku konfiguracyjnym lub historii Gita w repozytoriach używanych z Grok Build, ponieważ mogły zostać przesłane i przechowane w zasobniku GCS grok-code-session-traces .
• Audytuj historię Gita pod kątem sekretów, które mogły istnieć w dowolnym poprzednim commicie, ponieważ CLI wysłało pełną historię commitów .
• Zakładaj, że dane zostały zapisane, a nie tylko przesłane – serwer zwrócił HTTP 200 na wszystkie żądania przechowywania, potwierdzając ich przyjęcie .
• Zapytaj xAI, czy zasobnik został usunięty, jakie istniały mechanizmy kontroli dostępu i czy objęto go Umową o Przetwarzanie Danych (w momencie ujawnienia nie opublikowano żadnej) .

Środki zaradcze na poziomie architektury dla każdego agenta kodowania:

• Uruchamiaj agentów w kontenerach/maszynach wirtualnych z zamontowanym tylko katalogiem zadania, bez katalogu domowego, agenta SSH, gniazda Docker ani katalogów z poświadczeniami chmurowymi .
• Wdróż kontrolę ruchu wychodzącego: zezwalaj na endpointy wnioskowania modelu i hosty uwierzytelniania, ale blokuj bezpośrednie wysyłanie do ogólnych magazynów obiektów. Alerty przy transferach przekraczających 100 MB .
• Użyj przechwytywania pakietów całego hosta, rejestrowania DNS i telemetrii sieciowej endpointów do wykrywania wysyłania przez procesy koordynujące w tle, które mogłyby umknąć licznikom bajtów na pierwszym planie .
• Testuj minimalne i maksymalne monity pod kątem przechwytywania ruchu – przypadki, w których agent ma nie czytać plików, są kluczowe do wykrycia eksfiltracji poza oknem kontekstowym .
• Wykonaj co najmniej trzy przypadki monitów: (1) "odpowiedz OK, nie czytaj żadnych plików", (2) przeczytaj jeden konkretny plik, (3) sprawdź język projektu – a następnie porównaj bajty na endpoint .

Zachowania związane z eksfiltracją danych zaprzeczające marketingowi "local-first"

Badacz zidentyfikował dwie zasadniczo różne ścieżki danych opuszczających komputer programisty :

• Kanał odpowiedzi modelu (POST /v1/responses): pliki, które agent otworzył, były serializowane do żądań modelu. Jest to oczekiwane zachowanie chmurowego agenta kodowania.
• Kanał przechowywania (POST /v1/storage): całe repozytorium było niezależnie pakowane jako git bundle i przesyłane w ~75 MB fragmentach do zasobnika Google Cloud Storage o nazwie grok-code-session-traces .

Skala rozbieżności udowodniła, że wysyłanie nie było napędzane tym, co agent przeczytał. W przypadku 12 GB repozytorium testowego kanał przechowywania przesłał 5,10 GiB w 73 fragmentach (wszystkie z kodem HTTP 200), podczas gdy kanał odpowiedzi modelu przesłał zaledwie 192 KB – stosunek ~27 800:1 . Nawet po wydaniu polecenia "odpowiedz OK, nie czytaj żadnych plików" narzędzie przesłało całe repozytorium jako git bundle; sklonowanie przechwyconego bundle'a pozwoliło odzyskać plik (src/_probe/never_read_canary.txt), którego agentowi wyraźnie zabroniono otwierać, wraz z pełną historią commitów Gita .

Rodzaje sekretów i plików przesłanych bez maskowania

• Pliki .env zawierające klucze API, hasła do baz danych i inne poświadczenia były przesyłane dosłownie, bez maskowania ani zaciemniania za pośrednictwem obu kanałów . W kontrolowanych testach 48 KB plik zawierający dane uwierzytelniające bazy danych i klucze API pojawił się w czystej postaci w treści żądania .
• Każdy śledzony plik w repozytorium, plus pełna historia Gita (wszystkie commity, gałęzie, tagi) został spakowany i przesłany . Oznacza to, że usunięte sekrety, które zostały zatwierdzone miesiące temu, ale później zmienione, mogą nadal znajdować się w przesłanych danych.
• Mechanizm wysyłania został zidentyfikowany jako autorska paczka Rusta (xai-data-collector) znajdująca się w binarce, ze ścieżkami źródłowymi takimi jak crates/codegen/xai-data-collector/src/gcs.rs i crates/codegen/xai-grok-shell/src/upload/ .
• W przypadku prawdziwej 12 GB bazy kodów z losowymi plikami, których agent nigdy nie czytał, endpoint przechowywania akceptował przesyłane dane bez odrzucania ich ze względu na rozmiar; jedynymi odpowiedziami innymi niż 200 były błędy limitu użycia modelu (402/429), a nie błędy przechowywania .

Nieskuteczność przełącznika rezygnacji

Badacz przetestował przełącznik prywatności "Improve the model" (Ulepszaj model) i stwierdził, że nie zatrzymał on wysyłania danych .

• Po wyłączeniu przełącznika i restarcie endpoint ustawień serwera nadal zwracał trace_upload_enabled: true .
• Kanał przechowywania nadal akceptował przesyłanie fragmentów git bundle z odpowiedziami HTTP 200 .
• Opcja konfiguracyjna disable_codebase_upload=true istnieje w ustawieniach, ale jej związek z zachowaniem serwera jest nieudokumentowany, a testy badacza wykazały, że serwer nie respektował preferencji klienta .

Zalecane środki zaradcze dla dotkniętych programistów

Oryginalny badacz i inne analizy zalecają następujące działania :

Natychmiastowe działania dla zespołów, które używały Grok Build CLI w prywatnych repozytoriach:

• Zmień wszystkie poświadczenia, które istniały w jakimkolwiek pliku .env, pliku konfiguracyjnym lub historii Gita w repozytoriach używanych z Grok Build, ponieważ mogły zostać przesłane i przechowane w zasobniku GCS grok-code-session-traces .
• Audytuj historię Gita pod kątem sekretów, które mogły istnieć w dowolnym poprzednim commicie, ponieważ CLI wysłało pełną historię commitów .
• Zakładaj, że dane zostały zapisane, a nie tylko przesłane – serwer zwrócił HTTP 200 na wszystkie żądania przechowywania, potwierdzając ich przyjęcie .
• Zapytaj xAI, czy zasobnik został usunięty, jakie istniały mechanizmy kontroli dostępu i czy objęto go Umową o Przetwarzanie Danych (w momencie ujawnienia nie opublikowano żadnej) .

Środki zaradcze na poziomie architektury dla każdego agenta kodowania:

• Uruchamiaj agentów w kontenerach/maszynach wirtualnych z zamontowanym tylko katalogiem zadania, bez katalogu domowego, agenta SSH, gniazda Docker ani katalogów z poświadczeniami chmurowymi .
• Wdróż kontrolę ruchu wychodzącego: zezwalaj na endpointy wnioskowania modelu i hosty uwierzytelniania, ale blokuj bezpośrednie wysyłanie do ogólnych magazynów obiektów. Alerty przy transferach przekraczających 100 MB .
• Użyj przechwytywania pakietów całego hosta, rejestrowania DNS i telemetrii sieciowej endpointów do wykrywania wysyłania przez procesy koordynujące w tle, które mogłyby umknąć licznikom bajtów na pierwszym planie .
• Testuj minimalne i maksymalne monity pod kątem przechwytywania ruchu – przypadki, w których agent ma nie czytać plików, są kluczowe do wykrycia eksfiltracji poza oknem kontekstowym .
• Wykonaj co najmniej trzy przypadki monitów: (1) "odpowiedz OK, nie czytaj żadnych plików", (2) przeczytaj jeden konkretny plik, (3) sprawdź język projektu – a następnie porównaj bajty na endpoint .