SpaceXAI의 Grok Build 코딩 도구가 보안 연구원에 의해 CLI가 코딩 작업에 필요한 파일만 전송하는 대신 전체 Git 저장소를 클라우드 스토리지에 업로드한다는 사실이 밝혀지며 조사를 받고 있습니다. 보고서에 따르면, 업로드된 데이터에는 ...
SpaceXAI의 Grok Build 코딩 도구가 최근 보안 연구원에 의해 조명을 받았다. 해당 연구원은 이 CLI(명령줄 도구)가 코딩 작업에 필요한 파일만 전송하는 것이 아니라 전체 Git 저장소를 클라우드 스토리지에 업로드한다는 사실을 발견했다.
보도에 따르면, 업로드된 데이터에는 추적된 파일, 전체 Git 히스토리, 에이전트가 읽지 말라고 지시받은 파일, 그리고 현재 작업 트리에서 삭제되었으나 이전 커밋에 여전히 남아 있는 기밀 정보가 포함되어 있었다. 데이터는 xAI가 관리하는 Google Cloud Storage 버킷으로 전송되었다.
조사 결과가 공개된 후, 업로드 행위는 중단되었다. 연구원은 SpaceXAI의 서버가 다음과 같은 응답을 반환하기 시작한 것을 관찰했다:
코드베이스 업로드 비활성화: true
일론 머스크는 또한 이전에 업로드된 사용자 데이터가 완전히 삭제될 것이라고 밝혔다. 그러나 사건이 보도될 당시, 모든 과거 사본이 제거되었는지 여부를 공개적으로 독립적으로 확인할 수는 없었다.
이 사건은 Grok Build CLI에 대한 통제된 네트워크 분석에서 시작되었다.
별칭 Cereblab을 사용하는 연구원은 공식 바이너리를 리버스 엔지니어링하고 네트워크 트래픽을 모니터링했다. 이 도구의 실제 데이터 흐름을 밝히기 위한 테스트에서 Grok Build는 저장소를 Git 번들로 패키징하여 xAI와 연결된 Google Cloud Storage 버킷에 업로드했다.
이는 프롬프트에 응답하는 데 필요한 소수의 파일에만 국한되지 않았다.
보도에 따르면, 캡처된 번들에는 다음이 포함되어 있었다:
원본 AIbase 보고서는 그 보존 범위가 Claude Code와 같은 유사한 AI 코딩 도구보다 훨씬 더 광범위하다고 설명했다.
Axios가 보도한 테스트에서 Grok Build는 약 5.1GB의 데이터를 업로드한 반면, 코딩 작업 자체는 약 192KB만 필요했다. 이 예는 작업 관련 컨텍스트 전송과 전체 저장소 아카이브 전송 간의 차이를 보여준다.
현재 소스 트리를 업로드하는 것만으로도 이미 심각한 보안 사건이다. 전체 Git 히스토리를 업로드하는 것은 훨씬 더 큰 피해를 초래할 수 있다.
개발자는 종종 저장소의 최신 버전에서 기밀 정보를 삭제하고 사라졌다고 생각한다. 실제로는 히스토리가 다시 작성되지 않는 한 해당 값이 이전 커밋에 여전히 남아 있을 수 있다.
Git 히스토리에는 다음이 포함될 수 있다:
따라서 저장소는 현재 작업 디렉토리에서는 깔끔해 보일 수 있지만, 민감한 자료는 여전히 .git 디렉토리 내에 남아 있을 수 있다.
이것이 도구가 Git 수준에서 저장소를 별도로 패키징할 때 "이 파일을 열지 마십시오"와 같은 지시만으로는 충분한 보호를 제공할 수 없는 이유이다. 파일 수준 권한 지시는 모델 대화 중 에이전트가 읽는 내용을 제어할 수 있지만, 별도의 업로드 프로세스가 저장소 히스토리를 패키징하는 것을 자동으로 막을 수는 없다.
Cereblab의 분석에 따르면 대상은 xAI가 관리하는 Google Cloud Storage 버킷이었다.
Google Cloud를 사용한다고 해서 Google이 저장소 수집을 독립적으로 결정한 것은 아니다. 클라우드 스토리지 제공자는 고객을 위해 인프라를 호스팅하며, 이 사건의 관련 데이터 통제자 또는 서비스 운영자는 xAI 또는 SpaceXAI인 것으로 보도되었다.
핵심 문제는 저장소 데이터가 사용자의 머신을 떠나 제3자 클라우드 인프라로 이동했다는 점이다.
기업 팀의 경우, 이는 다음과 같은 문제를 야기할 수 있다:
클라우드 제공자 자체가 강력한 보안 통제를 갖추고 있더라도, 공개되지 않거나 예상치 못한 전송은 회사 자체의 거버넌스 요구 사항을 위반할 수 있다.
조사가 공개된 후, Cereblab은 CLI를 다시 테스트했다.
서버가 반환한 내용:
disable_codebase_upload: true
전체 저장소 업로드가 더 이상 트리거되지 않았다.
이는 서버 측 변경인 것으로 보인다. 사용자가 행위가 중단되기 전에 새 버전을 설치할 필요가 없었기 때문이다. 원격 구성 플래그가 저장소 패키징 프로세스를 비활성화했다.
이 차이는 중요하다.
서버 측 스위치는 행위를 신속하게 중단시킬 수 있지만, 클라이언트의 데이터 처리 행위가 원격 구성에 의존할 수 있음을 시사한다. 따라서 코딩 에이전트를 평가하는 조직은 로컬 버전 번호나 정적 설정 화면에만 의존하지 말고 실제 네트워크 트래픽을 검증해야 한다.
일론 머스크는 공개적으로 변경 전에 업로드된 모든 사용자 데이터가 "완전히 철저히" 삭제되어 어떠한 흔적도 남지 않을 것이라고 응답했다.
SpaceXAI는 또한 개인정보 보호 선택을 존중할 것이며, 데이터 제로 보존 약정을 적용받는 고객의 추적 데이터나 코드 데이터는 보존되지 않을 것이라고 밝혔다.
이는 중요한 약속이지만, 보도 시점에 여전히 몇 가지 미해결 질문이 남아 있다:
삭제는 미래의 위험을 완화할 수 있지만, 이는 모든 보안 문제를 자동으로 해결하지는 않는다. 저장소에 활성 자격 증명이 포함되어 있었다면, 사용자는 해당 값이 로컬 환경을 벗어났을 수 있다고 가정하고 즉시 순환시켜야 한다.
/privacy 명령이 진정한 수정 사항이 아닌 이유SpaceXAI는 처음에 사용자에게 Grok Build CLI 명령을 안내했다:
/privacy
공식 Grok Build 문서는 /privacy를 개인정보 보호 및 데이터 보존 상태를 표시하거나 변경하는 명령으로 설명한다.
보안 연구원은 이 설정이 전체 저장소 번들 전송 메커니즘이 아닌 보존 행위를 제어한다는 것을 발견했다. 즉, 이 명령은 데이터를 수신한 후 SpaceXAI의 보존 작업에만 영향을 미칠 수 있을 뿐, 저장소가 로컬 머신을 떠나는 것을 막는 서버 측 메커니즘이 아니다.
Cereblab의 결론은 매우 명확했다:
/privacy는 세션 수준의 보존 제어이다.disable_codebase_upload가 활성화된 후에만 저장소 업로드가 중단된다.이는 이 사건에서 얻을 수 있는 가장 중요한 교훈 중 하나이다.
| 제어 문제 | 의미 |
|---|---|
| 데이터가 장치를 떠나는가? | 전송 또는 업로드 제어 |
| 수신된 데이터가 저장되는가? | 보존 제어 |
| 저장 기간은 얼마인가? | 보존 기간 정책 |
| 모델 훈련에 사용되는가? | 훈련 용도 정책 |
| 사용자가 데이터를 삭제할 수 있는가? | 삭제 제어 |
| 사용자가 삭제를 확인할 수 있는가? | 감사 및 보증 제어 |
서비스는 데이터를 보존하지 않겠다고 약속하면서도 실시간 처리를 위해 데이터를 전송할 수 있다. 이는 명시적으로 문서화된 기업 계약 하에서는 수용 가능할 수 있지만, 데이터를 로컬에 유지하는 것과는 동일한 개념이 아니다.
사용자는 제품이 명시적으로 그러한 보증을 하지 않는 한 "데이터 제로 보존"을 "데이터 제로 전송"과 동일시해서는 안 된다.
xAI의 API 보안 문서는 제로 데이터 보존(ZDR)을 엔터프라이즈급 기능으로 설명합니다.
API 팀이 ZDR을 활성화하면, xAI는 프롬프트, 완성 내용 및 관련 메타데이터가 실시간으로 처리되지만 서버에 지속적으로 저장되지는 않는다고 밝힙니다. 문서는 또한 API 응답에 x-zero-data-retention 헤더가 포함되어 애플리케이션이 ZDR이 적용되고 있는지 확인할 수 있도록 한다고 설명합니다.
ZDR이 활성화되지 않은 표준 API 사용 시나리오의 경우, xAI는 요청과 응답이 오용 및 남용 감사를 위해 최대 30일 동안 임시 저장될 수 있다고 밝힙니다.
이러한 API 정책은 참고할 만하지만, 각 조직은 모든 Grok 제품, CLI 추적, 파일 전송 채널 또는 소비자 계정이 동일한 데이터 수명 주기를 따른다고 자동으로 가정해서는 안 됩니다.
Grok Build를 사용하여 비공개 리포지토리를 처리하기 전에 다음 사항을 확인하십시오:
독립적인 보안 연구원인 Lukasz Olejnik 박사는 데이터 규모에 대해 설명합니다——
데이터 보존 기간이 너무 깁니다.
유출될 수 있는 정보는 다음과 같습니다:
위험은 악의적인 사용에만 국한되지 않습니다.
대규모 코드 아카이브는 또한 다음과 같은 경로를 통해 유출될 수 있습니다:
데이터 최소화 원칙은 공격 표면을 줄이는 것을 목표로 합니다. 소수의 파일만 필요할 때 전체 리포지토리를 기본적으로 업로드하는 것은 이 원칙과 일치하기 어렵습니다.
업로드 기능이 비활성화되기 전에 Grok Build를 사용한 팀은 잠재적인 소스 코드 유출 사고에 대응하는 것처럼 조치를 취해야 합니다.
Grok Build가 실행된 위치를 확인하십시오.
기록:
에이전트가 열어본 것으로 보이는 파일로만 검사 범위를 제한하지 마십시오.
조직에서 승인한 키 스캐닝 도구를 사용하여 현재 브랜치 내용뿐만 아니라 전체 기록을 확인하십시오.
찾을 항목:
비밀이 최신 커밋에서 삭제되었더라도 여전히 교체가 필요할 수 있습니다.
영향을 받은 기간 동안 추적된 리포지토리 기록의 어느 위치에 자격 증명이 존재했다면, 이를 취소하거나 교체하십시오.
아이디어를 한 문장으로 입력하면 We0 AI가 쇼케이스 사이트, 페이지, CMS를 생성하고 출시 후 고객과 트래픽 확보를 돕습니다.
무료 등록을 위한 하나의 완전한 프로젝트 생성
하나의 완전한 생성 흐름을 시도하고 첫 번째 프로젝트 초안을 빠르게 보는 데 가장 적합합니다.
업로드된 복사본에 누군가 접근했다는 증거를 기다리지 마십시오. 자격 증명 교체는 일반적으로 사고 발생 후 침해를 조사하는 것보다 비용이 적게 듭니다.
다음과 같은 권한을 제공하는 자격 증명을 우선적으로 처리하십시오:
리포지토리가 Grok Build와 함께 사용된 후 클라우드, 소스 코드 관리, CI/CD, 데이터베이스 및 내부 서비스 로그에서 비정상적인 활동을 확인하십시오.
찾을 항목:
의심스러운 활동이 없다고 해서 데이터가 유출되지 않았다는 증명이 되는 것은 아니지만, 현재 위험을 평가하는 데 도움이 됩니다.
최신 버전의 Grok Build를 사용하고 활성 구성을 확인하십시오.
공식 문서는 다음을 제공합니다:
grok inspect
이 명령은 어떤 구성 소스가 로드되고 있는지 확인하는 데 도움이 됩니다.
CLI는 또한 다음을 제공합니다:
/privacy
이것을 사용하여 보존 상태를 확인하되, 이 명령을 증거로 간주해서는 안 됩니다.
어떤 데이터도 기기를 떠나지 않습니다.
엔터프라이즈 사용자는 다음을 포함하는 서면 답변을 요청해야 합니다:
공개된 삭제 약속은 도움이 되지만, 규제 대상 조직은 계정별 증거가 필요할 수 있습니다.
리포지토리에 고객 코드, 개인 데이터, 규제 정보 또는 비밀 유지 계약에 해당하는 내용이 포함된 경우, 관련 내부 팀을 참여시키십시오.
상황에 따라 관련 팀은 다음과 같습니다:
뉴스 보도만으로 위반 통지 결정을 내리지 마십시오. 조직 자체의 노출 사실과 적용 가능한 법률에 따라 판단하십시오.
이번 사건은 AI 개발 도구 분야의 광범위한 문제를 부각시킵니다.
코딩 에이전트는 일반적으로 대규모 리포지토리 검색, 명령 실행, 문서 읽기 및 파일 수정을 위해 광범위한 액세스 권한을 필요로 합니다. 이러한 능력은 거대한 개인정보 보호 경계를 형성합니다.
코딩 어시스턴트를 승인하기 전에 팀은 다섯 가지 측면을 평가해야 합니다.
도구가 수집할 수 있는 모든 데이터 유형을 기록하십시오:
실제로 머신을 떠나는 내용을 테스트하십시오.
공급업체 문서는 필요하지만, 네트워크 동작이 실제 전송에 대한 가장 강력한 증거입니다.
무해한 카나리 값을 포함하는 격리된 테스트 리포지토리를 사용한 다음 다음을 확인하십시오:
관련 없는 프로젝트의 디렉토리에서 도구를 실행하지 마십시오.
다음을 우선 선택하십시오:
엔터프라이즈 배포의 경우 다음을 확인하십시오:
도구의 동작은 자동 업데이트 또는 원격 구성 변경으로 인해 변경될 수 있습니다.
다음과 같은 경우 후에 다시 테스트하십시오:
제품이 빠르게 변화할 때 보안 승인은 영구적이어서는 안 됩니다.
에이전트 지시는 모델 또는 도구 사용 계층에서 실행됩니다. 별도의 원격 측정 또는 동기화 구성 요소는 이러한 지시를 해석하지 않을 수 있습니다.
개인정보 보호 제어는 데이터 파이프라인 자체에 존재해야 합니다.
공급업체는 필요한 컨텍스트만 전송한다고 주장할 수 있지만, 엔터프라이즈 사용자는 증거가 필요합니다.
유용한 보장 사항은 다음과 같습니다:
원격 구성은 업로드를 신속하게 중지할 수 있지만, 사용자가 중요한 동작이 언제 변경되었는지 모를 수도 있음을 의미합니다.
성숙한 대응에는 다음이 포함되어야 합니다:
SpaceXAI가 모든 저장된 복사본을 삭제하더라도, 업로드된 리포지토리에 포함된 모든 자격 증명은 노출 위험에 따라 처리되어야 합니다.
삭제는 공급업체 복사본에 대한 향후 액세스를 보호하지만, 자격 증명 자체를 변경하지는 않습니다.
Cereblab의 프로토콜 레벨 분석에 따르면, CLI는 현재 코딩 작업과 관련 없는 파일 및 커밋 기록을 포함하여 추적된 전체 Git 저장소를 번들로 업로드합니다. 이 기록에는 현재 작업 디렉토리에서 이미 제거된 키가 포함될 수 있습니다.
캡처된 트래픽에 따르면, xAI가 관리하는 Google Cloud Storage 버킷에 업로드됩니다. Google Cloud는 인프라 제공자이며, 관련 제품 및 데이터 처리 결정은 SpaceXAI에 귀속됩니다.
연구원들은 이후 서버에서 disable_codebase_upload: true를 반환하는 것을 확인했으며, 그 이후로 전체 저장소 업로드가 더 이상 트리거되지 않았습니다. 이 변경은 서버 측에서 이루어진 것으로 보입니다.
/privacy 명령어로 저장소 업로드를 막을 수 있나요?해당 명령어는 개인정보 보호 및 보존 설정을 제어하지만, Cereblab은 전체 저장소 업로드를 중단하는 메커니즘이 아니라고 보고했습니다. 사용자는 전송을 차단하는 것과 전송 후 보존을 제한하는 것을 구분해야 합니다.
네. 머스크는 이전에 업로드된 모든 사용자 데이터를 완전히 삭제하겠다고 공개적으로 밝혔습니다. 보도 시점 기준, 완전 삭제에 대한 독립적인 검증은 아직 공개되지 않았습니다.
Grok Build를 사용할 때 키가 추적된 저장소 또는 그 Git 기록에 존재했다면, 키 교체는 신중한 대응입니다. 공급업체에 저장된 복사본을 삭제한다고 해서 자격 증명이 노출되거나 액세스된 적이 없다는 것을 보장하지는 않습니다.
xAI는 ZDR을 엔터프라이즈 API 기능으로 설명하며, 입력과 출력을 영구 저장하지 않고 처리합니다. 이것이 반드시 데이터가 로컬 장치를 떠나지 않는다는 것을 의미하지는 않으며, 조직은 어떤 Grok Build 데이터 채널이 적용되는지 확인해야 합니다.
보고된 전체 저장소 업로드 기능은 비활성화되었지만, 각 조직은 현재 버전, 설정, 계정 약관, 네트워크 동작 및 저장소 민감도를 평가해야 합니다. 서버 측 수정이 내부 보안 검토를 대체하지는 않습니다.
/privacy를 포함합니다.Grok Build는 작업에 소량의 코드만 필요하더라도, 추적된 전체 Git 저장소와 전체 기록을 xAI가 관리하는 Google Cloud Storage 버킷에 업로드하는 것으로 밝혀졌습니다.
SpaceXAI는 서버 측 disable_codebase_upload 플래그를 통해 저장소 업로드 기능을 비활성화했으며, 일론 머스크는 이전에 업로드된 데이터를 삭제하겠다고 약속했습니다. /privacy 명령어는 보존 설정과 관련이 있지만, 저장소 전송을 차단하는 제어 수단은 아닙니다.
영향을 받은 CLI를 사용하는 개발자는 관련 저장소를 식별하고, 전체 Git 기록을 스캔하며, 노출 가능성이 있는 자격 증명을 교체하고, 로그를 검토하며, 필요한 경우 계정별 삭제 정보를 요청해야 합니다.
핵심 교훈은 간단합니다: AI 코딩 도구의 개인정보 보호는 프롬프트, 보존 레이블 또는 설정 인터페이스가 아닌 데이터 전송 수준에서 검증되어야 합니다.
