xAI Grok Build CLI가 데이터 흡입하는 와이어 — .env 그대로, 저장소 통째로

GeekNews #31375 에 올라온 글은, xAI의 코딩 CLI Grok Build 가 사용자 디스크에서 어떤 데이터를 어디로 보내는지를 mitmproxy 캡처와 git bundle 복구로 직접 검증한 결과를 정리한 문서입니다. 표면적으로는 "AI가 내 코드를 읽는다" 수준으로 보일 수도 있지만, 실제 와이어 데이터는 그 범위를 훨씬 넘어섭니다.

흥미로운 점은 두 개의 독립된 업로드 채널이 존재한다는 사실입니다. 하나는 모델 응답을 만들기 위한 /v1/responses 채널이고, 다른 하나는 작업 공간 전체를 묶어서 보내는 /v1/storage 채널입니다. 두 채널 사이의 전송량 차이는 약 27,800배로, 단순한 컨텍스트 전송이 아니라 저장소 스냅샷이 별도 파이프라인으로 빠져나가고 있음을 보여줍니다.

• grok 0.2.93의 네트워크 트래픽을 직접 캡처한 결과, Grok Build는 읽은 파일을 마스킹 없이 전송하고 session_state로 저장했으며 테스트용 .env 비밀값도 두 경로에 그대로 포함했음
• 모델 요청이 에이전트가 읽은 파일을 보내는 것과 별개로, 모든 추적 파일과 Git 이력을 담은 저장소 전체가 git bundle로 업로드됐고 열지 말라고 지정한 파일도 원문 그대로 복구됐음
• 12GB 무작위 파일 저장소에서 /v1/responses 요청은 총 192KB였지만 /v1/storage 전송량은 캡처 중단 시점까지 5.10GiB에 달해 약 27,800배 차이가 났으며, 모든 저장 요청이 HTTP 200을 반환했음
• 업로드 목적지는 Google Cloud Storage의 grok-code-session-traces 버킷이었고, "Improve the model"을 꺼도 trace_upload_enabled: true와 upload_enabled: true가 유지되며 전체 저장소 업로드가 계속됐음
• 실험은 데이터의 전송·수락·저장을 입증하지만 모델 학습에 사용됐는지는 확인하지 못했으며, .gitignore 파일과 모든 계정·설정 조합도 시험하지 않아 결과는 2026년 7월의 특정 버전에 한정됨

---

테스트 대상과 분석 범위

• 대상은 일반 소비자 계정으로 로그인한 xAI 공식 Grok Build CLI였음
• - 설치 경로는 ~/.grok/bin/grok
• - 브라우저에서 X 또는 SuperGrok 계정으로 인증하며 API 키는 사용하지 않음
• - 테스트 바이너리는 Apple Silicon용 grok 0.2.93 (f00f96316d4b)임
• - SHA-256은 2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c임
• 바이너리 문자열에서 자체 Rust 업로드 구성요소와 저장소 관련 상수가 확인됐음
• - 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
• 모든 캡처는 테스트 수행자의 컴퓨터와 트래픽만을 대상으로 했으며, 저장소에는 실제 자격 증명 대신 고유 canary 문자열을 넣었음

재현 및 트래픽 캡처 방법

• macOS Apple Silicon에서 mitmproxy의 CA를 로그인 키체인에 신뢰 인증서로 추가하고 HTTPS_PROXY와 SSL_CERT_FILE을 설정해 Grok의 HTTPS 요청을 캡처함
• Grok은 이 구성에서 인증서 고정(certificate pinning) 으로 캡처를 차단하지 않았음
• mitmdump 애드온으로 요청별 메서드, 호스트, 경로, 응답 상태, 요청 바이트 크기를 기록하고 xAI 호스트로 향하는 요청 본문을 저장함
• ~/.grok/upload_queue/*를 실행 중 복사한 뒤 gzip과 tar로 풀어 전송 대기 중인 스테이징 아티팩트도 검사함
• 각 파일에는 출처를 구분할 수 있는 고유 마커를 넣었으며, 비밀 파일에는 다음과 같은 가짜 값을 사용함
• - API_KEY=CANARY7F3A9-SECRET-should-not-leave
• - DB_PASSWORD=CANARY7F3A9-DBPASS

채널 A: 읽은 파일과 .env의 모델 요청 전송

• Grok이 읽은 파일 내용은 POST cli-chat-proxy.grok.com/v1/responses의 모델 턴 본문에 직렬화됐음
• - 캡처된 48,070바이트 요청에는 "model":"grok-4.5"와 메시지 배열이 포함됐음
• - .env의 API_KEY와 DB_PASSWORD canary가 줄바꿈까지 원문 그대로 발견됐음
• 같은 내용은 session_state 아카이브에도 들어가 POST /v1/storage로 업로드됐으며, 해당 저장 요청은 HTTP 200으로 수락됐음
• 비밀값은 모델이 일시적으로 처리하는 데 그치지 않고 저장용 아카이브에도 기록됐음
• 비밀값은 .env 또는 secrets.env에 있었고 Git으로 추적되는 파일이었음
• - 확인된 범위는 테스트한 .env 내용이 마스킹되지 않은 채 전송됐다는 점임

채널 B: 읽지 않은 파일까지 포함한 저장소 전체 업로드

• /v1/storage는 모델이 읽은 파일을 보내는 /v1/responses와 별개로 작업 공간 전체 스냅샷을 업로드했음



• 실제 cereblab_api 저장소에서 Reply with exactly: OK. Do not read or open any files.라고 지시한 뒤 실행함
• - Grok은 POST /v1/storage로 152,102바이트 git bundle을 전송했고 서버는 HTTP 200을 반환했음
• - 캡처한 uploaded_repo.bundle을 git clone하자 열지 말라고 지정한 src/_probe/never_read_canary.txt가 복구됐음
• 두 번째 독립 저장소 cereblab_auth에서도 같은 결과가 재현됐음
• 바이너리에는 after_codebase.tar.gz, repo_state.upload, collecting workspace files, spawning background coordinator 같은 문자열도 포함돼 작업 공간 수집 메커니즘과 일치했음

12GB 저장소에서 확인한 다중 GiB 전송

• 압축이 거의 되지 않는 무작위 파일로 저장소 크기를 늘리며 업로드 동작을 관찰함
• - 64MB에서는 약 48MB 크기의 단일 POST /v1/storage가 HTTP 200을 반환했지만 로그는 보존하지 못함
• - 약 600MB에서는 약 7.5MB 청크 수십 개가 모두 HTTP 200을 반환했으나 로그가 남아 있지 않음
• - 약 12GB에서는 약 75MB 청크를 /v1/storage로 계속 전송했으며 5.10GiB 시점에서 캡처를 중단함
• 보존된 wire_12gb.log에는 /v1/storage* HTTP 200 응답이 총 83개 있음
• 같은 세션의 두 채널 사이에는 큰 용량 차이가 있었음
• - /v1/responses는 5개 요청을 합쳐 196,705B, 약 192KB였고 가장 큰 요청도 60,394B였음
• - /v1/storage는 5.10GiB였음
• - 약 27,800배 차이가 발생해 모델 요청에 포함되지 않은 대량의 저장소 데이터가 별도 저장 채널로 이동했음
• 이 결과는 로컬 upload_queue가 비워지는 현상에 의존하지 않음

저장 위치와 원격 측정

• 저장 목적지는 AWS S3가 아니라 Google Cloud Storage의 grok-code-session-traces 버킷으로 확인됐음
• - 바이너리에 grok-code-session-traces, storage.googleapis.com, Uploading bytes to GCS via proxy가 포함됐음
• 제3자 및 자체 원격 측정 요청도 확인됐음
• - Mixpanel의 api.mixpanel.com/track과 /engage
• - grok.com/_data/v1/events
• 검토한 CLI 설치 스크립트와 quickstart 자료에서는 repo_state, session_state, ~/.grok/upload_queue, grok-code-session-traces 업로드를 찾지 못했음
• - 확인 가능한 범위는 CLI 자체 설정 자료에서 드러나지 않았다는 것임

"Improve the model" 설정과 정책 범위

• 클라우드 코딩 에이전트가 작업에 필요한 코드 문맥을 서버로 보내는 행위 자체는 필요한 동작임
• 테스트에서 확인된 동작은 다음 세 가지로 구분됨
• - .env 같은 비밀 파일을 마스킹 없이 전송함
• - 해당 내용을 명시된 GCS 버킷에 저장함
• - 저장소 전체 업로드가 검토한 CLI 설정 자료에 드러나지 않은 채 기본 활성화돼 있음
• xAI 소비자 정책은 모델 개선을 위한 데이터 이용과 opt-out을 광범위하게 다루며, Private Chat은 자동 opt-out이고 opt-out은 소급 적용되지 않음
• - 관련 문서는 xAI Privacy Policy와 Consumer ToS임
• "Improve the model"을 꺼도 업로드는 중단되지 않음
• - 설정을 끈 상태에서도 전체 저장소가 git bundle로 /v1/storage에 업로드됐고 HTTP 200을 반환했음
• - git clone으로 읽지 않은 파일과 Git 이력을 복구할 수 있었음
• - CLI가 받은 /v1/settings에는 "trace_upload_enabled": true, "upload_enabled": true, "session_registry_enabled": true가 유지됐음
• - "max_upload_file_bytes": 1073741824로 파일당 1GiB 제한도 반환됐음

한국 시장에서의 시사점

국내에서도 코딩 에이전트(GitHub Copilot, Cursor, Claude Code, 그리고 이제 Grok Build까지)를 도입하는 팀이 빠르게 늘고 있습니다. 그런데 이번 실험은 에이전트가 어떤 데이터를 어디로 보내는지는 사용자 입장에서 거의 보이지 않는다는 점을 적나라하게 드러냅니다. .env에 들어있는 canary 문자열이 줄바꿈까지 그대로 전송됐고, "이 파일은 열지 말라"고 지시한 파일조차 git bundle에서 복구됐습니다.

운영 측면에서 가장 먼저 챙겨야 할 것은 (1) 비밀 파일을 워크스페이스 밖에 두기, (2) opt-out이 학습은 막지만 전송 자체를 멈추지는 않는다는 사실을 팀에 공유하기, (3) 가능하면 mitmproxy 같은 도구로 한 번 직접 캡처해서 우리 환경의 실제 트래픽 모양을 확인하기 입니다. AI를 코드에 들이는 속도가 빨라지는 만큼, 데이터가 나가는 속도와 방향도 함께 점검해야 합니다.

원문: GeekNews #31375 - xAI Grok Build CLI가 xAI로 전송하는 데이터: 와이어 수준 분석 · 원 분석: gist.github.com/cereblab

---

📰 원본 출처 · https://news.hada.io/topic?id=31375 (#N=31375)

이 글은 GeekNews(긱뉴스)에 게제된 글을 기반으로 작성되었습니다. 원본의 라이선스와 저작권은 원작자에게 있습니다.