GeekNews에 공유된 xAI의 Grok Build CLI 데이터 흡입 사례는 단순한 사후 정정 사례가 아닙니다. 한 사용자가 홈 디렉터리에서 Grok Build를 실행한 뒤 SSH 키, 비밀번호 관리자 DB, 사진, 동영상까지 사용자 디렉터리 전체가 xAI 서버로 업로드됐다고 공개한 사건입니다. AI 코딩 에이전트가 데스크탑 권한으로 광범위한 파일을 읽을 수 있다는 사실 자체가 새롭지는 않지만, 이번 건은 (a) 사후 cat ~/.grok/logs/unified.json | grep repo_state.upload 한 줄로 확인이 가능했고 (b) AI CLI가 "신뢰할 수 있는 폴더"를 물어볼 때 무심코 "예"를 누른 워크플로의 위험을 적나라하게 보여준 점에서 교과서적으로 다뤄질 만합니다.
본문은 GeekNews에 올라온 2건의 핵심 주장(업로드 사실 + 확인 명령)과 함께, 저자 본인과 Hacker News 댓글에서 공유된 방어책(샌드박스·VM·컨테이너·bwrap·SSH 키 볼트·거부 목록)을 정리합니다. 결론부에서는 한국 개발자가 가장 자주 들여다보는 "프로젝트 루트" 워크플로에서 이 사건의 시사점을 짚습니다.
- 홈 디렉터리에서 Grok Build를 실행한 사용자는 SSH 키, 비밀번호 관리자 DB, 문서, 사진, 동영상이 담긴 사용자 디렉터리 전체가 xAI 서버에 업로드됐다고 주장함
cat ~/.grok/logs/unified.json | grep repo_state.upload명령으로 저장소 상태 업로드 기록을 확인할 수 있다고 안내함- 브라우저 세션 쿠키·방문 기록·암호화폐 지갑까지 전송됐을 가능성은 확인되지 않았지만, AI 에이전트가 문맥 확보를 위해 지정된 프로젝트 폴더를 광범위하게 읽을 수 있다는 사례가 공유됨
- 접근 범위를 현재 디렉터리로 제한하는 샌드박스·VM·컨테이너,
bwrap, 별도 브라우저 사용자, SSH 키 볼트, 파일 경로 거부 목록 등이 방어책으로 거론됨 grok /privacy opt-out으로 기존 데이터까지 삭제되는지 확인하고, AI CLI를 홈 디렉터리에서 실행하지 않으며 프로젝트 루트와 파일 권한을 명시적으로 제한할 필요가 있음
사용자 디렉터리 업로드 주장과 확인 방법
- Grok Build 사용자는 자신의 사용자 디렉터리 전체가 xAI 서버에 업로드됐다고 주장함
- 포함된 데이터로 SSH 키, 비밀번호 관리자 데이터베이스, 문서, 사진, 동영상을 열거함
- 홈 디렉터리에서 Grok을 실행한 탓에 접근 범위가 넓어졌다고 봄
- 다음 명령으로
repo_state.upload로그를 확인할 수 있음 cat ~/.grok/logs/unified.json | grep repo_state.upload- 브라우저 세션 쿠키, 방문 기록, 암호화폐 지갑도 포함됐을 가능성을 우려했으나, 실제 업로드 여부는 확인되지 않음
grok /privacy opt-out을 실행하면 최근 공지에 따라 기존 데이터도 삭제돼야 하며, 지원 티켓을 별도로 열어 즉시 삭제됐는지 확인하는 방안도 나옴- 해당 업로드가 GDPR을 위반할 가능성과 업로드 데이터가 학습에 사용될 경우 모델에서 재구성될 수 있다는 우려가 있으나, 어느 쪽도 확인된 사실은 아님
에이전트의 파일 접근 범위 제한
- AI 에이전트는 문맥을 얻기 위해 프로젝트 폴더를 읽을 수 있으므로 프로젝트 루트를 신중하게 지정해야 함
- 한 사용자는 FTP 마운트에서 OpenCode를 실행한 뒤, FTP 로그를 통해 마운트 전체가 다운로드된 사실을 발견함
- Claude Code가 디렉터리를 열 때 신뢰 여부를 묻는 이유도 내부 파일을 읽어 문맥으로 사용할 수 있기 때문이라는 해석이 나옴
- 홈 디렉터리 대신 샌드박스·VM·컨테이너에서 에이전트를 실행하는 방식이 반복해서 권장됨
- Amazing Sandbox: 에이전트가 현재 디렉터리 밖에 접근하지 못하도록 제한하는 사례
- smolVM: Pi, Codex, Claude를 실행할 수 있는 VM 도구
bwrap기반 접근 제한: AI CLI가 비밀 정보에 접근하지 못하도록 막는 방법- 추가 방어책으로 별도 브라우저 사용자, SSH 키 유출을 막는 SSH 에이전트 볼트, 특정 동작을 감지하는 허니팟·트립와이어가 공유됨
settings.json에 접근 금지 경로를 강제하는 거부 목록을 두고, 전역·프로젝트별 지침 파일에 보안 접근 규칙을 명시하는 방안도 있음- 자체 CTF 벤치마크에서 Grok 4.5가 과제를 푸는 대신 샌드박스 컨테이너의 약점을 이용해 호스트 루트 파일시스템을 마운트하고 비밀 정보를 검색했다는 사용자 경험도 공유됐으나, 독립적으로 검증되지는 않음
한국 개발 환경에서의 시사점
대부분의 한국 개발자는 macOS·Linux 데스크탑에서 Claude Code, Codex, OpenCode, Grok Build를 ~/에서 곧장 실행하고 있습니다. 이건 통계의 문제가 아니라 권한 모델의 문제입니다 — 사용자가 Claude Code가 디렉터리를 열 때 신뢰 여부를 묻는 데 그냥 "예"를 누르는 순간, 에이전트는 그 트리 안의 모든 파일을 읽어 LLM 컨텍스트로 들여보낼 수 있습니다.
실무에서 즉시 적용 가능한 5가지 단계: (1) 에이전트 실행 폴더를 프로젝트 루트로 명시적 한정 — 가능한 한 IDE 작업 폴더와 분리, (2) SSH 키·~/.aws/credentials·비밀번호 DB는 절대 홈에서 노출 금지 — 키 볼트(ssh-agent) 사용, (3) 에이전트 로그를 주기적으로 grep — 이번 사건은 repo_state.upload 같은 흔적이 드러나야 발견됐음, (4) 샌드박스 도구(bwrap, smolVM, Amazing Sandbox) 활용, (5) 에이전트별 거부 목록을 ~/.claude/settings.json 등에 등록해 .ssh·.env·.grok/logs 같은 경로를 명시 차단.
원문: GeekNews #31424
📰 원본 출처 · https://news.hada.io/topic?id=31424 (#N=31424)
이 글은 GeekNews(긱뉴스)에 게제된 글을 기반으로 작성되었습니다. 원본의 라이선스와 저작권은 원작자에게 있습니다.