xAI Grok Build CLI 0.2.93 분석: 비공개 비밀 및 전체 저장소 업로드

xAI Grok Build CLI(버전 0.2.93)에 대한 와이어 레벨 분석은 이 도구가 비공개 비밀을 그대로 전송하고 전체 로컬 저장소를 xAI 서버에 업로드한다는 것을 보여줍니다. 이 동작은 AI 에이전트가 세션 중에 실제로 파일을 읽었는지 여부와 무관하게 발생하며, "Improve the model" 설정을 비활성화해도 지속됩니다.

비공개 비밀 전송

Grok Build CLI가 파일을 읽을 때, 해당 내용은 비공개 처리 없이 xAI에 전송됩니다. 여기에는 .env 또는 secrets.env와 같은 민감한 파일이 포함됩니다. 데이터는 두 개의 별도 채널을 통해 전송됩니다:

Model-Turn Channel: 파일 내용이 모델 상호작용에 사용되는 POST /v1/responses 요청 본문으로 직렬화됩니다.
Storage Channel: 내용이 session_state 아카이브로 패키징되어 POST /v1/storage를 통해 업로드됩니다.

캡처된 트래픽 분석 결과, 카나리 비밀(예: API_KEY=CANARY7F3A9-SECRET)이 두 엔드포인트 모두에 그대로 전송되고 HTTP 200 상태 코드로 수락되는 것을 확인했습니다.

Git 번들을 통한 전체 저장소 업로드

에이전트가 읽는 파일을 넘어, Grok Build는 작업 공간의 전체 스냅샷을 수행합니다. 이 도구는 POST /v1/storage를 통해 모든 추적 파일과 전체 git 히스토리를 포함한 전체 저장소를 git 번들 형태로 업로드합니다.

대량 업로드 증거

볼륨 차이: 에이전트에게 읽지 말라고 명시적으로 지시된 무작위 파일을 포함하는 12 GB 저장소를 사용한 테스트에서, 모델-턴 채널(/v1/responses)은 192 KB의 데이터만 전송했습니다. 반면, 저장소 채널(/v1/storage)은 캡처가 중단되기 전까지 5.10 GiB의 데이터를 업로드했습니다. 약 27,800배의 비율은 업로드가 코드베이스 스냅샷이며 모델이 실제로 섭취한 내용과는 무관함을 확인시켜 줍니다.
Git Clone을 통한 검증: POST /v1/storage 요청을 캡처함으로써 연구자들은 git 번들을 복구할 수 있었습니다. 이 번들에 대해 git clone을 실행하면 저장소가 재구성되었으며, 에이전트에게 열지 말라고 명시적으로 지시된 파일과 그 고유 마커도 그대로 포함되었습니다.
규모: 업로드 메커니즘은 다중 기가바이트 규모까지 확장됩니다. 12 GB 저장소 테스트에서 82개의 콘텐츠 POST(각 약 75 MB인 73개의 청크 포함) 모두 HTTP 200을 반환했으며, 테스트 범위 내에서 저장소 크기 제한에 도달하지 않았음을 나타냅니다.

저장소 목적지 및 인프라

업로드된 데이터는 grok-code-session-traces라는 Google Cloud Storage(GCS) 버킷으로 라우팅됩니다. 이는 다음을 통해 확인됩니다:

바이너리 분석: 바이너리 내 문자열이 grok-code-session-traces와 storage.googleapis.com를 참조합니다.
메타데이터 검사: 스테이징된 metadata.json 파일은 gs://grok-code-session-traces/repo_changes_dedup/v2/... 형식으로 파일별 목적지를 보여줍니다.

또한, CLI는 Mixpanel(api.mixpanel.com)을 통한 제3자 텔레메트리와 xAI 자체 이벤트 추적(grok.com/_data/v1/events)을 사용합니다.

동의, 정책 및 옵트아웃 제한

xAI의 소비자 정책은 사용자가 모델 개선을 위해 자신의 데이터를 사용하지 않도록 옵트아웃할 수 있도록 허용하지만, 이 토글은 저장소 업로드 과정을 중단하지 않습니다.

옵트아웃의 무효성: 테스트 결과, "Improve the model"을 OFF로 설정해도 CLI는 여전히 전체 저장소를 git 번들로 업로드했으며 서버의 /v1/settings 응답은 계속해서 "trace_upload_enabled": true를 반환했습니다.
문서 부족: repo_state와 session_state를 grok-code-session-traces 버킷에 업로드하는 구체적인 메커니즘은 CLI 설치 스크립트나 퀵스타트 자료에 명시되어 있지 않습니다.

커뮤니티 관점 및 완화 방안

이러한 발견 이후의 기술 토론은 독점 에이전트 러너 사용에 대한 중대한 프라이버시 우려를 강조합니다.

"바로 이것이 이유입니다... 저는 그들을 선택하지 않았습니다. [전체 저장소 업로드]는 매우 우려됩니다."

사용자들은 이러한 도구를 반드시 사용해야 하는 경우를 위해 여러 완화 전략을 제안했습니다:

샌드박싱: bubblewrap 또는 landstrip과 같은 도구를 사용해 에이전트가 필요한 프로젝트 디렉터리만 접근하도록 제한하고, 네트워크 네임스페이스를 격리하여 특정 LLM 제공자 호스트명만 허용합니다.
프록시: 커스텀 프록시(예: CLIProxyAPI 포크)를 구현해 외부 스트림에서 비밀을 스캔하고 상위 제공자에 도달하기 전에 고유 식별자로 교체합니다.
환경 격리: 에이전트를 전용 UNIX 계정에서 실행하고 홈 디렉터리 및 /etc 또는 /proc 파일 시스템에 대한 접근을 제한합니다.

기술적 발견 요약

발견	세부 내용	상태
비밀 누출	`.env` 파일이 `/v1/responses`와 `/v1/storage`를 통해 비공개 처리 없이 전송됨	입증됨
저장소 업로드	전체 추적 워크스페이스와 git 히스토리가 git 번들로 업로드됨	입증됨
데이터 양	다중 GB 업로드 확인 (최대 5.1 GiB 캡처)	입증됨
목적지	Google Cloud Storage 버킷 `grok-code-session-traces`	입증됨
옵트아웃	"Improve the model" 토글이 업로드를 중단하지 않음	입증됨