xAI Grok Build CLI द्वारा xAI को भेजा जाने वाला डेटा: wire-level विश्लेषण

 (gist.github.com/cereblab)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • grok 0.2.93 के network traffic को सीधे capture करने पर पाया गया कि Grok Build ने पढ़ी गई files को बिना masking के भेजा और session_state के रूप में store किया, तथा test के लिए रखे गए .env secrets भी दो paths में जस के तस शामिल थे
  • model request में agent द्वारा पढ़ी गई files भेजने से अलग, पूरा repository जिसमें सभी tracked files और Git history शामिल थी git bundle के रूप में upload किया गया, और जिन files को खोलने से मना किया गया था वे भी मूल रूप में restore हो गईं
  • 12GB के random file repository में /v1/responses requests कुल 192KB थीं, लेकिन /v1/storage का transfer capture रोकने तक 5.10GiB तक पहुंच गया, यानी लगभग 27,800 गुना अंतर, और सभी storage requests ने HTTP 200 लौटाया
  • upload destination Google Cloud Storage का grok-code-session-traces bucket था, और “Improve the model” बंद करने पर भी trace_upload_enabled: true और upload_enabled: true बने रहे, साथ ही पूरे repository का upload जारी रहा
  • यह experiment data के transfer, acceptance और storage को साबित करता है, लेकिन यह verify नहीं कर सका कि इसे model training में इस्तेमाल किया गया या नहीं, और .gitignore files तथा सभी account/config combinations का परीक्षण नहीं किया गया, इसलिए नतीजे जुलाई 2026 के एक specific version तक सीमित हैं

परीक्षण लक्ष्य और विश्लेषण की सीमा

  • लक्ष्य xAI का आधिकारिक Grok Build CLI था, जिसमें एक सामान्य consumer account से login किया गया था
    • install path ~/.grok/bin/grok था
    • browser में X या SuperGrok account से authenticate किया गया, API key का उपयोग नहीं हुआ
    • test binary Apple Silicon के लिए grok 0.2.93 (f00f96316d4b) थी
    • SHA-256 2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c था
  • binary strings से internal Rust upload components और storage-related constants की पुष्टि हुई
    • 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
  • सभी captures केवल tester के computer और उसके traffic पर किए गए, और repository में असली credentials की जगह unique canary strings रखे गए थे

पुनरुत्पादन और traffic capture की विधि

  • macOS Apple Silicon पर mitmproxy का CA login keychain में trusted certificate के रूप में जोड़कर HTTPS_PROXY और SSL_CERT_FILE सेट किए गए, ताकि Grok की HTTPS requests capture की जा सकें
  • इस setup में Grok ने certificate pinning के जरिए capture को block नहीं किया
  • mitmdump addon के साथ हर request का method, host, path, response status और request byte size log किया गया, और xAI hosts की ओर जाने वाले request bodies save किए गए
  • ~/.grok/upload_queue/* को execution के दौरान copy करके gzip और tar से खोलकर upload की प्रतीक्षा कर रहे staging artifacts भी जांचे गए
  • हर file में source पहचानने योग्य unique marker डाले गए, और secret files में नीचे जैसे fake values उपयोग किए गए
    • API_KEY=CANARY7F3A9-SECRET-should-not-leave
    • DB_PASSWORD=CANARY7F3A9-DBPASS

चैनल A: पढ़ी गई files और .env का model request के जरिए transfer

  • Grok द्वारा पढ़ी गई files की content POST cli-chat-proxy.grok.com/v1/responses के model turn body में serialize की गई थी
    • capture की गई 48,070-byte request में "model":"grok-4.5" और message array शामिल था
    • .env के API_KEY और DB_PASSWORD canary line breaks सहित मूल रूप में मिले
    • source, logic, README, nested JavaScript file और दो secret values सहित 6 markers request body से recover किए जा सके
  • यही content session_state archive में भी गई और POST /v1/storage के जरिए upload हुई, तथा संबंधित storage request को HTTP 200 से accept किया गया
    • compressed archive खोलकर जांचने पर दोनों secret values और अन्य file markers सभी मिले
    • secrets केवल model द्वारा अस्थायी रूप से process नहीं किए गए, बल्कि storage archive में भी लिखे गए
  • Reply exactly OK, do not read any files वाले control prompt में बिना खोली गई untouched_secret.txt का marker /v1/responses body में नहीं मिला
    • इससे केवल इतना साबित होता है कि model request channel की सीमा agent द्वारा वास्तव में पढ़ी गई files पर केंद्रित है
    • अलग full-repository snapshot channel में unread files भी शामिल थीं, इसलिए यह control result पूरे repository upload को खारिज नहीं करता
  • secrets .env या secrets.env में थे और Git-tracked files थे
    • .gitignore में शामिल files भी upload होती हैं या नहीं, इसका अलग से परीक्षण नहीं किया गया
    • canary असली high-entropy token format नहीं थे, इसलिए यह पूरी तरह साबित नहीं होता कि sk-… जैसे specific formats के लिए कोई अलग masking mechanism बिल्कुल नहीं है
    • सत्यापित सीमा बस यह है कि परीक्षण की गई .env content बिना masking के transfer हुई

चैनल B: unread files सहित पूरे repository का upload

  • /v1/storage ने model द्वारा पढ़ी गई files भेजने वाले /v1/responses से अलग पूरे workspace snapshot को upload किया
  • वास्तविक cereblab_api repository में Reply with exactly: OK. Do not read or open any files. निर्देश देकर run किया गया
    • Grok ने POST /v1/storage के जरिए 152,102-byte git bundle भेजा और server ने HTTP 200 लौटाया
    • capture किए गए uploaded_repo.bundle को git clone करने पर src/_probe/never_read_canary.txt, जिसे खोलने से मना किया गया था, restore हो गई
    • file के भीतर CANARY-XR47P2-NEVERREAD-UNIQUE marker भी मूल रूप में मौजूद था
    • bundle में 4 commits, 47 files और पूरी Git history शामिल थी
  • दूसरे स्वतंत्र repository cereblab_auth में भी वही परिणाम पुनरुत्पादित हुए
    • POST /v1/storage के जरिए 31,743-byte git bundle upload हुआ और HTTP 200 लौटा
    • restore किए गए repository में unread file का CANARY-AUTH-4T8K2-NEVERREAD marker जस का तस मिला
  • 298 files वाले अलग cereblab_api run में staged manifest ने unread files तक enumerate कीं
    • src/_probe/never_read_canary.txt के साथ src/apns.ts, src/index.ts जैसी वास्तविक source files भी दर्ज थीं
    • metadata.json में file-wise fileId का रूप gs://grok-code-session-traces/repo_changes_dedup/v2/supplemental/sha256_… था
    • यह run quota के कारण content blob transfer पूरा नहीं कर सका, लेकिन अलग git bundle experiment और 12GB experiment में वास्तविक upload की पुष्टि हुई
  • binary में after_codebase.tar.gz, repo_state.upload, collecting workspace files, spawning background coordinator जैसी strings भी थीं, जो workspace collection mechanism से मेल खाती हैं

12GB repository में multi-GiB transfer की पुष्टि

  • लगभग compress न होने वाली random files से repository size बढ़ाकर upload behavior देखा गया
    • 64MB पर लगभग 48MB का single POST /v1/storage HTTP 200 लौटा, लेकिन log संरक्षित नहीं रहा
    • लगभग 600MB पर लगभग 7.5MB chunks के कई requests ने HTTP 200 लौटाया, लेकिन logs नहीं बचे
    • लगभग 3GB पर multipart initialization के बाद storage.googleapis.com की ओर 50MB units में PUT दिखे, लेकिन direct PUT logs सुरक्षित नहीं रहे
    • लगभग 12GB पर लगभग 75MB chunks /v1/storage पर लगातार भेजे गए और 5.10GiB पर capture रोक दिया गया
  • संरक्षित wire_12gb.log में कुल 83 /v1/storage* HTTP 200 responses हैं
    • content upload POST /v1/storage 82
    • इनमें लगभग 75MB chunks 73
    • 73 chunks का कुल योग 5,476,083,317B, यानी 5.10GiB या 5.48GB
    • 9 छोटे POSTs और /v1/storage/batch_exists का 1 dedupe check भी शामिल है
    • कुल /v1/storage* request bytes 5,476,228,005B थीं, और कोई failed storage request नहीं थी
  • capture upload जारी रहते हुए रोकी गई, इसलिए पूरा 12GB upload पूरा हुआ यह साबित नहीं होता
    • अंतिम record भी लगभग 75MB chunk के लिए HTTP 200 था
    • जो सिद्ध होता है वह यह कि 5.10GiB से अधिक data बिना failure के भेजा गया और रुकने के समय भी बढ़ रहा था
  • उसी session के दो channels के बीच capacity का बहुत बड़ा अंतर था
    • /v1/responses की 5 requests मिलाकर 196,705B, यानी लगभग 192KB थीं, और सबसे बड़ी request भी 60,394B थी
    • /v1/storage 5.10GiB था
    • लगभग 27,800 गुना अंतर दिखा, जिससे model requests में शामिल न हुआ बड़ा repository data अलग storage channel से गया
  • model quota errors और storage upload स्वतंत्र रूप से हुए
    • /v1/responses पर HTTP 402 एक बार और 429 तीन बार आए
    • session bookkeeping requests में असंबंधित 404 एक बार आया
    • पहले 429 के बाद भी /v1/storage पर HTTP 200 कुल 76 बार आते रहे
    • 82 storage requests सभी सफल रहीं, और परीक्षण सीमा में storage capacity limit error नहीं आई
  • यह परिणाम local upload_queue खाली होने जैसी घटना पर निर्भर नहीं है
    • queue upload success और discard दोनों स्थितियों में खाली हो सकती थी, इसलिए इसे evidence नहीं माना गया
    • आधार वे captures हैं जिनमें request bodies वास्तव में network पर गईं, HTTP 200 मिला, और uploaded git bundle से files recover हुईं

storage location और telemetry

  • storage destination AWS S3 नहीं, बल्कि Google Cloud Storage का grok-code-session-traces bucket था
    • binary में grok-code-session-traces, storage.googleapis.com, Uploading bytes to GCS via proxy मौजूद थे
    • संरक्षित metadata.json में file destinations gs://grok-code-session-traces/… के रूप में दर्ज थे
    • लगभग 3GB experiment में संबंधित GCS host पर direct multipart PUT भी देखे गए, लेकिन logs सुरक्षित नहीं रहे
    • binary में aws-sdk-s3 होने के बावजूद, परीक्षण में पुष्टि किया गया destination GCS था
  • third-party और internal telemetry requests भी देखी गईं
    • Mixpanel का api.mixpanel.com/track और /engage
    • grok.com/_data/v1/events
    • इन सभी requests ने HTTP 200 लौटाया
  • review किए गए CLI install script और quickstart materials में repo_state, session_state, ~/.grok/upload_queue, grok-code-session-traces upload का उल्लेख नहीं मिला
    • सभी xAI documents और help pages की जांच नहीं की गई, इसलिए यह निर्णायक रूप से नहीं कहा जा सकता कि कहीं भी documentation नहीं है
    • सत्यापित सीमा बस यह है कि CLI की अपनी setup materials में यह स्पष्ट नहीं था
  • ~/.grok/upload_queue एक turn में लगभग 3GB snapshot stage कर सकता था और अधिक load पर कई दर्जन GB तक बढ़कर disk भर सकता था
    • यह upload की privacy issue से अलग एक reliability issue है

“Improve the model” setting और policy की सीमा

  • cloud coding agent द्वारा काम के लिए आवश्यक code context server पर भेजना अपने आप में आवश्यक behavior हो सकता है
  • परीक्षण में पुष्टि किया गया behavior नीचे के तीन बिंदुओं में अलग होता है
    • .env जैसी secret files को बिना masking के transfer करना
    • उस content को निर्दिष्ट GCS bucket में store करना
    • पूरे repository upload का review की गई CLI setup materials में दिखे बिना default रूप से enabled होना
  • xAI consumer policy model improvement के लिए data use और opt-out को व्यापक रूप से cover करती है; Private Chat अपने आप opt-out है और opt-out retrospective नहीं है
    • संबंधित documents हैं xAI Privacy Policy और Consumer ToS
    • ऐसी सामान्य training policy, specific repo_state और GCS upload pipeline को document करने के बराबर नहीं है

  • “Improve the model” बंद करने पर भी upload नहीं रुकता

    • setting बंद होने पर भी पूरा repository git bundle के रूप में /v1/storage पर upload हुआ और HTTP 200 लौटा
    • git clone से unread files और Git history restore की जा सकी
    • CLI को मिले /v1/settings में "trace_upload_enabled": true, "upload_enabled": true, "session_registry_enabled": true बने रहे
    • "max_upload_file_bytes": 1073741824 के रूप में प्रति file 1GiB limit भी लौटी
    • परीक्षण नतीजों में opt-out ने training usage को control किया, लेकिन repository का computer छोड़कर upload और store होने वाला behavior नहीं रोका

क्या सिद्ध नहीं हुआ और evidence की सीमाएँ

  • केवल network capture से यह साबित नहीं किया जा सकता कि xAI data को model training में इस्तेमाल करता है
    • सत्यापित सीमा transfer, HTTP 200 acceptance, storage archive और GCS destination तक है
  • 3GB run में देखे गए storage.googleapis.com/grok-code-session-traces direct PUT logs overwrite हो गए और सुरक्षित नहीं रहे
    • multi-GiB upload का आधार संरक्षित 12GB run के /v1/storage logs, तथा bucket बताने वाली binary और metadata हैं
  • size-wise tests में 64MB, 600MB, 3GB logs नहीं बचे और केवल 12GB log संरक्षित रहा
  • 12GB run लगभग 5.10GiB पर रोका गया, इसलिए यह निश्चित नहीं कहा जा सकता कि पूरा 12GB अंत तक upload होता
  • सभी account tiers और config combinations का परीक्षण नहीं किया गया
    • free tier में multi-GiB upload सफल हुआ
    • SuperGrok में “Improve the model” बंद होने पर भी git bundle upload सफल रहा
    • परीक्षण में upload बंद करने की setting नहीं मिली, लेकिन यह निर्णायक रूप से नहीं कहा गया कि किसी भी environment में इसे कभी disable नहीं किया जा सकता
  • शुरुआत में PID-based nettop results के आधार पर गलत निष्कर्ष निकाला गया था कि large blobs upload नहीं हुए; यह निष्कर्ष वापस लिया गया
    • अलग upload coordination process और Google IPs की ओर जाने वाले pre-signed direct PUT, API host या single PID-based measurement में छूट सकते थे
    • बाद की proxy wire capture ने शुरुआती निष्कर्ष की जगह ली
  • परिणाम grok 0.2.93, macOS Apple Silicon, जुलाई 2026 environment तक सीमित हैं, और xAI बाद में behavior बदल सकता है

संरक्षित प्रमुख evidence

  • secrets_responses_body.bin: दिखाता है कि .env का मूल content /v1/responses body में शामिल था
  • secrets_session_state.tar.gz: दिखाता है कि वही secrets /v1/storage archive में भी थीं
  • wire_12gb.log: 5.10GiB storage upload, 83 /v1/storage* HTTP 200, 0 storage failures और दोनों channels के बीच लगभग 27,800 गुना size difference को record करता है
  • model_limit.txt: model requests पर आए 402 एक बार और 429 तीन बार record करता है
  • crate_strings.txt: xai-data-collector, grok-code-session-traces, storage.googleapis.com strings को संरक्षित करता है
  • uploaded_repo.bundle: uploaded git bundle से unread files और पूरी Git history restore होने का पहला repository evidence
  • uploaded_repo_auth.bundle: दूसरे स्वतंत्र repository में वही परिणाम दोहराने का evidence
  • staged_base_tree_manifest.json: दिखाता है कि unread files repository snapshot manifest में enumerate की गई थीं
  • staged_metadata.json: दिखाता है कि file destination gs://grok-code-session-traces/… था
  • gcs_puts.txt direct GCS PUT को सुरक्षित न रख पाने के कारण खाली placeholder है, और उस PUT के preserved evidence के रूप में उपयोग नहीं किया जा सकता

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की टिप्पणियाँ

  • मैं हमेशा coding tools और LLM provider को अलग रखता हूँ, और bubblewrap sandbox से coding tool की permissions सीमित करता हूँ
    tool सिर्फ working project directory पढ़ सकता है, .git read-only रहता है, और sensitive directories को empty directories के रूप में mount किया जाता है
    network namespace भी isolate करता हूँ ताकि वह सिर्फ Unix socket के HTTP proxy के ज़रिए internet तक पहुँचे, और केवल खास LLM provider hosts को allow किया जाए, जबकि tool के अपने hosts block रहें
    उदाहरण के लिए Crush में *.openrouter.ai की access allow करता हूँ, लेकिन LLM list auto-update में इस्तेमाल होने वाला *.charm.land block करता हूँ। इसकी वजह से yolo mode में सारे काम सौंपना काफी आसान हो जाता है

    • bubblewrap में Docker Hub का debian:unstable जैसा rootfs लेकर उसे अलग folder में एक complete distribution environment की तरह सेट करना बेहतर रहता है
      उसके अंदर AI agent install करने के बाद distribution rootfs को read-only, और customized /home/user को read-write रखकर bwrap चलाने वाली script बनाई जा सकती है। इससे तय directories के बाहर की महत्वपूर्ण files दिखती ही नहीं, और कई agents को एक-दूसरे से छिपाकर भी चलाया जा सकता है
      इसे और मजबूत करना हो तो अंदर से gVisor का runsc ... do ... call किया जा सकता है, या muvm जैसा virtual machine monitor इस्तेमाल किया जा सकता है। bwrap environment setup संभालता है और locking किसी अलग sandbox tool से होती है, इसलिए इस पर भरोसा करना आसान है
      अगर configuration सही हो तो सिर्फ bwrap भी ज़्यादातर attackers को रोकने के लिए काफी है, और privilege escalation के लिए लगभग Linux kernel zero-day चाहिए होगा
    • यह लागू करते समय आप कौन-सा तरीका इस्तेमाल करते हैं, जानने की उत्सुकता है
    • यह भी जानना चाहता हूँ कि ये अतिरिक्त security hardening सिर्फ मन की शांति देती है, या इसने सच में खतरनाक behavior पकड़ा भी है
      अगर model इतना मूर्खतापूर्ण behavior करता है कि उसे constraints से रोकना पड़े, तो मेरे हिसाब से वह शुरू से इस्तेमाल लायक ही नहीं है। मैं भी अपना environment harden कर रहा हूँ, और यह practice की आलोचना नहीं है

  • claude-code, Codex, grok-build जैसे proprietary native coding agent runners privacy के लिहाज़ से जोखिमभरे हैं, क्योंकि अगली update में कौन-सी private functionality जुड़ जाएगी, यह पता नहीं होता
    opencode में API के ज़रिए model इस्तेमाल करना कहीं ज़्यादा सुरक्षित लगता है, लेकिन native runner जितनी अच्छी performance पाना मुश्किल होने का trade-off रहता है

    • अगर usage काफी हो, तो सिर्फ server-side tool calling से भी पूरा codebase फिर से बनाया जा सकता है, और इस process को पूरी तरह detect करना मुश्किल है
      Grok का तरीका बस ज़्यादा खुला हुआ है; opencode भी असल security boundary नहीं बनाता, और यह Cheetos को ताले की तरह इस्तेमाल करने वाले meme जैसा है
    • Codex open source है
    • auto-update अपने आप में भी बड़ी समस्या है
      Windows XP SP1 की remote code execution vulnerability जैसी चीज़ को तुरंत patch न करना भी जोखिमभरा है, लेकिन पिछले कई दशकों में updates न करने से जितना नुकसान होना चाहिए था, उससे ज़्यादा नुकसान मैंने auto-update की वजह से देखा है
    • मैं अपना agent इस्तेमाल करता हूँ, लेकिन उसके कारण company account ban होने का जोखिम नहीं उठा सकता

  • “agent ने कौन-सी files पढ़ी, इससे अलग tracked सभी files की contents और Git history सहित पूरे repository को upload कर देता है” — यह बहुत चौंकाने वाला है
    Elon catch up करने के लिए ऐसा कर सकता है, इसका कुछ अंदाज़ा था, लेकिन यह गंभीर रूप से चिंताजनक है। इसकी price competitiveness है और grok-4.5 की performance भी काफी अच्छी है, लेकिन इसी वजह से मैंने इसे नहीं चुना

    • यह साफ़ data exfiltration है, और इसे illegal होना चाहिए
    • Microsoft के साथ partnership की वजह से क्या OpenAI को भी सभी GitHub repositories की access है, यह जानने की उत्सुकता है
    • आख़िरकार यह race to the bottom ही है
    • कौन-सा data share होगा, इस बारे में जानकारी नहीं मिली, इसलिए free trial तक लेने में हिचकिचाया
    • ऐसे CLI को मैं हमेशा access वाली directories सीमित करने वाले sandbox के अंदर चलाता हूँ
      CLI गलती से SSH keys या दूसरी sensitive जानकारी ले जा सकता है, और programmers ऐसी गलतियाँ सच में अक्सर करते हैं। “जो भी file accessible है, सब upload कर दो” यह जानबूझकर है या गलती, इस पर अपनी safety छोड़ना नहीं चाहता

  • पहली बात, “repository के अंदर की secrets file model ने पढ़ ली,” असल में लगभग intended behavior ही है
    LLM file पढ़ने से पहले यह तय नहीं कर सकता कि उसमें secrets हैं या नहीं। अगर आप plain-text secrets वाली file तक LLM को access देते हैं और फिर उसके पढ़ लेने पर हैरान होते हैं, तो मूल समस्या वहीं है
    लेकिन पूरे repository को अपने आप upload करना बेतुका है। अगर repository कई GB की हो तो कुछ connections पर इसमें बहुत लंबा समय लगेगा, और अगर सारा data इकट्ठा करने जैसा कोई दूसरा मकसद न हो तो यह आम तौर पर निरर्थक लगता है

  • मैं हमेशा मानकर चलता हूँ कि जिस current workspace में agent चलाया गया है, कम-से-कम उस पर agent का पूरा अधिकार है, इसलिए यह अपेक्षित behavior जैसा लगता है
    ज़्यादातर agents पहले prompt में code और उसके अंदर के secrets तक पढ़ लेते हैं। अगर server पर इसका इस्तेमाल करके prompt round-trip time और tool calls कम किए जाते हैं, तो क्या यह उल्टा user के लिए फ़ायदेमंद नहीं है?

    • file पढ़कर response भेजते समय सामान्य message API इस्तेमाल होती है
      लेकिन यहाँ project folder पूरे का पूरा GCP storage bucket में निकालने वाला एक अलग endpoint मिला। जिसने भी बड़े distributed systems design किए हैं, वह समझ जाएगा कि यह training data बटोरने वाली architecture है
    • मेरी जानकारी में Cursor local पर किसी तरह का indexing work करता है
      बिना सारी files upload किए भी search के ज़रिए सिर्फ relevant हिस्से ढूँढकर model के इस्तेमाल के लिए भेजे जा सकते हैं

  • अच्छा होता अगर overview किसी इंसान ने लिखा होता, लेकिन content खुद ही बेचैन करने वाला है

    • upload हो रही चीज़ें दिखाने वाले कुछ code blocks और 2–3 paragraphs ही काफी थे
      AI-written report पढ़ना इतना कष्टदायक है कि मैंने लगभग 10 सेकंड स्कैन किया और रुचि खो दी
    • कम-से-कम किसी इंसान ने LLM के साथ कुछ और rounds में polish करके style बेहतर की होती

  • सोच रहा हूँ कि चुराई गई चीज़ें “हर business को automate” करने वाले Macrohard project या “everything app” में जाएँगी क्या
    यह ऐसा लगता है जैसे सब कुछ खुद बनाने की ज़रूरत नहीं, बस चुरा लो

    • और मज़े की बात यह है कि users इस privilege के लिए पैसे भी देते हैं
      अगर आप बिना नैतिकता के ऐसी company चलाते हैं, तो scam का scale सामने आने और regulation के रोकने से पहले जितना हो सके उतना चुराने की कोशिश करेंगे। मेरा मतलब यह नहीं कि वे सचमुच ऐसा कर रहे हैं, लेकिन economic incentives ठीक उसी दिशा में aligned हैं

  • यह मानकर चलना चाहिए कि AI agent उस डायरेक्टरी की फ़ाइलें पढ़ सकता है जहाँ से runner शुरू हुआ है
    ज़्यादातर मामलों में वह पहले prompt में कोड और उसके भीतर के secret तक पढ़ लेता है, और .env केवल local environment के लिए है इसलिए उसमें असली secret नहीं रखने चाहिए। AI agent के निर्देशों पर भरोसा नहीं किया जा सकता, इसलिए उसे असली secret से अलग-थलग रखना चाहिए
    अगर इस आधार को स्वीकार करें, तो हर बार context में कोड भेजने के बजाय उसे server पर चढ़ाकर रखना बेहतर हो सकता है

    • LLM के काम करने के तरीके के अनुसार आखिरकार कोड को context के ज़रिए फिर से भेजना ही पड़ता है
      इसलिए अलग से upload करने की वजह बस यही लगती है कि Musk अगले model के लिए project structure, लोकप्रिय library, CI workflow जैसे साफ़ training data जुटाना चाहता है
    • एक बार upload करने पर भी यह inference प्रक्रिया में फिर भी शामिल रहता है, और बचत बस थोड़ी-सी HTTP traffic की होती है
    • बात का मूल मुद्दा बहुत बड़ा नहीं है। संभव है कि context बनाने में Grok दूसरे providers की तुलना में लगभग 10% ज़्यादा आक्रामक हो, या बस यह तरीका जल्दी ship किया जा सकता था
      अगर नतीजे बेहतर होते हों तो सभी providers के पास वही काम करने की क्षमता और प्रोत्साहन है
      असली फ़र्क यह है कि .env जैसी secret फ़ाइलों को छिपाए बिना भेजा जाता है, उन्हें सिर्फ़ अस्थायी रूप से process करने के बजाय नामित GCS bucket में store किया जाता है, और CLI settings documentation में upload के तरीके की जानकारी दिए बिना इसे default रूप से enabled रखा गया
      ऐसी किसी accessible path में unencrypted .env नहीं रखना चाहिए। बेहतर होता कि Grok secret पहचानकर उसे नज़रअंदाज़ कर दे, लेकिन users को ऐसे behavior पर निर्भर नहीं होना चाहिए

  • “Improve the model” setting चालू हो या बंद, पूरा repository एक जैसा upload होता है — यह बेहद गंभीर है
    ज़्यादातर AI कंपनियाँ भी अगर data collection की सहमति दी जाए तो अपने runner में ऐसा ही कुछ करेंगी, लेकिन साफ़ तौर पर बंद करने के बाद भी upload करना दुर्भावनापूर्ण है

  • पूरा codebase upload करने से model “सोचते” समय client से असली tool call माँगे बिना भी कोड देख सकता है
    client को फिर से request भेजने में क्या कमी है यह स्पष्ट नहीं, इसलिए यह बहुत मज़बूत वजह नहीं लगती, लेकिन सोची जा सकने वाली सबसे अच्छी दलील यही है

    • असली मकसद trade secrets, app design, और कंपनी के अंदरूनी कामकाज के ज्ञान को चुराने, या code·app·tool·process की नकल करने के क़रीब ज़्यादा लगता है
      जो code पहले निजी था, अब वह उनका code बन जाता है
    • यह इस काम के लिए भी हो सकता है कि कंप्यूटर offline होने पर भी कहीं किसी container के ज़रिए फ़ोन से remote control किया जाए, और बाद में local development पर लौटकर GCP bucket के बदलाव sync किए जाएँ
      यह काफ़ी उपयोगी है, लेकिन Elon को पूरा repository सौंप देने जितना उपयोगी नहीं। इसे अस्वीकार न कर पाने लायक बनाया गया और बिल्कुल बताया भी नहीं गया — यही बात इस निष्कर्ष को और मज़बूत करती है कि यह data उन्हें नहीं सौंपना चाहिए