xAI Grok Build CLI’ın xAI’a Gönderdiği Veriler: Kablo Düzeyinde Analiz

 (gist.github.com/cereblab)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • grok 0.2.93 ağ trafiğinin doğrudan yakalanması sonucunda, Grok Build’ün okuduğu dosyaları maskelemeden gönderdiği ve session_state olarak sakladığı; test amaçlı .env gizli değerlerinin de iki yola aynen dahil edildiği görüldü
  • Model isteğinin, ajanın okuduğu dosyaları göndermesinden ayrı olarak, tüm izleme dosyalarını ve Git geçmişini içeren deponun tamamı git bundle olarak yüklendi; açılmaması istenen dosya da ham haliyle geri çıkarılabildi
  • 12GB’lık rastgele dosya deposunda /v1/responses istekleri toplam 192KB iken /v1/storage aktarımı, yakalama durdurulana kadar 5.10GiB’ye ulaştı; yaklaşık 27.800 kat fark vardı ve tüm depolama istekleri HTTP 200 döndürdü
  • Yükleme hedefi Google Cloud Storage’daki grok-code-session-traces bucket’ı idi; “Improve the model” kapatılsa bile trace_upload_enabled: true ve upload_enabled: true korunuyor, tüm depo yüklemesi devam ediyordu
  • Deney, verilerin aktarımını, kabulünü ve saklanmasını kanıtlıyor ancak model eğitiminde kullanılıp kullanılmadığını doğrulayamıyor; .gitignore dosyaları ile tüm hesap ve ayar kombinasyonları da test edilmediğinden sonuçlar Temmuz 2026’daki belirli bir sürümle sınırlı

Test edilen hedef ve analiz kapsamı

  • Hedef, normal bir tüketici hesabıyla oturum açılmış xAI’ın resmi Grok Build CLI’ıydı
    • Kurulum yolu ~/.grok/bin/grok
    • Tarayıcıda X veya SuperGrok hesabıyla kimlik doğrulaması yapılıyor; API anahtarı kullanılmıyor
    • Test edilen ikili dosya Apple Silicon için grok 0.2.93 (f00f96316d4b)
    • SHA-256 değeri 2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c
  • İkili dosya dizgelerinde özel Rust yükleme bileşeni ve depoyla ilgili sabitler tespit edildi
    • 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
  • Tüm yakalamalar yalnızca testi yapan kişinin bilgisayarını ve trafiğini kapsadı; depoya gerçek kimlik bilgileri yerine benzersiz canary dizgeleri kondu

Yeniden üretme ve trafik yakalama yöntemi

  • macOS Apple Silicon’da mitmproxy CA’sı oturum açma keychain’ine güvenilir sertifika olarak eklendi; Grok’un HTTPS isteklerini yakalamak için HTTPS_PROXY ve SSL_CERT_FILE ayarlandı
  • Grok, bu yapılandırmada sertifika sabitleme (certificate pinning) ile yakalamayı engellemedi
  • mitmdump eklentisiyle her istek için yöntem, host, yol, yanıt durumu ve istek bayt boyutu kaydedildi; xAI host’larına giden istek gövdeleri saklandı
  • Çalışma sırasında ~/.grok/upload_queue/* kopyalandı ve gzip ile tar kullanılarak açılıp gönderim bekleyen staging artefaktları da incelendi
  • Her dosyaya kaynağın ayırt edilebilmesi için benzersiz bir işaretçi kondu; gizli dosyalarda aşağıdaki sahte değerler kullanıldı
    • API_KEY=CANARY7F3A9-SECRET-should-not-leave
    • DB_PASSWORD=CANARY7F3A9-DBPASS

Kanal A: Okunan dosyaların ve .env’nin model isteğinde gönderilmesi

  • Grok’un okuduğu dosya içerikleri, POST cli-chat-proxy.grok.com/v1/responses içindeki model turn gövdesine serileştirildi
    • Yakalanan 48.070 baytlık istekte "model":"grok-4.5" ve mesaj dizisi yer aldı
    • .env içindeki API_KEY ve DB_PASSWORD canary değerleri, satır sonları dahil ham haliyle bulundu
    • Kaynak, mantık, README, iç içe JavaScript dosyası ve iki gizli değeri içeren 6 işaretçi istek gövdesinden geri çıkarılabildi
  • Aynı içerik session_state arşivine de girdi ve POST /v1/storage ile yüklendi; ilgili depolama isteği HTTP 200 ile kabul edildi
    • Sıkıştırılmış arşiv açılıp incelendiğinde iki gizli değer ve diğer dosya işaretçilerinin tamamı bulundu
    • Gizli değerler yalnızca model tarafından geçici olarak işlenmekle kalmadı, depolama arşivine de kaydedildi
  • Reply exactly OK, do not read any files kontrol prompt’unda açılmayan untouched_secret.txt işaretçisi /v1/responses gövdesinde görünmedi
    • Bu, model isteği kanalının ajanın gerçekten okuduğu dosyalar etrafında kurulduğu kapsamını kanıtlıyor
    • Ayrı olan tüm depo snapshot kanalı okunmamış dosyaları da içerdiğinden, bu kontrol sonucu tüm depo yüklemesini çürütmez
  • Gizli değerler .env veya secrets.env içindeydi ve Git tarafından izlenen dosyalardı
    • .gitignore kapsamındaki dosyaların da yüklenip yüklenmediği ayrıca test edilmedi
    • Canary gerçek yüksek entropili token biçiminde olmadığından, sk-… gibi belirli biçimlere yönelik ayrı bir maskeleme mekanizmasının hiç bulunmadığı da kanıtlanmış sayılmaz
    • Doğrulanan kapsam, test edilen .env içeriğinin maskelenmeden gönderildiği

Kanal B: Okunmayan dosyalar dahil tüm depo yüklemesi

  • /v1/storage, modelin okuduğu dosyaları gönderen /v1/responses’tan bağımsız olarak tüm çalışma alanı snapshot’ını yükledi
  • Gerçek cereblab_api deposunda Reply with exactly: OK. Do not read or open any files. talimatı verilip çalıştırıldı
    • Grok, POST /v1/storage ile 152.102 baytlık git bundle gönderdi ve sunucu HTTP 200 döndürdü
    • Yakalanan uploaded_repo.bundle git clone ile klonlandığında, açılmaması belirtilen src/_probe/never_read_canary.txt geri çıkarıldı
    • Dosyanın içindeki CANARY-XR47P2-NEVERREAD-UNIQUE işaretçisi de ham haliyle duruyordu
    • Bundle’da 4 commit, 47 dosya ve tüm Git geçmişi vardı
  • İkinci bağımsız depo cereblab_auth üzerinde de aynı sonuç yeniden üretildi
    • POST /v1/storage ile 31.743 baytlık git bundle yüklendi ve HTTP 200 döndürdü
    • Geri yüklenen depoda okunmamış dosyanın CANARY-AUTH-4T8K2-NEVERREAD işaretçisi aynen doğrulandı
  • Ayrı bir 298 dosyalık cereblab_api çalıştırmasında, staging’e alınmış manifest okunmayan dosyaları da listeledi
    • src/_probe/never_read_canary.txt ile src/apns.ts, src/index.ts gibi gerçek kaynak dosyalar birlikte kaydedildi
    • metadata.json içindeki dosya bazlı fileId, gs://grok-code-session-traces/repo_changes_dedup/v2/supplemental/sha256_… biçimindeydi
    • Bu çalıştırma kota nedeniyle içerik blob aktarımını tamamlayamadı; ancak ayrı git bundle deneyi ve 12GB deneyi gerçek yüklemeyi doğruladı
  • İkili dosyada after_codebase.tar.gz, repo_state.upload, collecting workspace files, spawning background coordinator gibi dizgeler de vardı ve bunlar çalışma alanı toplama mekanizmasıyla uyumluydu

12GB depoda doğrulanan çoklu GiB aktarım

  • Sıkıştırılması neredeyse mümkün olmayan rastgele dosyalarla depo boyutu artırılırken yükleme davranışı gözlendi
    • 64MB’de yaklaşık 48MB boyutunda tek bir POST /v1/storage HTTP 200 döndürdü ancak log korunamadı
    • Yaklaşık 600MB’de yaklaşık 7,5MB’lık onlarca parça HTTP 200 döndürdü fakat log kalmadı
    • Yaklaşık 3GB’de multipart başlatma sonrası storage.googleapis.com’a 50MB’lık PUT’lar gözlendi; ancak doğrudan PUT logları korunamadı
    • Yaklaşık 12GB’de yaklaşık 75MB’lık parçalar /v1/storage’a sürekli gönderildi ve 5.10GiB noktasında yakalama durduruldu
  • Korunan wire_12gb.log içinde /v1/storage* için toplam 83 HTTP 200 yanıtı var
    • İçerik yüklemesi POST /v1/storage: 82 adet
    • Bunların içinde yaklaşık 75MB’lık 73 parça
    • 73 parçanın toplamı 5,476,083,317B, yani 5.10GiB veya 5.48GB
    • 9 küçük POST ve 1 adet /v1/storage/batch_exists yinelenen kontrolü de dahil
    • Tüm /v1/storage* istek baytı 5,476,228,005B; başarısız depolama isteği yok
  • Yakalama yükleme devam ederken durdurulduğu için 12GB’ın tamamının yüklendiği kanıtlanmıyor
    • Son kayıt da yaklaşık 75MB’lık bir parça için HTTP 200 idi
    • Kanıtlanan kapsam, 5.10GiB’den fazlasının hatasız aktarıldığı ve durdurma anında artmaya devam ettiğidir
  • Aynı oturumdaki iki kanal arasında büyük bir hacim farkı vardı
    • /v1/responses, 5 istek toplamında 196,705B, yaklaşık 192KB idi; en büyük istek de 60.394B idi
    • /v1/storage 5.10GiB idi
    • Yaklaşık 27.800 kat fark oluştu; model isteğine dahil olmayan büyük miktarda depo verisi ayrı bir depolama kanalına taşındı
  • Model kota hataları ile depolama yüklemesi bağımsız olarak gerçekleşti
    • /v1/responses’ta 1 kez HTTP 402, 3 kez 429 oluştu
    • Oturum bookkeeping isteklerinde ilgisiz 1 adet 404 oluştu
    • İlk 429’dan sonra da /v1/storage için 76 adet HTTP 200 devam etti
    • 82 depolama isteğinin tamamı başarılı oldu ve test kapsamı içinde depolama kapasitesi sınırı hatası oluşmadı
  • Bu sonuç, yerel upload_queue’nun boşalması olgusuna dayanmaz
    • Kuyruk hem başarılı yükleme hem de atma durumunda boşalabileceğinden kanıt olarak kullanılmadı
    • Dayanak, istek gövdelerinin gerçekten ağ üzerinden çıkıp HTTP 200 aldığı yakalama ve yüklenen git bundle’dan dosyaların geri çıkarılmasıdır

Depolama konumu ve telemetri

  • Depolama hedefinin AWS S3 değil, Google Cloud Storage’daki grok-code-session-traces bucket’ı olduğu doğrulandı
    • İkili dosyada grok-code-session-traces, storage.googleapis.com, Uploading bytes to GCS via proxy yer aldı
    • Korunan metadata.json içinde dosya hedefi gs://grok-code-session-traces/… olarak kaydedilmişti
    • Yaklaşık 3GB deneyinde ilgili GCS host’una doğrudan multipart PUT da gözlendi; ancak log korunamadı
    • İkili dosyada aws-sdk-s3 bulunsa da testte doğrulanan hedef GCS idi
  • Üçüncü taraf ve kendi telemetri istekleri de doğrulandı
    • Mixpanel api.mixpanel.com/track ve /engage
    • grok.com/_data/v1/events
    • Bu isteklerin tamamı HTTP 200 döndürdü
  • İncelenen CLI kurulum betiği ve quickstart materyallerinde repo_state, session_state, ~/.grok/upload_queue, grok-code-session-traces yüklemesi bulunamadı
    • Tüm xAI belgeleri ve yardım içerikleri araştırılmadığından hiçbir yerde belgelenmediği kesin olarak söylenemez
    • Doğrulanabilir kapsam, CLI’ın kendi ayar materyallerinde görünmediğidir
  • ~/.grok/upload_queue tek bir turn’de yaklaşık 3GB’lık snapshot’ı staging’e alabiliyor; yük yüksek olduğunda onlarca GB’a büyüyerek diski tüketebiliyordu
    • Bu, yüklemenin mahremiyet sorunundan ayrı bir güvenilirlik sorunu

“Improve the model” ayarı ve politika kapsamı

  • Bir bulut kodlama ajanının iş için gereken kod bağlamını sunucuya göndermesi kendi başına gerekli bir davranıştır
  • Testte doğrulanan davranış şu üç başlığa ayrılıyor
    • .env gibi gizli dosyaları maskelemeden gönderiyor
    • Bu içeriği belirtilen GCS bucket’ında saklıyor
    • Tüm depo yüklemesi, incelenen CLI ayar materyallerinde görünmeden varsayılan olarak etkin
  • xAI tüketici politikası model iyileştirme için veri kullanımı ve opt-out’u geniş biçimde ele alıyor; Private Chat otomatik opt-out ve opt-out geriye dönük uygulanmıyor
    • İlgili belgeler xAI Privacy Policy ve Consumer ToS
    • Bu genel eğitim politikaları, belirli repo_state ve GCS yükleme pipeline’ını belgeleme ile aynı şey değil

  • “Improve the model” kapatılsa da yükleme durmuyor

    • Ayar kapalıyken bile deponun tamamı git bundle olarak /v1/storage’a yüklendi ve HTTP 200 döndürdü
    • git clone ile okunmamış dosyalar ve Git geçmişi geri çıkarılabildi
    • CLI’ın aldığı /v1/settings içinde "trace_upload_enabled": true, "upload_enabled": true, "session_registry_enabled": true korunuyordu
    • "max_upload_file_bytes": 1073741824 ile dosya başına 1GiB sınırı da döndü
    • Test sonuçlarında opt-out eğitimde kullanılıp kullanılmayacağını kontrol ediyor, ancak deponun bilgisayardan çıkıp yüklenmesini ve saklanmasını engellemiyordu

Kanıtlanmayan noktalar ve kanıtların sınırları

  • Yalnızca ağ yakalamasıyla xAI’ın verileri model eğitiminde kullandığı kanıtlanamaz
    • Doğrulanan kapsam aktarım, HTTP 200 kabulü, depolama arşivi ve GCS hedefidir
  • 3GB çalıştırmasında gözlenen storage.googleapis.com/grok-code-session-traces doğrudan PUT logu üzerine yazıldığı için korunamadı
    • Çoklu GiB yüklemenin dayanağı, korunan 12GB çalıştırmasındaki /v1/storage logları ile bucket’ı açıkça belirten ikili dosya ve metadata’dır
  • Boyut bazlı testlerde 64MB, 600MB ve 3GB logları kalmadı; yalnızca 12GB logu korundu
  • 12GB çalıştırması yaklaşık 5.10GiB’de durdurulduğu için 12GB’ın tamamının sonuna kadar yükleneceği kesin olarak söylenemez
  • Tüm hesap kademeleri ve yapılandırma kombinasyonları test edilmedi
    • Ücretsiz kademede çoklu GiB yükleme başarılı oldu
    • SuperGrok’ta “Improve the model” kapalıyken de git bundle yüklemesi başarılı oldu
    • Testte yüklemeyi kapatan bir ayar bulunamadı; ancak hiçbir ortamda kesinlikle devre dışı bırakılamayacağı iddia edilmiyor
  • Başta PID bazlı nettop sonucuna dayanarak büyük blob’un yüklenmediği yanlış değerlendirilmiş, sonra bu geri çekilmiştir
    • Ayrı yükleme koordinasyon süreci ve Google IP’lerine doğrudan giden önceden imzalanmış PUT’lar, API host’u veya tek PID bazlı ölçüme takılmayabiliyordu
    • Sonraki proxy kablo yakalaması ilk değerlendirmenin yerini aldı
  • Sonuçlar grok 0.2.93, macOS Apple Silicon ve Temmuz 2026 ortamıyla sınırlıdır; xAI daha sonra davranışı değiştirebilir

Korunan başlıca kanıtlar

  • secrets_responses_body.bin: .env ham içeriğinin /v1/responses gövdesine dahil edildiğini gösterir
  • secrets_session_state.tar.gz: aynı gizli değerlerin /v1/storage için arşive girdiğini gösterir
  • wire_12gb.log: 5.10GiB depolama yüklemesini, 83 adet /v1/storage* HTTP 200’ü, 0 depolama başarısızlığını ve iki kanal arasındaki yaklaşık 27.800 kat hacim farkını kaydeder
  • model_limit.txt: model isteğinde oluşan 1 adet 402 ve 3 adet 429’u kaydeder
  • crate_strings.txt: xai-data-collector, grok-code-session-traces, storage.googleapis.com dizgelerini korur
  • uploaded_repo.bundle: yüklenen git bundle’dan okunmamış dosyaların ve tüm Git geçmişinin geri çıkarıldığı ilk depo kanıtıdır
  • uploaded_repo_auth.bundle: ikinci bağımsız depoda aynı sonucun yeniden üretildiğinin kanıtıdır
  • staged_base_tree_manifest.json: okunmamış dosyaların depo snapshot manifest’inde listelendiğini gösterir
  • staged_metadata.json: dosya hedefinin gs://grok-code-session-traces/… olduğunu gösterir
  • gcs_puts.txt, doğrudan GCS PUT’u koruyamadığı için boş bir placeholder’dır ve ilgili PUT’un korunmuş kanıtı olarak kullanılamaz

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News yorumları

  • Kodlama araçları ile LLM sağlayıcılarını her zaman ayırıyor, kodlama araçlarının yetkilerini bubblewrap sandbox ile kısıtlıyorum
    Araç yalnızca üzerinde çalışılan proje dizinini okuyabiliyor, .git salt okunur; hassas dizinler ise boş dizinler olarak mount ediliyor
    Ağ namespace'i de yalıtılıyor; internete yalnızca Unix socket üzerindeki HTTP proxy üzerinden eriştiriliyor ve yalnızca belirli LLM sağlayıcı host'larına izin verilirken aracın kendi host'ları engelleniyor
    Örneğin Crush için *.openrouter.ai erişimine izin veriyorum, ancak LLM listesinin otomatik güncellenmesinde kullanılan *.charm.land engelleniyor. Bu sayede tüm işleri yolo modu ile devretmek çok daha rahat hale geliyor

    • bubblewrap'ta Docker Hub'daki debian:unstable gibi bir rootfs alıp ayrı bir klasörde tam bir dağıtım ortamı olarak kurmak daha iyi
      Bunun içine yapay zeka ajanını kurduktan sonra dağıtım rootfs'ini salt okunur, özel /home/user dizinini ise okuma-yazma olarak belirleyip bwrap çalıştıran bir script yazmak yeterli. Belirlediğiniz dizinlerin dışındaki önemli dosyalar görünmez ve birden fazla ajanı birbirini görmeyecek şekilde de çalıştırabilirsiniz
      Daha da güçlendirmek için içeriden gVisor'ın runsc ... do ... komutunu çağırabilir veya muvm gibi bir sanal makine monitörü kullanabilirsiniz. bwrap, ortam kurulumunu üstlenip ayrı bir sandbox aracıyla kilitleme yaklaşımı olduğu için güvenilir
      Yapılandırma doğruysa, bwrap tek başına saldırganların çoğunu durdurmak için yeterlidir; yetki yükseltmek için fiilen Linux çekirdeği zero-day kullanmaları gerekme olasılığı yüksektir
    • Bunu uygularken nasıl bir yöntem kullandığınızı merak ediyorum
    • Bu ek güvenlik sertleştirmesinin yalnızca iç rahatlığı sağlamaktan ibaret mi olduğunu, yoksa gerçekten tehlikeli davranışları yakaladığı oldu mu merak ediyorum
      Kısıtlamalarla engellenmesi gerekecek kadar aptalca davranan bir modelin baştan kullanılmaya değmeyeceğini düşünüyorum. Ben de kendi ortamımı sertleştiriyorum; bu pratiğin kendisini eleştirmek istemiyorum

  • claude-code, Codex, grok-build gibi kapalı kaynak yerel kodlama ajanı çalıştırıcıları, bir sonraki güncellemede hangi gizli özelliklerin ekleneceği bilinmediği için gizlilik açısından riskli
    opencode üzerinden API ile model kullanmak çok daha güvenli, ancak yerel çalıştırıcılar kadar iyi performans almak zor olabiliyor; ödünleşim bu

    • Kullanım yeterince fazlaysa, yalnızca sunucu tarafı araç çağrılarıyla bile tüm kod tabanını yeniden oluşturmak mümkün olabilir ve bu süreci tamamen tespit etmek zordur
      Grok'un yöntemi sadece daha açık seçik; opencode da pratikte gerçek bir güvenlik sınırı oluşturmuyor, bu da Cheetos'u kilit olarak kullanma meme'ine benziyor
    • Codex açık kaynak
    • Otomatik güncelleme de başlı başına büyük bir sorun
      Windows XP SP1'deki uzaktan kod çalıştırma açığı gibi şeyleri hemen yamamamak da riskli; ancak son birkaç on yılda güncelleme yapmamaktan kaynaklanabilecek zararlardan çok, otomatik güncellemelerin yol açtığı zararları daha fazla gördüm
    • Kendi ajanımı kullanıyorum, ama bunun yüzünden şirket hesabımın engellenmesi riskini göze alamam

  • “Ajanın okuduğu dosyalarla ilgisi olmaksızın, izlenen tüm dosyaların içerikleri ve Git geçmişi dahil deponun tamamını yüklemesi” son derece şoke edici
    Elon'ın yetişmek için böyle şeyler yapabileceğini bir ölçüde tahmin ediyordum ama bu ciddi şekilde endişe verici. Fiyat açısından rekabetçi ve grok-4.5'in performansı da yeterince iyi, fakat tam da bu nedenle onu seçmedim

    • Bu açıkça veri sızıntısı ve yasa dışı olmalı
    • Microsoft ile işbirliği nedeniyle OpenAI'ın de tüm GitHub depolarına erişip erişemediğini merak ediyorum
    • Nihayetinde bu dibe doğru yarış
    • Hangi verilerin paylaşılması gerektiğine dair bilgi bulamadığım için ücretsiz denemeye bile tereddüt ettim
    • Bu tür CLI'ları her zaman erişebilecekleri dizinleri sınırlayan bir sandbox içinde çalıştırıyorum
      CLI yanlışlıkla SSH anahtarlarını veya başka hassas bilgileri alabilir; programcılar da gerçekten bu hataları sık sık yapar. “Erişilebilen tüm dosyaları yükleme” davranışının kasıt mı hata mı olduğuna güvenliğimi emanet etmek istemem

  • İlk madde olan “depo içindeki gizli bilgi dosyasını modelin okuması” aslında amaçlanan davranış
    LLM, bir dosyayı okumadan önce içinde gizli bilgi olup olmadığını bilemez. Düz metin gizli bilgiler içeren bir dosyaya LLM erişimi verip sonra okudu diye şaşırmak asıl temel sorun
    Ancak tüm depoyu otomatik olarak yüklemek saçmalık. Depo birkaç GB boyutundaysa bazı bağlantılarda çok uzun sürer ve tüm verileri toplamak gibi başka bir amaç yoksa genellikle anlamsız görünür

  • Ajanı çalıştırdığım mevcut çalışma alanının, en azından ajan tarafından serbestçe kullanılabileceğini her zaman varsaydığım için bu beklenen bir davranış gibi görünüyor
    Çoğu ajan ilk prompt'ta kodu ve içindeki gizli bilgileri okur. Sunucu bunu kullanarak prompt gidiş-dönüş süresini ve araç çağrılarını azaltıyorsa, bunun kullanıcıya faydası bile olabilir mi diye merak ediyorum

    • Dosyaları okuyup yanıtı iletirken normal mesaj API'si kullanılır
      Ancak burada proje klasörünün tamamını GCP depolama bucket'ına dışarı aktaran ayrı bir endpoint bulunmuş. Büyük ölçekli dağıtık sistemler tasarlamış biri bunun eğitim verisi toplamak için kurulmuş bir yapı olduğunu anlar
    • Cursor'ın yerelde bir tür indeksleme yaptığını biliyorum
      Tüm dosyaları yüklemeden de arama yoluyla ilgili kısımları bulup modelin kullanabilmesi için göndermek mümkün

  • Özeti bir insan yazmış olsaydı iyi olurdu, ama içeriğin kendisi tedirgin edici

    • Yüklenenleri gösteren birkaç kod bloğu ve 2-3 paragraf bu yazı için yeterli olurdu
      Yapay zekanın yazdığı raporu okumak o kadar zahmetliydi ki yaklaşık 10 saniye göz gezdirip ilgimi kaybettim
    • En azından bir insan LLM ile birkaç tur daha çalışıp üslubu iyileştirebilirdi

  • Çalınan içeriğin “tüm işletmeleri otomatikleştirecek” Macrohard projesine ya da “everything app”e girip girmeyeceğini merak ediyorum
    Her şeyi kendin yapmak zorunda değilsin, çalman yeterli gibi bir fikir gibi görünüyor

    • Kullanıcıların bu ayrıcalık için üstüne para ödemesi işin tuzu biberi
      Ahlaki sınırları olmadan böyle bir şirket işletiyorsanız, dolandırıcılığın ölçeği ortaya çıkıp düzenleyiciler engellemeden önce mümkün olduğunca çok şey çalmaya çalışırsınız. Gerçekten bunu yaptıkları anlamına gelmiyor, ancak ekonomik teşvikler tam olarak o yöne hizalanmış durumda

  • Yapay zeka ajanının, çalıştırıcının başlatıldığı dizindeki dosyaları okuyabildiği varsayılmalı
    Çoğu, ilk prompt’ta kodu ve içindeki gizli bilgileri bile okur; .env yerel ortam içindir, gerçek gizli bilgileri barındırmamalıdır. Yapay zeka ajanının talimatlarına güvenilemeyeceği için gerçek gizli bilgilerden izole edilmesi gerekir
    Bu varsayımı kabul edersek, kodu her seferinde bağlam olarak göndermektense sunucuya yükleyip orada tutmak daha iyi olabilir

    • LLM’lerin çalışma biçimi gereği kod eninde sonunda bağlam üzerinden yeniden aktarılmak zorundadır
      Böyle ayrı bir yüklemenin tek nedeni bence Musk’ın bir sonraki model için proje yapısı, popüler kütüphaneler, CI iş akışları gibi temiz eğitim verileri elde etmek istemesi
    • Bir kez yüklenmiş olsa bile çıkarım sürecine hâlâ girer; tasarruf edilen şey olsa olsa biraz HTTP trafiğidir
    • Hikâyenin özü çok büyük değil. Grok’un bağlam oluşturma konusunda diğer sağlayıcılardan yaklaşık %10 daha agresif olması ya da bu yöntemin basitçe daha hızlı piyasaya sürülebilmiş olması muhtemel
      Sonuçları iyileştirmeye yardımcı olacaksa tüm sağlayıcıların aynı şeyi yapma kapasitesi ve teşviki var
      Asıl fark, .env gibi gizli bilgi dosyalarını filtrelemeden göndermesi, bunları yalnızca geçici olarak işlemekle kalmayıp adı belirlenmiş bir GCS bucket’ında saklaması ve CLI yapılandırma belgelerinde yükleme yöntemini belirtmeden varsayılan olarak etkinleştirmiş olması
      Erişilebilir bir yolda şifrelenmemiş .env bulundurmamak gerekir. Grok’un gizli bilgileri tespit edip yok sayması daha iyi olurdu, ancak kullanıcılar böyle bir davranışa güvenmemeli

  • “Improve the model” ayarını açsanız da kapatsanız da tüm deponun aynı şekilde yüklenmesi çok ciddi bir sorun
    Çoğu yapay zeka şirketi de veri toplamaya onay verirseniz kendi çalıştırıcısında benzer şeyler yapacaktır; ancak açıkça kapatıldığı hâlde yükleme yapması kötü niyetlidir

  • Tüm kod tabanını yüklemek, modelin “düşünürken” istemciden gerçek araç çağrıları istemeden kodu inceleyebilmesini sağlar
    İstemciye yeniden istek göndermenin dezavantajının ne olduğu belirsiz olduğu için bu çok iyi bir gerekçe değil, ama akla gelen en iyi savunma bu

    • Gerçek amaç daha çok ticari sırları, uygulama tasarımını, şirket içi iş bilgisini çalmak ya da kodu, uygulamayı, araçları ve prosedürleri kopyalamak gibi görünüyor
      Başta özel olan kod artık onların kodu oluyor
    • Bilgisayar çevrimdışı olsa bile bir yerlerdeki konteyner üzerinden telefondan uzaktan kontrol etmek ve daha sonra yerel geliştirmeye dönüp GCP bucket’ındaki değişiklikleri senkronize etmek için kullanılıyor olabilir
      Oldukça kullanışlı, ama tüm depoyu Elon’a teslim edecek kadar değil. Bunu reddedilemez hâle getirmiş olmaları ve hiç açıklamamış olmaları, bu verilerin onlara emanet edilmemesi gerektiği kanaatini daha da güçlendiriyor