Welche Daten xAI Grok Build CLI an xAI sendet: Eine Analyse auf Wire-Ebene

 (gist.github.com/cereblab)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Das direkte Mitschneiden des Netzwerkverkehrs von grok 0.2.93 zeigte, dass Grok Build gelesene Dateien ohne Maskierung übertrug und als session_state speicherte; auch Test-Geheimnisse aus .env waren auf zwei Wegen unverändert enthalten
  • Getrennt von den Modellanfragen, die vom Agenten gelesene Dateien senden, wurde das gesamte Repository inklusive aller getrackten Dateien und der Git-Historie als Git-Bundle hochgeladen; auch Dateien, die ausdrücklich nicht geöffnet werden sollten, konnten unverändert wiederhergestellt werden
  • In einem 12-GB-Repository mit Zufallsdateien umfassten die /v1/responses-Anfragen insgesamt 192 KB, während die /v1/storage-Übertragungen bis zum Abbruch der Aufzeichnung 5,10 GiB erreichten – ein Unterschied um etwa das 27.800-Fache; alle Storage-Anfragen erhielten HTTP 200
  • Ziel der Uploads war der Google-Cloud-Storage-Bucket grok-code-session-traces; selbst bei deaktiviertem „Improve the model“ blieben trace_upload_enabled: true und upload_enabled: true gesetzt, und der Upload des gesamten Repositorys lief weiter
  • Die Experimente belegen Übertragung, Annahme und Speicherung der Daten, nicht jedoch eine Nutzung für das Modelltraining; außerdem wurden .gitignore-Dateien und nicht alle Konto-/Konfigurationskombinationen getestet, daher gelten die Ergebnisse nur für eine bestimmte Version im Juli 2026

Testgegenstand und Umfang der Analyse

  • Getestet wurde die offizielle Grok Build CLI von xAI, angemeldet mit einem normalen Consumer-Account
    • Installationspfad: ~/.grok/bin/grok
    • Authentifizierung im Browser mit X- oder SuperGrok-Konto, ohne API-Key
    • Test-Binary: grok 0.2.93 (f00f96316d4b) für Apple Silicon
    • SHA-256: 2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c
  • In den Binary-Strings wurden eigene Rust-Upload-Komponenten und speicherbezogene Konstanten gefunden
    • crates/codegen/xai-data-collector/src/gcs.rs
    • storage_client.rs, queue.rs, file_access_tracker.rs, circuit_breaker_observer.rs
    • xai-grok-shell/src/upload/{gcs,turn,trace,manifest}.rs
    • grok-code-session-traces, storage.googleapis.com, Uploading bytes to GCS via proxy
  • Alle Captures betrafen nur den Computer und den Traffic des Testers; im Repository wurden statt echter Zugangsdaten eindeutige Canary-Strings verwendet

Reproduktion und Mitschnitt des Netzwerkverkehrs

  • Auf macOS Apple Silicon wurde das CA-Zertifikat von mitmproxy als vertrauenswürdiges Zertifikat im Login-Keychain hinzugefügt und HTTPS_PROXY sowie SSL_CERT_FILE gesetzt, um die HTTPS-Anfragen von Grok mitzuschneiden
  • Grok blockierte den Mitschnitt in dieser Konfiguration nicht durch Certificate Pinning
  • Ein mitmdump-Addon protokollierte pro Anfrage Methode, Host, Pfad, Antwortstatus und Größe der Request-Bytes und speicherte Request-Bodies für Anfragen an xAI-Hosts
  • ~/.grok/upload_queue/* wurde während der Ausführung kopiert und anschließend mit gzip und tar entpackt, um auch die gestagten Artefakte in der Upload-Warteschlange zu untersuchen
  • Jede Datei erhielt einen eindeutigen Marker zur Herkunftszuordnung; für Secret-Dateien wurden folgende Fake-Werte benutzt
    • API_KEY=CANARY7F3A9-SECRET-should-not-leave
    • DB_PASSWORD=CANARY7F3A9-DBPASS

Kanal A: Übertragung gelesener Dateien und von .env in Modellanfragen

  • Inhalte von Dateien, die Grok gelesen hatte, wurden in den Body des Modell-Turns von POST cli-chat-proxy.grok.com/v1/responses serialisiert
    • Die mitgeschnittene Anfrage über 48.070 Byte enthielt "model":"grok-4.5" und ein Nachrichten-Array
    • Die Canaries für API_KEY und DB_PASSWORD aus .env fanden sich inklusive Zeilenumbrüchen unverändert wieder
    • Sechs Marker, darunter Source-Code, Logik, README, verschachtelte JavaScript-Dateien und beide Secret-Werte, konnten aus dem Request-Body rekonstruiert werden
  • Derselbe Inhalt befand sich auch im session_state-Archiv und wurde per POST /v1/storage hochgeladen; diese Storage-Anfrage wurde mit HTTP 200 akzeptiert
    • Nach dem Entpacken des komprimierten Archivs fanden sich beide Secret-Werte und weitere Dateimarker wieder
    • Die Secret-Werte wurden also nicht nur vorübergehend vom Modell verarbeitet, sondern auch in ein Speicherarchiv geschrieben
  • Bei einem Kontroll-Prompt Reply exactly OK, do not read any files erschien der Marker aus der nicht geöffneten Datei untouched_secret.txt nicht im Body von /v1/responses
    • Das belegt nur, dass der Kanal für Modellanfragen sich auf Dateien konzentriert, die der Agent tatsächlich gelesen hat
    • Da ein separater Vollsnapshot-Kanal auch ungelesene Dateien enthält, widerlegt dieses Kontrollergebnis keinen Upload des gesamten Repositorys
  • Die Secret-Werte befanden sich in .env oder secrets.env und waren Git-getrackte Dateien
    • Ob auch in .gitignore enthaltene Dateien hochgeladen werden, wurde nicht gesondert getestet
    • Die Canaries hatten nicht das Format echter hochentropischer Tokens; damit ist nicht bewiesen, dass es keinerlei spezielle Maskierung für bestimmte Formen wie sk-… gibt
    • Belegt ist, dass die getesteten .env-Inhalte unmaskiert übertragen wurden

Kanal B: Upload des gesamten Repositorys inklusive ungelesener Dateien

  • /v1/storage lud getrennt von /v1/responses, das die vom Modell gelesenen Dateien überträgt, einen Vollsnapshot des gesamten Workspace hoch
  • Im realen Repository cereblab_api wurde die CLI nach der Anweisung Reply with exactly: OK. Do not read or open any files. ausgeführt
    • Grok übertrug per POST /v1/storage ein 152.102 Byte großes Git-Bundle; der Server antwortete mit HTTP 200
    • Nach git clone des mitgeschnittenen uploaded_repo.bundle konnte src/_probe/never_read_canary.txt, das nicht geöffnet werden sollte, wiederhergestellt werden
    • Der Marker CANARY-XR47P2-NEVERREAD-UNIQUE war darin unverändert enthalten
    • Das Bundle enthielt 4 Commits, 47 Dateien und die komplette Git-Historie
  • Dasselbe Ergebnis wurde in einem zweiten unabhängigen Repository cereblab_auth reproduziert
    • Ein 31.743 Byte großes Git-Bundle wurde per POST /v1/storage hochgeladen und mit HTTP 200 bestätigt
    • Im wiederhergestellten Repository war der Marker CANARY-AUTH-4T8K2-NEVERREAD aus einer ungelesenen Datei unverändert vorhanden
  • In einem separaten Lauf von cereblab_api mit 298 Dateien listete das gestagte Manifest auch ungelesene Dateien auf
    • src/_probe/never_read_canary.txt wurde zusammen mit echtem Source-Code wie src/apns.ts und src/index.ts aufgeführt
    • Die fileId pro Datei in metadata.json hatte das Format gs://grok-code-session-traces/repo_changes_dedup/v2/supplemental/sha256_…
    • In diesem Lauf verhinderte ein Quotenlimit den vollständigen Upload der Content-Blobs; der tatsächliche Upload wurde jedoch in den separaten Git-Bundle- und 12-GB-Experimenten bestätigt
  • In der Binary fanden sich außerdem Strings wie after_codebase.tar.gz, repo_state.upload, collecting workspace files, spawning background coordinator, was zum Mechanismus der Workspace-Erfassung passt

Multi-GiB-Übertragungen in einem 12-GB-Repository

  • Das Upload-Verhalten wurde beobachtet, während die Repository-Größe mit kaum komprimierbaren Zufallsdateien erhöht wurde
    • Bei 64 MB ergab sich ein einzelnes POST /v1/storage von etwa 48 MB mit HTTP 200, die Logs wurden aber nicht aufgehoben
    • Bei etwa 600 MB gab es Dutzende Chunks von jeweils ca. 7,5 MB, alle mit HTTP 200, aber ohne erhaltene Logs
    • Bei etwa 3 GB wurden nach Multipart-Initialisierung 50-MB-PUTs an storage.googleapis.com beobachtet, die direkten PUT-Logs blieben jedoch nicht erhalten
    • Bei etwa 12 GB wurden fortlaufend Chunks von rund 75 MB an /v1/storage gesendet; die Aufzeichnung wurde bei 5,10 GiB abgebrochen
  • Das erhaltene wire_12gb.log enthält insgesamt 83 HTTP-200-Antworten für /v1/storage*
    • 82 POST /v1/storage für Content-Uploads
    • darunter 73 Chunks von jeweils etwa 75 MB
    • die Summe dieser 73 Chunks beträgt 5,476,083,317B, also 5,10 GiB bzw. 5,48 GB
    • enthalten sind außerdem 9 kleinere POSTs und 1 Duplikatsprüfung über /v1/storage/batch_exists
    • alle /v1/storage*-Requests zusammen umfassten 5,476,228,005B; fehlgeschlagene Storage-Requests gab es nicht
  • Die Aufzeichnung wurde beendet, während der Upload noch lief; damit ist kein vollständiger Upload der gesamten 12 GB bewiesen
    • Auch der letzte Eintrag war ein HTTP 200 für einen Chunk von rund 75 MB
    • Belegt ist, dass mehr als 5,10 GiB fehlerfrei übertragen wurden und das Volumen beim Abbruch weiter anstieg
  • Zwischen den beiden Kanälen derselben Session bestand ein großer Größenunterschied
    • /v1/responses umfasste über 5 Requests hinweg 196,705B, also etwa 192 KB; die größte einzelne Anfrage hatte 60.394 B
    • /v1/storage umfasste 5,10 GiB
    • Daraus ergibt sich ein Unterschied um etwa das 27.800-Fache, was zeigt, dass große Mengen Repository-Daten über einen separaten Speicherkanal flossen und nicht Teil der Modellanfragen waren
  • Modellquotenfehler und Storage-Uploads traten unabhängig voneinander auf
    • In /v1/responses gab es einmal HTTP 402 und dreimal 429
    • Bei einer Session-Bookkeeping-Anfrage trat einmal ein nicht zusammenhängender 404 auf
    • Nach dem ersten 429 folgten dennoch 76 weitere /v1/storage-Antworten mit HTTP 200
    • Alle 82 Storage-Anfragen waren erfolgreich; im Test trat kein Fehler wegen eines Storage-Limits auf
  • Dieses Ergebnis hängt nicht davon ab, dass sich die lokale upload_queue leert
    • Die Queue kann sich sowohl bei erfolgreichem Upload als auch beim Verwerfen leeren und wurde daher nicht als Beleg verwendet
    • Grundlage sind die Capture-Daten, die zeigen, dass Request-Bodies tatsächlich übers Netzwerk gingen und HTTP 200 erhielten, sowie die Wiederherstellung von Dateien aus dem hochgeladenen Git-Bundle

Speicherort und Telemetrie

  • Als Speicherziel wurde nicht AWS S3, sondern der Google-Cloud-Storage-Bucket grok-code-session-traces identifiziert
    • In der Binary fanden sich grok-code-session-traces, storage.googleapis.com, Uploading bytes to GCS via proxy
    • In der erhaltenen metadata.json war das Dateiziel als gs://grok-code-session-traces/… verzeichnet
    • Im Experiment mit etwa 3 GB wurden auch direkte Multipart-PUTs zu diesem GCS-Host beobachtet, die Logs wurden jedoch nicht erhalten
    • Obwohl aws-sdk-s3 in der Binary enthalten war, war das im Test beobachtete Ziel GCS
  • Zusätzlich wurden Telemetrie-Anfragen an Dritte und eigene Endpunkte festgestellt
    • api.mixpanel.com/track und /engage von Mixpanel
    • grok.com/_data/v1/events
    • Alle diese Anfragen erhielten HTTP 200
  • In den geprüften CLI-Installationsskripten und Quickstart-Materialien fanden sich keine Hinweise auf Uploads von repo_state, session_state, ~/.grok/upload_queue oder grok-code-session-traces
    • Es wurden nicht sämtliche xAI-Dokumente und Hilfeseiten untersucht; daher kann nicht sicher behauptet werden, dass dies nirgends dokumentiert ist
    • Belegt ist nur, dass es in den CLI-eigenen Konfigurationsmaterialien nicht offengelegt war
  • ~/.grok/upload_queue konnte pro Turn einen Snapshot von etwa 3 GB stagen und bei hoher Last auf Dutzende GB anwachsen, was den Datenträger füllen konnte
    • Das ist ein Zuverlässigkeitsproblem, getrennt von den Datenschutzfragen des Uploads

Einstellung „Improve the model“ und Reichweite der Richtlinie

  • Dass ein Cloud-Coding-Agent für seine Arbeit notwendigen Code-Kontext an den Server sendet, ist an sich erwartbares Verhalten
  • Das im Test beobachtete Verhalten lässt sich in drei Punkte gliedern
    • Secret-Dateien wie .env werden unmaskiert übertragen
    • dieser Inhalt wird im angegebenen GCS-Bucket gespeichert
    • der Upload des gesamten Repositorys ist standardmäßig aktiviert, ohne in den geprüften CLI-Konfigurationsmaterialien offengelegt zu sein
  • Die Consumer-Richtlinien von xAI behandeln die Datennutzung zur Modellverbesserung und das Opt-out allgemein; Private Chat ist standardmäßig vom Training ausgenommen, und ein Opt-out gilt nicht rückwirkend
    • Relevante Dokumente sind die xAI Privacy Policy und die Consumer ToS
    • Solche allgemeinen Trainingsrichtlinien sind nicht dasselbe wie die Dokumentation einer konkreten repo_state- und GCS-Upload-Pipeline

  • Auch bei deaktiviertem „Improve the model“ stoppt der Upload nicht

    • Selbst mit deaktivierter Einstellung wurde das komplette Repository als Git-Bundle an /v1/storage hochgeladen und mit HTTP 200 bestätigt
    • Per git clone ließen sich ungelesene Dateien und die Git-Historie wiederherstellen
    • In /v1/settings, das die CLI erhielt, blieben "trace_upload_enabled": true, "upload_enabled": true, "session_registry_enabled": true gesetzt
    • Außerdem wurde "max_upload_file_bytes": 1073741824 zurückgegeben, also ein Limit von 1 GiB pro Datei
    • Im Testergebnis steuerte das Opt-out möglicherweise das Training, blockierte aber nicht, dass Repository-Daten den Computer verlassen, hochgeladen und gespeichert werden

Nicht belegte Punkte und Grenzen der Beweislage

  • Allein aus Netzwerk-Captures lässt sich nicht beweisen, dass xAI die Daten für das Modelltraining verwendet
    • Belegt sind Übertragung, HTTP-200-Annahme, Speicherarchive und das GCS-Ziel
  • Die im 3-GB-Lauf beobachteten direkten PUT-Logs an storage.googleapis.com/grok-code-session-traces wurden überschrieben und nicht erhalten
    • Der Nachweis für Multi-GiB-Uploads stützt sich auf die erhaltenen /v1/storage-Logs des 12-GB-Laufs sowie auf Binary- und Metadata-Hinweise auf den Bucket
  • Von den Größenversuchen mit 64 MB, 600 MB und 3 GB blieben keine Logs erhalten; nur die 12-GB-Logs wurden aufgehoben
  • Der 12-GB-Lauf wurde bei etwa 5,10 GiB abgebrochen, daher kann nicht sicher behauptet werden, dass die vollen 12 GB bis zum Ende hochgeladen würden
  • Es wurden nicht alle Kontostufen und Konfigurationskombinationen getestet
    • Im Free-Tier gelang ein Multi-GiB-Upload
    • Bei SuperGrok gelang ein Git-Bundle-Upload auch bei deaktiviertem „Improve the model“
    • Im Test wurde keine Einstellung gefunden, um Uploads zu deaktivieren; daraus folgt aber nicht, dass dies in keiner Umgebung jemals möglich ist
  • Anfangs wurde aus PID-basierten nettop-Ergebnissen fälschlich geschlossen, dass keine großen Blobs hochgeladen würden; diese Einschätzung wurde zurückgezogen
    • Ein separater Upload-Koordinator-Prozess und direkt an Google-IP-Adressen gerichtete vorab signierte PUTs können bei Messungen pro API-Host oder einzelner PID übersehen werden
    • Die spätere Proxy-Wire-Capture ersetzt diese frühere Einschätzung
  • Die Ergebnisse gelten nur für grok 0.2.93, macOS Apple Silicon und die Umgebung im Juli 2026; xAI kann das Verhalten später geändert haben

Wichtige erhaltene Belege

  • secrets_responses_body.bin: zeigt, dass der Klartext aus .env im Body von /v1/responses enthalten war
  • secrets_session_state.tar.gz: zeigt, dass dieselben Secret-Werte im Archiv für /v1/storage enthalten waren
  • wire_12gb.log: dokumentiert 5,10 GiB Storage-Upload, 83 /v1/storage* mit HTTP 200, 0 Storage-Fehler und den Größenunterschied der beiden Kanäle um etwa das 27.800-Fache
  • model_limit.txt: dokumentiert 1× 402 und 3× 429 bei Modellanfragen
  • crate_strings.txt: bewahrt die Strings xai-data-collector, grok-code-session-traces, storage.googleapis.com
  • uploaded_repo.bundle: erster Repository-Beleg dafür, dass sich ungelesene Dateien und die komplette Git-Historie aus dem hochgeladenen Git-Bundle wiederherstellen ließen
  • uploaded_repo_auth.bundle: Beleg für dieselbe Reproduktion in einem zweiten unabhängigen Repository
  • staged_base_tree_manifest.json: zeigt, dass ungelesene Dateien im Snapshot-Manifest des Repositorys aufgeführt waren
  • staged_metadata.json: zeigt, dass das Dateiziel gs://grok-code-session-traces/… war
  • gcs_puts.txt ist ein leerer Platzhalter, da direkte GCS-PUTs nicht erhalten wurden, und kann nicht als Beleg für diese PUTs dienen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Hacker-News-Kommentare

  • Ich trenne Coding-Tools und LLM-Anbieter immer und beschränke die Berechtigungen der Coding-Tools mit einer bubblewrap-Sandbox.
    Das Tool kann nur das jeweilige Projekt-Arbeitsverzeichnis lesen, .git ist nur lesbar, und sensible Verzeichnisse werden als leere Verzeichnisse gemountet.
    Auch der Netzwerk-Namespace ist isoliert: Internetzugriff gibt es nur über einen HTTP-Proxy auf einem Unix-Socket, und nur bestimmte Hosts von LLM-Anbietern sind erlaubt, während die Hosts des Tools selbst blockiert werden.
    Bei Crush erlaube ich zum Beispiel den Zugriff auf *.openrouter.ai, blockiere aber *.charm.land, das für automatische Updates der LLM-Liste genutzt wird. Dadurch wird es deutlich angenehmer, im yolo-Modus alle Aufgaben abzugeben.

    • Bei bubblewrap ist es sinnvoll, ein rootfs wie debian:unstable von Docker Hub zu beziehen und in einem separaten Ordner als vollständige Distributionsumgebung einzurichten.
      Darin installiert man den AI-Agenten und erstellt dann ein Skript, das bwrap so ausführt, dass das Distributions-rootfs nur lesbar und ein eigenes /home/user les- und schreibbar ist. Wichtige Dateien außerhalb der angegebenen Verzeichnisse sind nicht sichtbar, und mehrere Agenten können so ausgeführt werden, dass sie sich gegenseitig nicht sehen.
      Zur weiteren Härtung kann man im Inneren gVisors runsc ... do ... aufrufen oder einen Virtual-Machine-Monitor wie muvm verwenden. bwrap kümmert sich um die Umgebung, während ein separates Sandbox-Tool sie absichert; das macht den Ansatz vertrauenswürdig.
      Wenn die Konfiguration korrekt ist, reicht bwrap allein für die meisten Angreifer aus; für eine Rechteausweitung bräuchte man praktisch wohl einen Linux-Kernel-Zero-Day.
    • Mich würde interessieren, welche Methode man bei der Umsetzung davon verwendet.
    • Mich würde auch interessieren, ob diese zusätzliche Sicherheits-Härtung nur ein besseres Gefühl gibt oder ob sie tatsächlich schon gefährliches Verhalten abgefangen hat.
      Wenn ein Modell so dumme Dinge tut, dass man es mit Einschränkungen stoppen muss, ist es meiner Ansicht nach von vornherein nicht nutzenswert. Ich härte meine eigene Umgebung ebenfalls, will die Praxis an sich also nicht kritisieren.

  • Proprietäre native Coding-Agent-Runner wie claude-code, Codex oder grok-build sind aus Datenschutzsicht riskant, weil man nicht weiß, welche nicht öffentlichen Funktionen mit dem nächsten Update hinzukommen.
    Modelle über eine API in opencode zu nutzen ist deutlich sicherer, bringt aber den Kompromiss mit sich, dass es schwer ist, die gleiche Performance wie mit nativen Runnern zu erreichen.

    • Bei genügend Nutzung kann man auch allein über serverseitige Tool-Aufrufe die gesamte Codebase rekonstruieren, und dieser Vorgang ist extrem schwer vollständig zu erkennen.
      Groks Vorgehen ist nur offensichtlicher; auch opencode schafft praktisch keine echte Sicherheitsgrenze und erinnert an das Meme, Cheetos als Schloss zu verwenden.
    • Codex ist Open Source.
    • Auch automatische Updates sind an sich ein großes Problem.
      Dinge wie die Remote-Code-Execution-Schwachstelle in Windows XP SP1 nicht sofort zu patchen ist ebenfalls riskant, aber in den vergangenen Jahrzehnten habe ich mehr Schäden durch automatische Updates gesehen als durch Schäden, die wahrscheinlich durch ausbleibende Updates entstanden wären.
    • Ich nutze meinen eigenen Agenten, kann aber nicht riskieren, dass deswegen das Firmenkonto gesperrt wird.

  • Die Aussage, dass „unabhängig davon, welche Dateien der Agent gelesen hat, das gesamte Repository hochgeladen wird, einschließlich aller getrackten Dateiinhalte und der Git-Historie“, ist sehr schockierend.
    Ich hatte gewissermaßen erwartet, dass Elon so etwas tun könnte, um aufzuholen, aber es ist ernsthaft besorgniserregend. Der Preis ist konkurrenzfähig und die Leistung von grok-4.5 auch gut genug, aber genau aus diesem Grund habe ich mich nicht dafür entschieden.

    • Das ist eindeutig ein Datenabfluss und sollte illegal sein.
    • Wegen der Partnerschaft mit Microsoft frage ich mich, ob OpenAI ebenfalls Zugriff auf alle GitHub-Repositories haben kann.
    • Am Ende ist es ein Race to the Bottom.
    • Ich habe gezögert, selbst die kostenlose Testversion zu nutzen, weil ich keine Informationen dazu finden konnte, welche Daten geteilt werden müssen.
    • Solche CLIs führe ich immer in einer Sandbox aus, die die zugänglichen Verzeichnisse beschränkt.
      Die CLI könnte versehentlich SSH-Keys oder andere sensible Informationen mitnehmen, und Programmierer machen solche Fehler tatsächlich häufig. Ich möchte meine Sicherheit nicht davon abhängig machen, ob „alle zugänglichen Dateien hochladen“ Absicht oder ein Versehen ist.

  • Der erste Punkt, dass „das Modell eine Datei mit Geheimnissen im Repository gelesen hat“, ist im Grunde beabsichtigtes Verhalten.
    Ein LLM kann vor dem Lesen einer Datei nicht beurteilen, ob darin Geheimnisse stehen. Das grundlegende Problem liegt eher darin, einem LLM Zugriff auf eine Datei mit Klartext-Geheimnissen zu geben und sich dann zu wundern, dass es sie liest.
    Das automatische Hochladen des gesamten Repositorys ist allerdings absurd. Bei Repositories im GB-Bereich würde das auf manchen Leitungen sehr lange dauern, und wenn es nicht den anderen Zweck gibt, alle Daten einzusammeln, wirkt es im Allgemeinen sinnlos.

  • Da ich immer davon ausgegangen bin, dass der aktuelle Workspace, in dem man einen Agenten ausführt, zumindest frei vom Agenten genutzt werden kann, wirkt das wie erwartetes Verhalten.
    Die meisten Agenten lesen beim ersten Prompt den Code samt darin enthaltenen Geheimnissen. Wenn der Server das nutzt, um Prompt-Roundtrips und Tool-Aufrufe zu reduzieren, frage ich mich, ob das nicht sogar ein Vorteil für die Nutzer ist.

    • Beim Lesen von Dateien und Übermitteln der Antwort wird die normale Message-API verwendet.
      Hier wurde jedoch ein separater Endpunkt entdeckt, der den gesamten Projektordner in einen GCP-Storage-Bucket exfiltriert. Wer große verteilte Systeme entworfen hat, erkennt daran eine Struktur zum Einsammeln von Trainingsdaten.
    • Soweit ich weiß, führt Cursor lokal eine Art Indexierung durch.
      Auch ohne alle Dateien hochzuladen kann es per Suche die relevanten Teile finden und an das Modell senden, damit es sie verwenden kann.

  • Es wäre gut gewesen, wenn die Zusammenfassung von einem Menschen geschrieben worden wäre, aber der Inhalt selbst ist beunruhigend.

    • Ein paar Codeblöcke, die zeigen, was hochgeladen wird, plus zwei bis drei Absätze hätten für den Artikel gereicht.
      Von KI geschriebene Berichte sind so mühsam zu lesen, dass ich nach etwa zehn Sekunden Überfliegen das Interesse verloren habe.
    • Zumindest hätte ein Mensch den Text mit dem LLM noch ein paar Runden überarbeiten und den Stil verbessern können.

  • Ich frage mich, ob die gestohlenen Inhalte in das Macrohard-Projekt, das „alle Unternehmen automatisiert“, oder in die „everything app“ einfließen werden.
    Es wirkt wie die Idee: Man muss nicht alles selbst bauen, wenn man es einfach stehlen kann.

    • Die Krönung ist, dass Nutzer sogar dafür bezahlen, in den Genuss dieses Privilegs zu kommen.
      Wenn man ein solches Unternehmen ohne Moral betreibt, würde man versuchen, so viel wie möglich zu stehlen, bevor das Ausmaß des Betrugs sichtbar wird und Regulierung es stoppt. Das heißt nicht, dass sie das tatsächlich tun, aber die wirtschaftlichen Anreize sind genau in diese Richtung ausgerichtet.

  • Man sollte davon ausgehen, dass AI Agents Dateien in dem Verzeichnis lesen können, in dem der Runner gestartet wurde.
    Meist lesen sie schon beim ersten Prompt den Code samt darin enthaltenen Geheimnissen; .env ist für die lokale Umgebung gedacht und sollte keine echten Geheimnisse enthalten. Da man den Anweisungen von AI Agents nicht trauen kann, müssen echte Geheimnisse von ihnen isoliert werden.
    Wenn man diese Annahme akzeptiert, könnte es sogar besser sein, den Code auf dem Server abzulegen, statt ihn jedes Mal als Kontext zu senden.

    • Aufgrund der Funktionsweise von LLMs muss der Code am Ende ohnehin über den Kontext erneut übergeben werden.
      Der einzige Grund für einen solchen separaten Upload scheint mir zu sein, dass Musk saubere Trainingsdaten für das nächste Modell sammeln will, etwa Projektstrukturen, beliebte Libraries und CI-Workflows.
    • Selbst wenn der Code einmal hochgeladen wurde, fließt er weiterhin in den Inferenzprozess ein; gespart wird höchstens ein wenig HTTP-Traffic.
    • Der Kern der Geschichte ist nicht besonders groß. Vermutlich ist Grok bei der Kontextzusammenstellung etwa 10 % aggressiver als andere Anbieter, oder diese Methode ließ sich schlicht schneller ausliefern.
      Alle Anbieter haben die Fähigkeit und den Anreiz, dasselbe zu tun, wenn es die Ergebnisse verbessert.
      Der eigentliche Unterschied besteht darin, dass Dateien mit Geheimnissen wie .env ungefiltert übertragen, nicht nur temporär verarbeitet, sondern in einem benannten GCS-Bucket gespeichert werden und der Upload standardmäßig aktiviert wurde, ohne die Upload-Methode in der CLI-Konfigurationsdokumentation offenzulegen.
      Man sollte keine unverschlüsselte .env in einem zugänglichen Pfad ablegen. Es wäre besser, wenn Grok Geheimnisse erkennen und ignorieren würde, aber Nutzer sollten sich nicht auf ein solches Verhalten verlassen.

  • Dass das gesamte Repository identisch hochgeladen wird, egal ob die Einstellung „Improve the model“ ein- oder ausgeschaltet ist, ist äußerst schwerwiegend.
    Die meisten AI-Anbieter würden bei Zustimmung zur Datenerfassung über ihre eigenen Runner wohl Ähnliches tun, aber trotz ausdrücklicher Deaktivierung hochzuladen, ist böswillig.

  • Wenn die gesamte Codebase hochgeladen wird, kann das Modell den Code ansehen, während es „denkt“, ohne beim Client tatsächliche Tool-Aufrufe anzufordern.
    Es ist unklar, worin der Nachteil liegen soll, erneut beim Client anzufragen, daher ist das kein besonders guter Grund, aber es ist die beste Rechtfertigung, die mir einfällt.

    • Der tatsächliche Zweck wirkt eher so, als ginge es darum, Geschäftsgeheimnisse, App-Designs und internes Arbeitswissen zu stehlen oder Code, Apps, Tools und Abläufe zu kopieren.
      Code, der ursprünglich privat war, wird nun zu ihrem Code.
    • Es könnte dafür gedacht sein, den Rechner selbst im Offline-Zustand über einen Container irgendwo vom Smartphone aus fernzusteuern und später bei der Rückkehr zur lokalen Entwicklung die Änderungen aus dem GCP-Bucket zu synchronisieren.
      Das ist ziemlich nützlich, aber nicht nützlich genug, um Elon das gesamte Repository zu überlassen. Dass man es nicht ablehnen kann und es überhaupt nicht offengelegt wurde, bestärkt nur die Einschätzung, dass man ihnen diese Daten nicht anvertrauen sollte.