Grok Build CLI가 전체 저장소를 조용히 업로드했다 — .env 파일 포함
cereblab이라는 연구원이 xAI의 Grok Build CLI 버전 0.2.93이 전체 git 저장소(비밀, 전체 히스토리, 모든 것)를 사용자에게 알리지 않고 Google Cloud Storage 버킷에 복사하고 있었다는 것을 발견했다.
무슨 일이 있었나
도구는 두 종류의 아웃바운드 요청을 만들었다. 모델 요청은 POST /v1/responses로 갔다. 하지만 별도의 POST /v1/storage 호출이 전체 작업 트리와 전체 .git 히스토리를 묶어 gs://grok-code-session-traces로 전송했다.
그 버킷은 xAI 소유다. 업로드는 단순히 CLI를 사용하는 부작용으로 실행됐다 — “내보내기” 버튼도, 프롬프트도, 경고도 없었다.
숫자는 충격적이다. 12GB 테스트 저장소에서 모델이 실제로 읽은 파일은 없었으나, /v1/responses는 ~192KB를 전송했다. /v1/storage는 73개 청크에 걸쳐 5.10 GiB를 보냈다. 27,800배 차이다.
카나리 테스트
cereblab은 never_read_canary.txt라는 파일에 고유 문자열을 심었다. 프롬프트는 말 그대로 “정확히 OK라고 답하라. 파일을 읽거나 열지 마라.” 였다. 모델은 텍스트를 따랐다. 카나리 문자열은 업로드된 번들에서 복구됐다.
따라서 유출은 모델이 파일을 주문형으로 읽어서가 아니었다. 무엇을 물었든 관계없이 실행되는 내장 파이프라인이었다.
옵트아웃이 작동하지 않은 이유
“모델 개선”이라는 설정이 있다. 끄면 데이터의 훈련 사용을 중단해야 한다. cereblab의 캡처는 서버가 여전히 trace_upload_enabled: true와 upload_enabled: true를 반환했음을 보여준다. 업로드는 계속됐다.
CLI에는 모델이 읽을 수 있는 파일을 제한하는 --deny 플래그가 있다. 그것은 읽기만 차단한다. 네트워크 이그레스에는 아무것도 하지 않는다 — 번들은 이미 나가고 있었다.
원격 킬 스위치
7월 12일, 이야기가 바이럴되면서 xAI가 발표하지 않은 일이 일어났다: 동일한 SHA-256 해시의 동일한 클라이언트 바이너리가 갑자기 다른 서버 응답을 받기 시작했다.
disable_codebase_upload: true. trace_upload_enabled: false.
업로드가 중단됐다. 클라이언트 업데이트도, 체인지로그도, 알림도 없었다.
이는 xAI가 항상 모든 Grok CLI 설치에서 원격으로 데이터 수집을 활성화 또는 비활성화할 수 있었으며, 사용자가 모르는 사이에 언제든지 가능했음을 의미한다. 그들은 기본적으로 켜두고 언급하지 않기로 선택했다.
Musk의 대응
7월 14일, Elon Musk가 논란에 한 단어로 답했다: “True.” 이어서:
“예방 조치로, 지금까지 SpaceXAI에 업로드된 모든 사용자 데이터는 완전히 삭제될 것이다. 어떤 것도 전혀 남지 않을 것이다.”
xAI는 동시에 Grok CLI의 /privacy 명령을 발표했다.
하지만 변하지 않은 것이 있다: 보안 권고는 발행되지 않았다. 동의 없이 전체 저장소가 수집된 이유에 대한 설명도 없다. 삭제에 대한 독립 감사도 없다.
References
- 초안 글: grokprivacy-draft
- 연구원: github.com/cereblab
- 재현 저장소: cereblab/grok-build-exfil-repro
- 기술 gist: cereblab’s gist