ZCode는 조용히 전체 Git 이력을 알리yun OSS에 업로드합니다 – 조사 및 대응 방법
TL;DR
ZCode는 프로젝트 전체(완전한 .git 이력, LFS 캐시, 로컬 설정 포함)를 암호화하여 서버에서 제공하는 RSA 공개 키로 암호화한 후, 직접 알리yun OSS에 업로드합니다. 업로드는 로그인 중 언제나 발생하며, UI에서 비활성화할 수 없으며, 복호화 키는 오직 지푸(Zhipu)의 백엔드에만 존재하므로 서버 외에는 데이터를 읽을 수 없습니다.
업로드 방식 – 클라이언트 측 단계
클라이언트는 https://zcode.z.ai에서 일회용 RSA 공개 키와 OSS 폼 자격 증명을 먼저 획득한 후, AES-256-CTR 암호화와 RSA-OAEP 키 래핑을 거쳐 tar-gz 아카이브를 스트리밍하여 암호화된 파일을 직접 알리yun OSS에 게시합니다.
sequenceDiagram
participant C as ZCode 클라이언트
participant S as zcode.z.ai
participant O as 알리yun OSS
C->>S: POST /api/v1/snapshot/upload-credential
S-->>C: snapshot_id, RSA 공개 키, OSS 정책, 서명, 객체 키
C->>C: tar.gz → AES-256-CTR → RSA-OAEP 키 래핑
C->>O: POST multipart/form-data (tar.gz.enc)
O->>S: 수신 확인 콜백
- 단계 1 – 자격 증명 요청: 클라이언트는 ZCode 조정자에게 접속하여 동적 객체 키, 크기 제한, 해당 업로드 세션용 RSA 공개 키를 수신합니다.
- 단계 2 – 직접 OSS 업로드: 로컬 암호화 후 클라이언트는 ZCode 자체 서버를 우회하고 서명된 폼 POST를 통해 암호화된 콘텐츠(
*.enc)를 알리yun OSS로 스트리밍합니다. 이후 OSS는 지푸의 백엔드에 알립니다.
네트워크 캡처 결과, 이 과정 동안 zcode.z.ai와 두 개의 알리yun OSS 노드로 지속적인 HTTPS 연결이 존재하는 것으로 확인되었습니다.
사용자에게 단방향 암호화인 이유
RSA 키 쌍은 서버에서 생성되며, 클라이언트에게는 공개 키만 전달되므로 클라이언트(사용자)는 업로드된 아카이브를 절대 복호화할 수 없습니다.
{
"keyId": "String(i.encryption.key_version)",
"keyWrapAlgorithm": "rsa-oaep-sha256",
"publicKeySpkiPem": "Ylt(i.encryption.public_key)"
}
- 일시적인 대칭 키가 AES-256-CTR로 타르볼을 암호화합니다.
- 대칭 키는 서버에서 제공한 RSA-OAEP-SHA256 공개 키로 래핑됩니다.
- 개인 키는 사용자 기계에 절대 전달되지 않으므로, 디스크에 존재하는 300MB의 암호문은 로컬에서 읽을 수 없습니다.
"서버가 개인 키를 보유한 래핑 암호화는 로컬 백업을 원격 자산 추출로 전환합니다." – @xcc3641 (HN 댓글)
이 기능이 사용자 측 복원 또는 동기화를 위해 제공된 것이라면 개인 키는 Git이나 Time Machine처럼 로컬에 저장되었을 것입니다. 개인 키의 부재는 오직 서버가 언제든지 데이터를 읽을 수 있도록 하기 위한 목적임을 시사합니다.
실제로 업로드되는 내용 – 분석
업로드된 페이로드의 약 87%는 .git 데이터이며, 서버는 전체 커밋 이력, LFS 객체, 참조 로그, 심지어 삭제된 시크릿까지 수신합니다.
| 경로 | 크기 | 페이로드 비율 | 내용 |
|---|---|---|---|
.git/lfs/ |
196.1 MB | 56.8 % | 모든 LFS 캐시된 바이너리 및 미디어 |
.git/objects/ |
102.2 MB | 29.6 % | 완전한 객체 저장소 (커밋, 트리, 블롭) |
.git/logs/ |
0.6 MB | 0.2 % | 참조 로그 – 로컬 브랜치 이동 |
| 소스 파일 및 문서 | ~46.2 MB | 13.4 % | src/, 설정 파일, 문서 |
암호화된 아카이브 자체는 읽을 수 없지만, 평문으로 저장된 매니페스트(42,411개 항목)는 디렉터리 구조를 노출합니다.
UI 전환기능은 업로드를 정지하지 않습니다
"경험 최적화"와 "저장소 스냅샷 인덱싱" 전환기능은 모두 서버 측 처리에만 영향을 미치며, 캡처 및 업로드 사이드카는 시작 시 조건부로 실행됩니다.
| 전환기능 | 의도된 효과 | 실제 효과 |
|---|---|---|
optimizeAgentExperienceEnabled |
태레메트리 비활성화 | 여전히 스냅샷 캡처 및 업로드; 모델 훈련 동의만 비활성화 |
repoSnapshotIndexingEnabled |
스냅샷 기능 비활성화 | 업로드 계속; 서버 측 인덱싱만 중단 |
클라이언트는 모든 LLM 프롬프트 전에 captureBeforePrompt를 호출하며, repo-wiki-update 라벨이 붙은 작업 완료 이벤트에도 호출합니다. 한 세션에서 최대 62건까지 캡처 이벤트가 발생할 수 있습니다.
개인정보 정책 누락
공식 ZCode 개인정보 정책은 "대화 중 제출된 텍스트, 파일, 코드"의 수집을 언급하지만, 자동으로 전체 워크스페이스 스냅샷 및 Git 이력 업로드를 공개하지 않습니다. 관련 조항은 유사한 설명으로, 최적화는 기본적으로 비활성화되며, 동의 없이 데이터를 훈련에 사용하지 않는다는 내용뿐입니다.
커뮤니티 반응 및 공식 답변
- 여러 사용자가 다른 AI 에이전트가 점 파일과 무시 파일을 읽는 유사한 행동을 보인다고 지적했습니다 (예: @philbo).
- @acrispino는 지푸의 공개 사과를 공유했으며, 이 기능은 초기 출시 버그로 "코드베이스 인덱싱" 기능과 연결되어 있으며, 위키 생성 후 업로드된 데이터는 즉시 삭제되며 문제는 해결되었다고 주장했습니다.
- 다른 사용자들은 신뢰 상실을 표현하고, 샌드박스 또는 격리 전략을 제안했습니다 (예: @radio879의 광범위한 샌드박스 논의).
기계에서 업로드를 중단하는 방법
보류 중인 아카이브를 삭제하면 새로운 캡처가 트리거되므로, 신뢰할 수 있는 대응 방법은 파일 시스템 수준에서 ~/.zcode/v2/checkpoints 디렉터리를 불변으로 설정하는 것입니다.
macOS
rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
chflags uchg ~/.zcode/v2/checkpoints # 불변 플래그 설정
# 확인: touch 명령은 "작업이 허용되지 않음" 오류 발생
Linux
rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
sudo chattr +i ~/.zcode/v2/checkpoints # 불변 속성 설정
# 확인: touch 명령은 "작업이 허용되지 않음" 오류 발생
영향: 체크포인트/롤백 UI는 더 이상 작동하지 않으며, 이는 업로드된 스냅샷에 의존하기 때문이지만, 일반적인 채팅, 자동 완성, 도구 실행은 정상적으로 작동합니다. 기능을 복원하려면 불변 플래그를 제거하세요 (chflags nouchg on macOS 또는 chattr -i on Linux).
결론
- ZCode는 전체 워크스페이스(완전한 Git 이력 포함)를 자동으로 캡처하고 암호화하여 클라우드 버킷에 업로드합니다.
- 암호화 키는 지푸의 서버에만 보유되어 있어 오직 그들만이 데이터를 복호화할 수 있습니다.
- UI 설정으로 이 기능을 비활성화할 수 없으며, 로그인 중 언제나 작동합니다.
- 개인정보 정책은 이 행동을 공개하지 않아 신뢰 및 준수 문제를 야기합니다.
- 사용자는
checkpoints디렉터리를 불변으로 설정함으로써 로컬에서 업로드를 차단할 수 있지만, ZCode의 스냅샷-복원 기능을 잃게 됩니다.
"저장소 위키 기능이 위키 페이지를 생성하면 저장소 데이터의 업로드가 트리거될 수 있습니다. 위키 페이지가 클라우드에서 생성된 후, 업로드된 데이터는 즉시 파괴되며 저장되지 않습니다." – @acrispino가 인용한 지푸의 성명
권고: 공급업체가 투명하고 선택적 제어를 제공하며 복호화 키를 로컬에 저장하지 않는 한, ZCode를 데이터 유출 위험으로 간주하세요. AI 에이전트를 샌드박싱하거나, 명확하고 사용자 제어 가능한 데이터 처리 정책을 가진 도구를 고려하세요.
Sources
관련
- Dispatch
- Dispatch
- Dispatch
- Dispatch
- 프로젝트