Dữ liệu mà xAI Grok Build CLI gửi về xAI: phân tích ở cấp độ đường truyền

 (gist.github.com/cereblab)
1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Kết quả tự capture lưu lượng mạng của grok 0.2.93 cho thấy Grok Build đã gửi các tệp đã đọc mà không che giấu, lưu chúng dưới dạng session_state, và cả các giá trị bí mật trong .env dùng để thử nghiệm cũng được đưa nguyên dạng vào cả hai đường dẫn
  • Tách biệt với việc yêu cầu mô hình gửi các tệp mà agent đã đọc, toàn bộ repository chứa mọi tệp trace và lịch sử Git đã được upload dưới dạng git bundle; ngay cả tệp được chỉ định là không được mở cũng được khôi phục nguyên văn
  • Trong repository gồm các tệp ngẫu nhiên 12GB, tổng dung lượng yêu cầu /v1/responses là 192KB, nhưng lượng truyền qua /v1/storage đạt 5.10GiB tại thời điểm dừng capture, chênh khoảng 27.800 lần; mọi yêu cầu lưu trữ đều trả về HTTP 200
  • Đích upload là bucket grok-code-session-traces trên Google Cloud Storage; ngay cả khi tắt “Improve the model”, trace_upload_enabled: true và upload_enabled: true vẫn được giữ nguyên, và việc upload toàn bộ repository vẫn tiếp tục
  • Thử nghiệm chứng minh việc truyền, chấp nhận và lưu trữ dữ liệu, nhưng không xác nhận được liệu dữ liệu có được dùng để huấn luyện mô hình hay không; các tệp .gitignore và mọi tổ hợp tài khoản/cấu hình cũng chưa được thử nghiệm, nên kết quả chỉ giới hạn ở một phiên bản cụ thể vào tháng 7 năm 2026

Đối tượng thử nghiệm và phạm vi phân tích

  • Đối tượng là Grok Build CLI chính thức của xAI, đăng nhập bằng tài khoản người dùng phổ thông
    • Đường dẫn cài đặt là ~/.grok/bin/grok
    • Xác thực bằng tài khoản X hoặc SuperGrok trong trình duyệt, không dùng API key
    • Binary thử nghiệm là grok 0.2.93 (f00f96316d4b) cho Apple Silicon
    • SHA-256 là 2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c
  • Từ chuỗi trong binary đã xác nhận có thành phần upload Rust riêng và các hằng số liên quan đến lưu trữ
    • 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
  • Mọi capture chỉ nhắm vào máy tính và lưu lượng của người thực hiện thử nghiệm; repository chứa chuỗi canary duy nhất thay cho thông tin xác thực thật

Cách tái hiện và capture lưu lượng

  • Trên macOS Apple Silicon, thêm CA của mitmproxy vào login keychain dưới dạng chứng chỉ tin cậy, rồi đặt HTTPS_PROXY và SSL_CERT_FILE để capture các yêu cầu HTTPS của Grok
  • Với cấu hình này, Grok không chặn capture bằng certificate pinning
  • Dùng addon mitmdump để ghi lại method, host, path, trạng thái phản hồi và kích thước byte của yêu cầu theo từng request, đồng thời lưu body của các request hướng tới host xAI
  • Sao chép ~/.grok/upload_queue/* khi chương trình đang chạy, rồi giải nén bằng gzip và tar để kiểm tra cả artifact staging đang chờ truyền
  • Mỗi tệp được chèn marker duy nhất để phân biệt nguồn gốc; tệp bí mật dùng các giá trị giả sau
    • API_KEY=CANARY7F3A9-SECRET-should-not-leave
    • DB_PASSWORD=CANARY7F3A9-DBPASS

Kênh A: truyền tệp đã đọc và .env trong yêu cầu mô hình

  • Nội dung tệp mà Grok đã đọc được serialize vào body lượt mô hình của POST cli-chat-proxy.grok.com/v1/responses
    • Request 48.070 byte được capture chứa "model":"grok-4.5" và mảng message
    • Canary API_KEY và DB_PASSWORD trong .env được tìm thấy nguyên dạng, gồm cả xuống dòng
    • Có thể khôi phục 6 marker trong body request, bao gồm source, logic, README, tệp JavaScript lồng nhau và hai giá trị bí mật
  • Cùng nội dung đó cũng được đưa vào archive session_state và upload bằng POST /v1/storage; yêu cầu lưu trữ này được chấp nhận với HTTP 200
    • Khi giải nén archive nén để kiểm tra, cả hai giá trị bí mật và các marker tệp khác đều được tìm thấy
    • Giá trị bí mật không chỉ được mô hình xử lý tạm thời mà còn được ghi vào archive dùng để lưu trữ
  • Với prompt đối chứng Reply exactly OK, do not read any files, marker của untouched_secret.txt chưa được mở không xuất hiện trong body /v1/responses
    • Điều này chỉ chứng minh phạm vi rằng kênh yêu cầu mô hình chủ yếu được cấu thành từ các tệp mà agent thực sự đã đọc
    • Vì kênh snapshot toàn bộ repository riêng biệt vẫn bao gồm cả tệp chưa đọc, kết quả đối chứng này không phủ nhận việc upload toàn bộ repository
  • Giá trị bí mật nằm trong .env hoặc secrets.env, và là các tệp được Git theo dõi
    • Chưa thử riêng việc các tệp nằm trong .gitignore có bị upload hay không
    • Canary không phải token entropy cao thực tế, nên không chứng minh được rằng hoàn toàn không có cơ chế che giấu riêng cho các dạng cụ thể như sk-…
    • Phạm vi đã xác nhận là nội dung .env được thử nghiệm đã được truyền đi mà không bị che giấu

Kênh B: upload toàn bộ repository, bao gồm cả tệp chưa đọc

  • /v1/storage đã upload snapshot toàn bộ workspace tách biệt với /v1/responses, vốn gửi các tệp mô hình đã đọc
  • Thử chạy trong repository cereblab_api thực tế sau khi chỉ thị Reply with exactly: OK. Do not read or open any files.
    • Grok gửi git bundle 152.102 byte qua POST /v1/storage và máy chủ trả về HTTP 200
    • Khi git clone tệp uploaded_repo.bundle đã capture, tệp src/_probe/never_read_canary.txt vốn được chỉ định không được mở đã được khôi phục
    • Marker CANARY-XR47P2-NEVERREAD-UNIQUE trong tệp cũng còn nguyên văn
    • Bundle chứa 4 commit, 47 tệp và toàn bộ lịch sử Git
  • Kết quả tương tự được tái hiện ở repository độc lập thứ hai cereblab_auth
    • Git bundle 31.743 byte được upload qua POST /v1/storage và trả về HTTP 200
    • Trong repository được khôi phục, marker CANARY-AUTH-4T8K2-NEVERREAD của tệp chưa đọc vẫn được xác nhận nguyên vẹn
  • Trong một lần chạy riêng với cereblab_api quy mô 298 tệp, manifest được staging liệt kê cả những tệp chưa đọc
    • src/_probe/never_read_canary.txt được ghi cùng với source thực như src/apns.ts và src/index.ts
    • fileId theo từng tệp trong metadata.json có dạng gs://grok-code-session-traces/repo_changes_dedup/v2/supplemental/sha256_…
    • Lần chạy này bị chặn bởi quota nên chưa hoàn tất truyền content blob, nhưng các thử nghiệm git bundle riêng và thử nghiệm 12GB đã xác nhận upload thực tế
  • Binary cũng chứa các chuỗi như after_codebase.tar.gz, repo_state.upload, collecting workspace files, spawning background coordinator, khớp với cơ chế thu thập workspace

Truyền nhiều GiB xác nhận trong repository 12GB

  • Quan sát hành vi upload bằng cách tăng kích thước repository với các tệp ngẫu nhiên hầu như không nén được
    • Ở 64MB, một POST /v1/storage đơn lẻ khoảng 48MB trả về HTTP 200 nhưng log không được giữ lại
    • Ở khoảng 600MB, hàng chục chunk khoảng 7,5MB đều trả về HTTP 200 nhưng không còn log
    • Ở khoảng 3GB, sau khi khởi tạo multipart, quan sát thấy các PUT 50MB tới storage.googleapis.com, nhưng log PUT trực tiếp không được giữ lại
    • Ở khoảng 12GB, các chunk khoảng 75MB tiếp tục được gửi tới /v1/storage, và capture bị dừng ở mốc 5.10GiB
  • wire_12gb.log được giữ lại có tổng cộng 83 phản hồi HTTP 200 cho /v1/storage*
    • 82 request POST /v1/storage upload nội dung
    • Trong đó có 73 chunk khoảng 75MB
    • Tổng của 73 chunk là 5,476,083,317B, tức 5.10GiB hoặc 5.48GB
    • Bao gồm thêm 9 POST nhỏ và 1 lần kiểm tra trùng lặp /v1/storage/batch_exists
    • Tổng byte của các request /v1/storage* là 5,476,228,005B, không có yêu cầu lưu trữ nào thất bại
  • Vì capture bị dừng khi upload vẫn đang tiếp diễn, điều này không chứng minh toàn bộ 12GB đã upload xong
    • Bản ghi cuối cùng cũng là HTTP 200 cho một chunk khoảng 75MB
    • Phạm vi được chứng minh là hơn 5.10GiB đã được truyền không lỗi và vẫn đang tăng tại thời điểm dừng
  • Có chênh lệch dung lượng lớn giữa hai kênh trong cùng phiên
    • /v1/responses gồm 5 request cộng lại là 196,705B, khoảng 192KB; request lớn nhất cũng chỉ 60.394B
    • /v1/storage là 5.10GiB
    • Chênh khoảng 27.800 lần, cho thấy một lượng lớn dữ liệu repository không nằm trong yêu cầu mô hình đã được chuyển qua kênh lưu trữ riêng
  • Lỗi quota mô hình và upload lưu trữ xảy ra độc lập
    • /v1/responses phát sinh HTTP 402 một lần và 429 ba lần
    • Một request bookkeeping phiên có lỗi 404 không liên quan
    • Sau lỗi 429 đầu tiên, /v1/storage vẫn tiếp tục có 76 phản hồi HTTP 200
    • Cả 82 request lưu trữ đều thành công, và trong phạm vi thử nghiệm không xảy ra lỗi giới hạn dung lượng lưu trữ
  • Kết quả này không phụ thuộc vào hiện tượng hàng đợi upload_queue cục bộ bị làm trống
    • Hàng đợi có thể bị làm trống cả khi upload thành công lẫn khi bị loại bỏ, nên không được dùng làm bằng chứng
    • Căn cứ là capture body request thực sự đi ra mạng và nhận HTTP 200, cùng với kết quả khôi phục tệp từ git bundle đã upload

Vị trí lưu trữ và telemetry

  • Đích lưu trữ được xác nhận không phải AWS S3 mà là bucket grok-code-session-traces trên Google Cloud Storage
    • Binary chứa grok-code-session-traces, storage.googleapis.com, Uploading bytes to GCS via proxy
    • Đích tệp trong metadata.json được giữ lại ghi là gs://grok-code-session-traces/…
    • Trong thử nghiệm khoảng 3GB, cũng quan sát thấy multipart PUT trực tiếp tới host GCS đó nhưng log không được giữ lại
    • Dù binary có chứa aws-sdk-s3, đích được xác nhận trong thử nghiệm là GCS
  • Cũng xác nhận có request telemetry của bên thứ ba và của chính dịch vụ
    • api.mixpanel.com/track và /engage của Mixpanel
    • grok.com/_data/v1/events
    • Các request này đều trả về HTTP 200
  • Trong script cài đặt CLI và tài liệu quickstart đã xem xét, không tìm thấy việc upload repo_state, session_state, ~/.grok/upload_queue, grok-code-session-traces
    • Chưa khảo sát toàn bộ tài liệu và trợ giúp của xAI, nên không thể kết luận là không được ghi tài liệu ở đâu cả
    • Phạm vi có thể xác nhận là không được thể hiện trong tài liệu cấu hình của chính CLI
  • ~/.grok/upload_queue có thể staging snapshot khoảng 3GB trong một lượt và có thể tăng tới hàng chục GB khi tải cao, làm cạn dung lượng đĩa
    • Đây là vấn đề độ tin cậy tách biệt với vấn đề quyền riêng tư của upload

Thiết lập “Improve the model” và phạm vi chính sách

  • Bản thân việc cloud coding agent gửi ngữ cảnh mã cần thiết cho tác vụ lên máy chủ là hành vi cần thiết
  • Hành vi được xác nhận trong thử nghiệm được chia thành ba điểm sau
    • Truyền các tệp bí mật như .env mà không che giấu
    • Lưu nội dung đó vào bucket GCS đã nêu
    • Upload toàn bộ repository được bật mặc định mà không được thể hiện trong tài liệu cấu hình CLI đã xem xét
  • Chính sách dành cho người dùng của xAI đề cập rộng đến việc sử dụng dữ liệu để cải thiện mô hình và opt-out; Private Chat tự động opt-out, và opt-out không có hiệu lực hồi tố
    • Tài liệu liên quan là xAI Privacy Policy và Consumer ToS
    • Các chính sách huấn luyện chung như vậy không tương đương với việc ghi tài liệu pipeline upload repo_state và GCS cụ thể

  • Tắt “Improve the model” không dừng upload

    • Ngay cả khi tắt thiết lập này, toàn bộ repository vẫn được upload lên /v1/storage dưới dạng git bundle và trả về HTTP 200
    • Có thể dùng git clone để khôi phục tệp chưa đọc và lịch sử Git
    • /v1/settings mà CLI nhận vẫn giữ "trace_upload_enabled": true, "upload_enabled": true, "session_registry_enabled": true
    • Giới hạn mỗi tệp 1GiB cũng được trả về dưới dạng "max_upload_file_bytes": 1073741824
    • Theo kết quả thử nghiệm, opt-out kiểm soát việc có dùng cho huấn luyện hay không, nhưng không chặn hành vi repository rời khỏi máy tính để được upload và lưu trữ

Những điều chưa được chứng minh và giới hạn của bằng chứng

  • Chỉ bằng capture mạng thì không thể chứng minh xAI sử dụng dữ liệu để huấn luyện mô hình
    • Phạm vi xác nhận là việc truyền, chấp nhận HTTP 200, archive dùng để lưu trữ và đích GCS
  • Log PUT trực tiếp tới storage.googleapis.com/grok-code-session-traces quan sát trong lần chạy 3GB đã bị ghi đè và không được giữ lại
    • Căn cứ cho upload nhiều GiB là log /v1/storage của lần chạy 12GB được giữ lại, cùng với binary và metadata nêu rõ bucket
  • Trong các thử nghiệm theo kích thước, log 64MB, 600MB và 3GB không còn, chỉ log 12GB được giữ lại
  • Lần chạy 12GB bị dừng ở khoảng 5.10GiB, nên không thể kết luận toàn bộ 12GB sẽ được upload đến cuối
  • Chưa thử mọi cấp tài khoản và tổ hợp cấu hình
    • Ở gói miễn phí, upload nhiều GiB đã thành công
    • Trên SuperGrok, upload git bundle vẫn thành công ngay cả khi tắt “Improve the model”
    • Trong thử nghiệm không tìm thấy thiết lập tắt upload, nhưng không khẳng định rằng không thể vô hiệu hóa tuyệt đối trong mọi môi trường
  • Ban đầu đã phán đoán sai rằng blob dung lượng lớn không được upload dựa trên kết quả nettop theo PID, nhưng nhận định đó đã được rút lại
    • Tiến trình điều phối upload riêng và PUT được ký sẵn đi trực tiếp tới IP Google có thể bị bỏ sót khi đo theo host API hoặc một PID đơn lẻ
    • Capture wire qua proxy sau đó thay thế nhận định ban đầu
  • Kết quả giới hạn trong môi trường grok 0.2.93, macOS Apple Silicon, tháng 7 năm 2026; xAI có thể thay đổi hành vi về sau

Bằng chứng chính được giữ lại

  • secrets_responses_body.bin: cho thấy nguyên văn .env được đưa vào body /v1/responses
  • secrets_session_state.tar.gz: cho thấy cùng các giá trị bí mật nằm trong archive dành cho /v1/storage
  • wire_12gb.log: ghi lại upload lưu trữ 5.10GiB, 83 phản hồi HTTP 200 cho /v1/storage*, 0 lỗi lưu trữ và chênh lệch dung lượng khoảng 27.800 lần giữa hai kênh
  • model_limit.txt: ghi lại 1 lần 402 và 3 lần 429 phát sinh trong request mô hình
  • crate_strings.txt: lưu các chuỗi xai-data-collector, grok-code-session-traces, storage.googleapis.com
  • uploaded_repo.bundle: bằng chứng repository đầu tiên cho thấy tệp chưa đọc và toàn bộ lịch sử Git được khôi phục từ git bundle đã upload
  • uploaded_repo_auth.bundle: bằng chứng tái hiện cùng kết quả ở repository độc lập thứ hai
  • staged_base_tree_manifest.json: cho thấy các tệp chưa đọc được liệt kê trong manifest snapshot repository
  • staged_metadata.json: cho thấy đích tệp là gs://grok-code-session-traces/…
  • gcs_puts.txt là placeholder rỗng vì không giữ lại được PUT trực tiếp tới GCS, và không thể dùng làm bằng chứng lưu giữ cho PUT đó

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Ý kiến trên Hacker News

  • Luôn tách riêng công cụ lập trình và nhà cung cấp LLM, đồng thời giới hạn quyền của công cụ lập trình bằng sandbox bubblewrap
    Công cụ chỉ có thể đọc thư mục dự án đang làm việc, .git ở chế độ chỉ đọc, còn các thư mục nhạy cảm được mount thành thư mục trống
    Cũng cô lập network namespace để chỉ cho phép truy cập Internet thông qua HTTP proxy trên Unix socket, chỉ cho phép host của nhà cung cấp LLM cụ thể và chặn host của chính công cụ
    Ví dụ, với Crush thì cho phép truy cập *.openrouter.ai nhưng chặn *.charm.land vốn được dùng để tự động cập nhật danh sách LLM. Nhờ vậy thấy yên tâm hơn nhiều khi giao mọi việc trong chế độ yolo

    • Với bubblewrap, tốt hơn là lấy một rootfs như debian:unstable từ Docker Hub rồi dựng thành môi trường phân phối hoàn chỉnh trong một thư mục riêng
      Cài AI agent vào đó, sau đó đặt rootfs của bản phân phối ở chế độ chỉ đọc, còn /home/user tùy chỉnh ở chế độ đọc-ghi, rồi viết script chạy bwrap. Như vậy các tệp quan trọng ngoài những thư mục đã chỉ định sẽ không hiển thị, và cũng có thể chạy nhiều agent mà chúng không nhìn thấy nhau
      Muốn siết chặt hơn nữa thì có thể gọi runsc ... do ... của gVisor ở bên trong hoặc dùng trình giám sát máy ảo như muvm. bwrap lo phần cấu hình môi trường, còn khóa lại bằng một công cụ sandbox riêng nên đáng tin cậy
      Nếu cấu hình đúng thì chỉ riêng bwrap cũng đủ để chặn phần lớn kẻ tấn công; để leo thang đặc quyền thì thực tế có lẽ phải dùng zero-day của nhân Linux
    • Tò mò không biết đã dùng cách nào để triển khai việc này
    • Cũng muốn biết liệu những lớp tăng cường bảo mật bổ sung này chỉ mang lại cảm giác an tâm hay đã thực sự chặn được hành vi nguy hiểm nào chưa
      Nếu mô hình ngu ngốc đến mức phải dùng ràng buộc để ngăn nó làm chuyện dại dột thì ngay từ đầu có lẽ đã không đáng dùng. Tôi cũng đang tự tăng cường môi trường của mình, nên không phải đang chỉ trích thông lệ này

  • Các trình chạy agent lập trình native độc quyền như claude-code, Codex, grok-build là rủi ro về quyền riêng tư vì không biết bản cập nhật tiếp theo sẽ bổ sung tính năng kín nào
    Dùng mô hình qua API trong opencode an toàn hơn nhiều, nhưng phải chấp nhận đánh đổi là khó đạt hiệu năng tốt như trình chạy native

    • Nếu mức sử dụng đủ lớn thì chỉ riêng việc gọi công cụ phía máy chủ cũng có thể tái dựng toàn bộ codebase, và quá trình này gần như không thể phát hiện hoàn toàn
      Cách của Grok chỉ lộ liễu hơn; opencode cũng không tạo ra ranh giới bảo mật thực sự, khá giống meme dùng Cheetos làm ổ khóa
    • Codex là mã nguồn mở
    • Bản thân tự động cập nhật cũng là một vấn đề lớn
      Đương nhiên việc không vá ngay các lỗ hổng thực thi mã từ xa kiểu Windows XP SP1 cũng nguy hiểm, nhưng trong vài chục năm qua tôi đã thấy thiệt hại do cập nhật tự động gây ra còn nhiều hơn thiệt hại có thể xuất phát từ việc không cập nhật
    • Tôi có dùng agent riêng, nhưng không thể chấp nhận rủi ro tài khoản công ty bị khóa chỉ vì việc đó

  • Việc “tải lên toàn bộ kho mã, bao gồm mọi nội dung tệp đang được theo dõi và toàn bộ lịch sử Git, bất kể agent có đọc các tệp đó hay không” thực sự rất sốc
    Cũng phần nào đoán được Elon có thể làm chuyện như vậy để đuổi kịp, nhưng vẫn cực kỳ đáng lo. Giá có tính cạnh tranh và hiệu năng của grok-4.5 cũng đủ tốt, nhưng chính vì lý do này mà tôi đã không chọn nó

    • Đây rõ ràng là rò rỉ dữ liệu và lẽ ra phải là bất hợp pháp
    • Không biết do quan hệ hợp tác với Microsoft mà OpenAI có thể truy cập mọi kho mã GitHub hay không
    • Rốt cuộc đây là một cuộc đua xuống đáy
    • Tôi không tìm thấy thông tin về việc phải chia sẻ dữ liệu nào nên ngay cả dùng thử miễn phí cũng còn ngần ngại
    • Tôi luôn chạy kiểu CLI này trong một sandbox giới hạn các thư mục có thể truy cập
      CLI có thể vô tình lấy cả SSH key hay thông tin nhạy cảm khác, và lập trình viên thực sự rất hay mắc những lỗi như vậy. Tôi không muốn giao sự an toàn cho việc “tải lên mọi tệp có thể truy cập” là cố ý hay vô tình

  • Mục đầu tiên, “mô hình đã đọc một tệp chứa bí mật trong kho mã”, về thực chất là hành vi có chủ đích
    LLM không thể biết trong tệp có bí mật hay không trước khi đọc nó. Vấn đề gốc rễ là cấp cho LLM quyền truy cập các tệp chứa bí mật dạng văn bản thuần rồi lại ngạc nhiên khi nó đọc chúng
    Tuy nhiên, việc tự động tải lên toàn bộ kho mã thì vô lý. Nếu là kho mã cỡ nhiều GB thì trên một số đường truyền sẽ mất rất lâu, và nếu không có mục đích khác là gom toàn bộ dữ liệu thì nhìn chung cũng chẳng có mấy ý nghĩa

  • Tôi vốn luôn giả định rằng không gian làm việc hiện tại nơi đang chạy agent ít nhất là thứ agent có thể tự do xử lý, nên điều này có vẻ như hành vi đã được dự liệu
    Phần lớn agent đều đọc mã và cả bí mật trong đó ngay từ prompt đầu tiên. Nếu việc này được tận dụng ở phía máy chủ để giảm độ trễ vòng lặp prompt và số lần gọi công cụ thì có khi lại có lợi cho người dùng?

    • Khi đọc tệp và chuyển phản hồi, họ dùng API nhắn tin thông thường
      Nhưng ở đây lại phát hiện một endpoint riêng để đẩy toàn bộ thư mục dự án lên bucket lưu trữ GCP. Ai từng thiết kế hệ thống phân tán quy mô lớn đều sẽ nhận ra đây là cấu trúc nhằm cào dữ liệu huấn luyện
    • Theo tôi biết thì Cursor có làm một kiểu lập chỉ mục ở máy cục bộ
      Không cần tải lên toàn bộ tệp; có thể tìm kiếm để lấy đúng phần liên quan rồi gửi cho mô hình sử dụng

  • Sẽ tốt hơn nếu phần tổng quan do con người viết, nhưng bản thân nội dung thì đáng bất an

    • Đây là kiểu bài chỉ cần vài khối mã cho thấy nội dung bị tải lên cùng 2–3 đoạn văn là đủ
      Báo cáo do AI viết quá khó đọc, tôi chỉ lướt khoảng 10 giây là mất hứng
    • Ít nhất con người cũng có thể cùng LLM biên tập thêm vài lượt để cải thiện văn phong

  • Tò mò không biết thứ bị lấy cắp có được đưa vào dự án Macrohard “tự động hóa mọi doanh nghiệp” hay “everything app” không
    Có cảm giác như họ nghĩ chẳng cần tự xây mọi thứ, cứ ăn cắp là được

    • Điểm chốt hạ là người dùng còn trả tiền để được hưởng kiểu đặc quyền này
      Nếu điều hành kiểu công ty như vậy mà không có đạo đức, thì khi quy mô lừa đảo bị lộ và trước khi bị quản lý chặn lại, họ sẽ cố ăn cắp càng nhiều càng tốt. Không phải tôi nói họ đang thực sự làm thế, nhưng động cơ kinh tế thì được căn chỉnh chính xác theo hướng đó

  • Cần xem như AI agent có thể đọc các tệp trong thư mục nơi trình chạy được khởi động
    Trong hầu hết trường hợp, ngay từ prompt đầu tiên nó sẽ đọc cả mã nguồn lẫn thông tin bí mật bên trong, và .env chỉ dành cho môi trường cục bộ nên không được chứa bí mật thực sự. Không thể tin cậy chỉ thị dành cho AI agent, nên phải cô lập nó khỏi bí mật thật
    Nếu chấp nhận tiền đề đó, thì có thể lưu mã trên máy chủ còn hơn là gửi nó làm context mỗi lần

    • Xét theo cách LLM hoạt động, rốt cuộc mã vẫn phải được gửi lại qua context
      Lý do duy nhất để tải riêng như vậy, theo tôi, là Musk muốn thu thập dữ liệu huấn luyện sạch như cấu trúc dự án, thư viện phổ biến, quy trình CI cho mô hình tiếp theo
    • Dù chỉ tải lên một lần thì trong quá trình suy luận nó vẫn tiếp tục được đưa vào; thứ tiết kiệm được chỉ là một ít lưu lượng HTTP
    • Trọng tâm câu chuyện không quá lớn. Có lẽ Grok chỉ quyết liệt hơn khoảng 10% trong việc dựng context so với nhà cung cấp khác, hoặc đơn giản là cách này giúp phát hành nhanh hơn
      Mọi nhà cung cấp đều có đủ khả năng và động cơ để làm điều tương tự nếu điều đó giúp cải thiện kết quả
      Khác biệt thực sự là nó gửi cả các tệp bí mật như .env mà không che đi, rồi không chỉ xử lý tạm thời mà còn lưu vào một bucket GCS có tên cụ thể, đồng thời bật mặc định mà không thông báo cách tải lên trong tài liệu cấu hình CLI
      Không nên để .env không mã hóa ở đường dẫn có thể truy cập. Sẽ tốt hơn nếu Grok nhận diện và bỏ qua bí mật, nhưng người dùng không nên dựa vào hành vi như vậy

  • Việc toàn bộ kho mã được tải lên y hệt dù bật hay tắt cài đặt “Improve the model” là cực kỳ nghiêm trọng
    Phần lớn công ty AI khác cũng có thể làm điều tương tự trong trình chạy riêng nếu người dùng đồng ý thu thập dữ liệu, nhưng đã tắt rõ ràng mà vẫn tải lên thì là hành vi ác ý

  • Khi tải toàn bộ codebase lên, mô hình có thể xem mã trong lúc “suy nghĩ” mà không cần yêu cầu client thực hiện các lệnh gọi công cụ thực tế
    Không rõ việc phải yêu cầu lại về client có nhược điểm gì nên đây không phải lý do quá thuyết phục, nhưng là lời biện minh hợp lý nhất tôi có thể nghĩ ra

    • Mục đích thực sự có vẻ gần với việc đánh cắp bí mật kinh doanh, thiết kế ứng dụng, tri thức vận hành nội bộ hoặc sao chép mã, ứng dụng, công cụ, quy trình
      Mã vốn là riêng tư nay trở thành mã của họ
    • Cũng có thể nhằm mục đích điều khiển từ xa từ điện thoại thông qua một container nào đó ngay cả khi máy tính đang ngoại tuyến, rồi sau này quay lại phát triển cục bộ và đồng bộ thay đổi từ bucket GCP
      Khá hữu ích, nhưng không hữu ích đến mức giao cả kho mã cho Elon. Việc họ khiến người dùng không thể từ chối và hoàn toàn không công khai điều đó càng củng cố kết luận rằng không nên giao dữ liệu này cho họ