Grok Build CLI 0.2.93, '로컬 우선' 광고와 달리 전체 저장소·비밀번호 무단 전송… 옵트아웃도 무용지물

보안 연구 그룹 Cereblab(@cereblab)이 xAI의 AI 코딩 도구인 **Grok Build CLI (버전 0.2.93)**의 네트워크 트래픽을 mitmproxy로 직접 캡처해 분석한 결과를 GitHub Gist에 공개했습니다. 이 분석은 회사의 '로컬 우선(local-first)' 마케팅과 정면으로 배치되는 세 가지 주요 보안 결함을 밝혀냈습니다.

'로컬 우선' 마케팅을 뒤집는 데이터 유출 행위

연구원은 개발자 PC를 떠나는 두 가지 본질적으로 다른 데이터 경로를 발견했습니다:

• 모델 턴 채널 (POST /v1/responses): 에이전트가 연 파일만 모델 요청에 직렬화됩니다. 이는 클라우드 코딩 에이전트의 예상되는 동작입니다.
• 스토리지 채널 (POST /v1/storage): 전체 저장소가 git bundle로 독립적으로 패키징되어 grok-code-session-traces라는 Google Cloud Storage 버킷에 약 75MB 청크 단위로 업로드되었습니다.

데이터 규모의 차이는 이 업로드가 에이전트가 읽은 내용과 무관하다는 것을 증명했습니다. 12GB 테스트 저장소에서 스토리지 채널은 73개의 청크(모두 HTTP 200)를 통해 5.10GiB를 전송한 반면, 모델 턴 채널은 단 192KB만을 전송했습니다. 이는 약 27,800배의 차이입니다. 심지어 "파일을 읽지 말고 OK라고만 답하라"는 프롬프트를 입력했을 때도, 이 도구는 전체 저장소를 git bundle로 업로드했습니다. 캡처된 bundle을 복제하면 에이전트가 명시적으로 열지 말라고 지시받은 파일(src/_probe/never_read_canary.txt)과 전체 Git 커밋 기록이 그대로 복구되었습니다.

마스킹 없이 전송된 비밀번호 및 파일 유형

• .env 파일: API 키, 데이터베이스 비밀번호 및 기타 자격 증명이 마스킹이나 수정 없이 그대로 두 채널을 통해 전송되었습니다. 통제된 테스트에서 데이터베이스 자격 증명과 API 키가 포함된 48KB 파일이 요청 본문에 평문으로 나타났습니다.
• 모든 추적 파일 및 전체 Git 히스토리(모든 커밋, 브랜치, 태그)가 번들로 묶여 업로드되었습니다. 이는 수개월 전에 커밋되었으나 이후 교체된 비밀번호도 업로드된 데이터에 여전히 존재할 수 있음을 의미합니다.
• 업로드 메커니즘은 바이너리 내에 포함된 **자사 Rust 크레이트(xai-data-collector)**로 식별되었으며, 소스 경로는 crates/codegen/xai-data-collector/src/gcs.rs와 crates/codegen/xai-grok-shell/src/upload/입니다.
• 한 번도 읽지 않은 임의의 파일로 구성된 실제 12GB 코드베이스에서도 스토리지 엔드포인트는 크기 기반 거부 없이 업로드를 수락했습니다. 유일한 비-200 응답은 모델 사용 할당량 오류(402/429)였지, 스토리지 실패가 아니었습니다.

옵트아웃 토글의 실패

연구원은 'Improve the model' 개인정보 토글을 테스트했지만, 업로드를 중단시키지 못했습니다.

• 토글을 비활성화하고 재시작한 후에도 서버 설정 엔드포인트는 여전히 trace_upload_enabled: true를 반환했습니다.
• 스토리지 채널은 계속해서 HTTP 200 응답으로 청크 단위 git bundle 업로드를 수락했습니다.
• 설정에 disable_codebase_upload=true 구성 옵션이 존재하지만, 서버 측 동작과의 관계는 문서화되지 않았으며, 연구원의 테스트 결과 서버는 클라이언트 측 설정을 존중하지 않는 것으로 나타났습니다.

영향 받은 개발자를 위한 권장 조치

연구원과 분석 매체들은 다음을 권장합니다:

비공개 저장소에서 Grok Build CLI를 사용한 팀의 즉시 조치:

• Grok Build와 함께 사용된 저장소 내 모든 .env 파일, 설정 파일, Git 히스토리에 존재했던 모든 자격 증명을 교체하세요. 이들은 grok-code-session-traces GCS 버킷에 전송되어 저장되었을 수 있습니다.
• CLI가 전체 커밋 히스토리를 전송했으므로, 과거 커밋에 존재했을 수 있는 비밀번호에 대해 Git 히스토리를 감사하세요.
• 데이터가 전송되었을 뿐만 아니라 저장되었음을 가정하세요. 서버는 모든 스토리지 요청에 HTTP 200을 반환하여 수락을 확인했습니다.
• xAI에 버킷이 삭제되었는지, 어떤 접근 제어가 있었는지, 데이터 처리 계약(DPA)이 적용되었는지(공개 시점에는 게시된 것이 없음) 문의하세요.

모든 코딩 에이전트를 위한 아키텍처 완화 조치:

• 컨테이너/VM에서 에이전트를 실행하고, 작업 디렉토리만 마운트하고 홈 디렉토리, SSH 에이전트, Docker 소켓, 클라우드 자격 증명 디렉토리는 노출하지 마세요.
• 송신 제어를 구현: 모델 추론 엔드포인트와 인증 호스트는 허용하지만, 일반 객체 스토리지 직접 업로드는 차단하고 100MB를 초과하는 전송에 대해 알림을 설정하세요.
• 전체 호스트 패킷 캡처, DNS 로깅, 엔드포인트 네트워크 텔레메트리를 사용하여 포그라운드 바이트 카운터가 놓칠 수 있는 백그라운드 코디네이터 프로세스의 업로드를 탐지하세요.
• 최소 및 최대 프롬프트를 유선 캡처 하에서 테스트하세요. 에이전트가 파일을 읽지 말라고 지시받은 경우는 컨텍스트 윈도우를 넘어선 데이터 유출 탐지에 중요합니다.
• 최소 세 가지 프롬프트 케이스를 실행하세요: (1) "OK라고 답하고 어떤 파일도 읽지 마세요," (2) 특정 파일 하나를 읽으세요, (3) 프로젝트 언어를 검사하세요. 그런 다음 엔드포인트별 바이트를 비교하세요.