xAI Grok Build CLI가 실제로 xAI에 보내는 데이터 분석

결론부터 말하면, 이 분석은 “Grok가 학습에 썼다”가 아니라 “무엇이 전송·저장됐는가”를 증명하려는 글임

• 대상은 xAI 공식 Grok Build 코딩 CLI 0.2.93임

  • macOS Apple Silicon 환경에서 consumer login으로 테스트함
  • 바이너리 SHA-256, 버전, strings 출력, 캡처 로그, 재현 명령을 같이 제시함
  • 실제 비밀키가 아니라 CANARY7F3A9 같은 가짜 canary secret을 넣은 테스트 저장소를 사용함

• 핵심 주장은 세 가지임

  • Grok가 읽은 파일 내용이 xAI로 전송되고, .env 안의 가짜 비밀값도 비가림 처리 없이 포함됨
  • 별도로 저장소 전체가 업로드되며, 읽지 말라고 한 파일과 git 히스토리까지 복원 가능한 git bundle이 전송됨
  • 업로드 목적지는 grok-code-session-traces라는 구글 클라우드 스토리지(GCS) 버킷으로 보인다는 증거를 제시함

첫 번째 채널: 모델 요청에 읽은 파일 내용이 그대로 들어감

• Grok가 파일을 읽으면 그 내용이 /v1/responses 요청 본문에 들어간 것으로 캡처됨

  • 48,070바이트짜리 POST 요청 body에서 .env 내용이 그대로 발견됨
  • 예시 canary 값인 API_KEY=CANARY7F3A9-SECRET-should-not-leave와 DB_PASSWORD=CANARY7F3A9-DBPASS가 복원됨
  • 요청 body 안에는 model":"grok-4.5"와 messages 구조도 들어 있어 모델 턴 요청으로 식별됨

• 같은 내용이 session_state 아카이브에도 들어간 것으로 제시됨

  • 테스트 중 ~/.grok/upload_queue/*를 race-copy해서 압축을 풀었고, 그 안에서도 canary secret이 발견됨
  • 이 아카이브는 /v1/storage로 업로드되는 경로에 놓인 것으로 설명됨

• 다만 이 부분에는 범위 제한도 명확히 적혀 있음

  • 연구자는 “읽지 않은 파일이 /v1/responses에 들어갔다”는 주장은 하지 않음
  • 읽지 말라고 한 파일은 모델 턴 채널에서는 발견되지 않았다고 밝힘
  • 즉 모델 요청 채널은 “에이전트가 읽은 파일” 중심이고, 전체 저장소 업로드는 별도 채널이라는 구분이 중요함

두 번째 채널: 저장소 전체가 별도로 업로드됨

• 더 큰 이슈는 /v1/storage 쪽 저장소 스냅샷 업로드임

  • 12GB짜리 랜덤 파일 저장소 테스트에서 /v1/storage 요청만 총 5,476,228,005바이트, 약 5.10GiB가 캡처됨
  • 약 75MB 크기 chunk 73개가 모두 HTTP 200을 받았고, 캡처는 중간에 중단됨
  • 저장소 요청 실패는 0건으로 보고됨

• 모델 턴 채널과 저장소 업로드 채널의 크기 차이가 결정적 근거로 쓰임

  • 같은 12GB 세션에서 /v1/responses 전체 요청량은 196,705바이트, 약 192KB였음
  • /v1/storage는 5.10GiB였으니 약 27,800배 차이임
  • 모델이 파일을 대량으로 읽은 게 아니라, 별도 저장소 스냅샷이 나갔다고 보는 이유임

• “읽지 말라”고 한 파일이 실제 업로드 bundle에서 복원됐다는 점이 가장 세게 박힘

  • SuperGrok 계정으로 quota를 풀고, Reply with exactly: OK. Do not read or open any files.라는 프롬프트를 사용함
  • src/_probe/never_read_canary.txt에 고유 문자열 CANARY-XR47P2-NEVERREAD-UNIQUE를 심어둠
  • 캡처된 uploaded_repo.bundle을 git clone했더니 해당 파일과 marker가 그대로 복원됨
  • bundle에는 전체 git 히스토리도 포함돼 있었다고 함

• 동일한 패턴을 두 번째 저장소에서도 재현했다고 밝힘

  • 별도 Cloudflare Worker 저장소에서도 git bundle 업로드가 캡처됨
  • clone 결과 CANARY-AUTH-4T8K2-NEVERREAD marker가 복원됨
  • 즉 단일 저장소에서 우연히 나온 결과가 아니라는 쪽으로 증거를 보강함

목적지는 GCS의 grok-code-session-traces로 보임

• 바이너리 문자열에서 관련 단서가 나옴

  • crates/codegen/xai-data-collector/src/gcs.rs
  • crates/codegen/xai-grok-shell/src/upload/{gcs,turn,trace,manifest}.rs
  • grok-code-session-traces
  • storage.googleapis.com
  • Uploading bytes to GCS via proxy

• staged metadata에도 버킷명이 그대로 등장함

  • 파일별 fileId가 gs://grok-code-session-traces/repo_changes_dedup/v2/.../sha256_... 형태였다고 함
  • 연구자는 AWS S3가 아니라 GCS 쪽 목적지라고 정리함

• 서드파티 텔레메트리도 별도로 관측됨

  • api.mixpanel.com/track, /engage 요청이 200 응답을 받음
  • grok.com/_data/v1/events 요청도 언급됨

“Improve the model”을 꺼도 업로드는 계속됐다는 대목이 꽤 중요함

• xAI의 소비자 정책은 모델 개선을 위한 데이터 사용과 opt-out을 설명함

  • 연구자도 이 부분은 인정함
  • 다만 정책상 학습 여부와 CLI의 저장소 업로드 동작은 별개라고 선을 그음

• 테스트에서는 모델 개선 설정을 꺼도 저장소 업로드가 중단되지 않았다고 함

  • /v1/settings 응답에서 trace_upload_enabled: true, upload_enabled: true, session_registry_enabled: true가 남아 있었다고 밝힘
  • max_upload_file_bytes는 1,073,741,824바이트, 즉 파일당 1GiB로 보고됨
  • 연구자 해석은 “opt-out은 학습 사용에 대한 것이지, 코드 업로드 자체를 멈추는 설정은 아니었다”는 쪽임

연구자가 스스로 못 박은 한계도 있음

• xAI가 이 데이터를 학습에 사용했다는 증거는 제시하지 않음

  • 전송과 저장은 관찰했지만, 학습 사용 여부는 정책과 내부 처리의 문제라고 분리함

• 일부 캡처는 관찰했지만 보존하지 못했다고 밝힘

  • 3GB 테스트에서 storage.googleapis.com/grok-code-session-traces 직접 PUT 라인을 봤지만 로그는 보존하지 못함
  • 64MB, 600MB, 3GB sweep 일부도 live 관찰만 있고 저장된 로그는 없다고 함
  • 보존된 핵심 로그는 12GB 테스트의 /v1/storage 200 응답들과 git bundle 증거임

• 문서화 여부 주장도 제한적으로 표현함

  • xAI 전체 문서를 다 뒤진 건 아니고, CLI 설치 스크립트와 quickstart 자료에서 이 메커니즘을 찾지 못했다는 주장임
  • 그래서 방어 가능한 표현은 “CLI 자체 설정 자료에 명확히 드러나지 않았다”에 가까움

개발팀이 바로 챙겨야 할 포인트

• 클라우드 코딩 에이전트를 회사 저장소에서 쓸 때는 “모델에게 보낸 프롬프트”만 보면 안 됨

  • 별도 trace, session_state, repo_state, upload queue 같은 채널이 있을 수 있음
  • 읽지 말라고 한 파일도 저장소 스냅샷에 들어갈 수 있는지 확인해야 함

• .env나 secrets 파일이 tracked 상태라면 특히 위험함

  • 이 테스트의 .env는 git-tracked였고, gitignored 파일까지 같은지 별도 검증은 없었음
  • 그래도 tracked secret이 그대로 전송된 것만으로도 충분히 큰 경고임

• 도구 도입 전에 확인할 질문이 꽤 명확해짐

  • 저장소 전체나 git 히스토리를 업로드하는가
  • 업로드된 데이터가 어느 리전에 얼마나 오래 저장되는가
  • 모델 개선 opt-out과 telemetry·trace 업로드 opt-out이 분리돼 있는가
  • 조직 관리자 설정으로 업로드 범위를 제한할 수 있는가

---

기술 맥락

• 이 분석의 핵심은 코딩 에이전트가 서버로 코드를 보내는 것 자체가 아니에요. 클라우드 기반 에이전트라면 모델 추론을 위해 일부 컨텍스트를 보내야 하거든요. 문제는 그 범위가 “읽은 파일”을 넘어 “저장소 전체와 히스토리”까지 확장되는지예요.

• git bundle 증거가 강한 이유는 파일 내용과 git 히스토리를 실제로 복원할 수 있기 때문이에요. 단순히 파일명이 manifest에 있었다거나 해시가 보였다는 수준이면 반박 여지가 남지만, clone해서 never-read marker를 읽었다면 업로드된 내용의 범위가 훨씬 명확해져요.

• /v1/responses와 /v1/storage를 분리해서 본 것도 중요해요. 모델 요청 채널은 에이전트가 읽은 파일 중심이고, 저장소 채널은 별도로 대량 데이터를 보낼 수 있어요. 그래서 프롬프트에 “파일 열지 마”라고 쓰는 것만으로 저장소 업로드를 막았다고 볼 수 없어요.

• 조직에서 이런 도구를 평가할 때는 개인정보 처리방침만 읽고 끝내면 부족해요. 실제 CLI가 어떤 auxiliary upload를 하는지, trace와 session_state가 어디에 저장되는지, opt-out이 학습에만 적용되는지 업로드 자체에도 적용되는지까지 봐야 해요.