Z.ai의 GLM 코딩 에이전트 ZCode, 사용자의 전체 Git 기록을 몰래 업로드하다

베이징 기업 Z.ai(GLM 오픈웨이트 모델 개발사)의 AI 코딩 데스크톱 앱 ZCode는 로그인만 하면 전체 워크스페이스를 조용히 패키징해 업로드한다. 여기에는 .git 기록, LFS 자산 캐시, reflog, 글로벌 앱 설정이 포함되며, 암호화되어 Aliyun OSS(알리바바 클라우드 객체 스토리지)로 전송된다. 이 사실은 2026년 9월 18일 개발자 ferstar가 공개한 리버스 엔지니어링 분석에서 밝혀졌다.

실제로 패키징되는 항목

패키징 매니페스트는 로컬에 평문으로 저장된다. 42,411개 파일 스냅샷 한 건에 대해 ferstar는 345MB 상용 워크스페이스에서 생성된 313MB 암호화 아카이브를 캡처했다:

• .git/lfs/ — 196.1 MB (56.8%)
• .git/objects/ — 102.2 MB (29.6%)
• .git/logs/ — 0.6 MB (0.2%)
• 소스 코드 및 문서 — 46.2 MB (13.4%)

.git 디렉터리만 전체 페이로드의 86.6%를 차지한다. git 객체 저장소는 작업 트리 스냅샷이 아니라 저장소의 전체 계보다. 이후 커밋에서 삭제된 API 키, 푸시되지 않은 브랜치 이름, .git/config의 내부 호스트명과 저장소 경로가 모두 포함된다. 조사 중 564건의 업로드 실패 시도가 기록되었다.

암호화 키는 Z.ai 클라우드에만 존재

ZCode는 봉투 암호화(envelope encryption)를 사용한다. 페이로드는 대칭 키로 암호화되고, 그 대칭 키는 업로드 자격 증명 협상 중 서버가 전달한 RSA-OAEP 공개 키로 래핑된다. 대응하는 개인 키는 Z.ai 클라우드에만 있다. ferstar는 로컬 시스템의 모든 개인 키로 아카이브를 풀려고 시도했지만 실패했다. 사용자 디스크에 있는 313MB 암호문은 사용자나 ZCode 클라이언트 모두 복호화할 수 없다.

app.asar에서 드러난 업로드 파이프라인

1. 클라이언트가 zcode.z.ai에 자격 증명을 요청하면 OSS 폼 서명, 객체 키, 크기 제한, 라운드별 RSA 공개 키가 반환된다.
2. 클라이언트가 워크스페이스를 tar.gz로 패키징하고 AES-256-CTR로 암호화한 뒤 대칭 키를 래핑한다.
3. 클라이언트가 아카이브를 Aliyun OSS에 직접 POST하면, OSS가 Z.ai 백엔드에 콜백해 스냅샷을 등록한다.

테스트 중 실행 중인 클라이언트는 zcode.z.ai와 Aliyun OSS 노드 두 곳에 지속적 연결을 유지했다.

설정 토글로는 막을 수 없다

• Optimize Experience (optimizeAgentExperienceEnabled) — 데이터를 모델 학습에 사용하도록 허가할지 여부만 제어한다. 스냅샷 캡처와 업로드는 계속된다.
• Repo Snapshot Indexing (repoSnapshotIndexingEnabled) — 서버가 업로드된 스냅샷을 인덱싱할지 여부만 제어한다. 로컬 패키징과 업로드는 계속된다.

ferstar는 캡처 사이드카가 시작 시 무조건 인스턴스화되며 사용자 환경설정에 대한 게이팅이 전혀 없다는 사실을 발견했다. 유일한 요구 사항은 토큰 제공자가 유효한 JWT를 생성할 수 있어야 한다는 것뿐이다. 세션 로그에는 단일 활성 세션에서 62건의 캡처 이벤트가 기록되었으며, 이는 매 프롬프트 전과 작업 완료 시 트리거되었다.

짚고 넘어갈 혼동

이 이슈가 퍼진 이유 중 하나는 — ferstar의 게시물 조회수 276,000회, FeiZ의 중국어 경고 조회수 63,800회 — 사람들이 GLM 가중치와 ZCode 하네스를 혼동하기 때문이다. 가중치는 오픈웨이트다. ZCode는 클로즈드 소스이며 Z.ai의 자사 하네스다. Petri Kuittinen의 인용 답변: "내 조언은 항상 같았다: 클로즈드 소스 AI 하네스를 신뢰하지 마라." Ollama나 llama.cpp로 GLM을 로컬에서 실행한다면 ZCode를 쓰는 게 아니다. 하지만 같은 GLM 모델을 쓰려고 데스크톱 앱을 설치했다면 ZCode를 쓰는 것이다.