ZCode Git 기록 업로드, 코딩 편의성을 신뢰 문제로 바꾸다

ZCode가 데이터 수집을 제한하는 것처럼 보이는 설정에도 불구하고 Git 기록을 포함한 345MB 규모의 개발자 워크스페이스 전체를 업로드했다는 주장이 제기됐다. 보고된 ZCode Git 기록 업로드는 AI 프롬프트용으로 선택된 파일에만 국한되지 않았다. 여기에는 수년간의 비공개 엔지니어링 작업을 보존할 수 있는 저장소 객체, reflog, 캐시된 대용량 파일이 포함됐다.

9월 18일 공개된 기술 조사는 ZCode의 폐쇄형 데스크톱 애플리케이션을 분석해 이 동작을 추적했다. 해당 분석에 따르면, 사용자가 로그인한 상태에서 클라이언트는 암호화된 워크스페이스 체크포인트를 만들고 이를 Alibaba Cloud Object Storage Service로 전송했다.

이 발견은 Z.ai가 독립 감사를 거쳐 공개한 내용이 아니라 제3자의 리버스 엔지니어링 주장에 머물러 있다. 게시 시점 기준으로 공개된 공식 자료는 보고된 업로드 범위, 체크포인트 보존 기간, 또는 사용자가 이를 막을 수 있는 방법을 명확히 설명하지 않았다.

이 검증 공백 자체가 이야기의 일부다. ZCode는 워크스페이스를 이해하고, 명령을 실행하며, 장기 작업을 복구하도록 설계된 에이전트와 함께 GLM 모델을 홍보한다. 하지만 오픈 웨이트 모델이라고 해서 이를 둘러싼 데스크톱 애플리케이션까지 투명해지는 것은 아니다.

따라서 핵심 충돌은 ZCode와 다른 코딩 어시스턴트 간의 비교가 아니다. 제품에 보이는 개인정보 보호 제어와 숨겨진 체크포인트 시스템에 귀속된 동작 사이의 문제다.

ZCode Git 기록 업로드 보고서가 발견한 내용

조사는 ZCode가 단일 모델 요청에 필요한 코드만이 아니라 저장소 아카이브를 수집했다고 주장한다.

연구자는 42,411개 파일을 포함한 비공개 상용 워크스페이스를 조사했다. 원본 디렉터리는 약 345MB였으며, ZCode의 암호화된 체크포인트는 약 313MB였다.

보고된 내용물은 특히 주목할 만했다. 약 196.1MB는 Git Large File Storage가 대형 프로젝트 자산을 캐시할 수 있는 .git/lfs 디렉터리에서 나왔다. 또 다른 102.2MB는 파일 내용, 디렉터리 트리, 커밋을 담는 Git의 기반 데이터베이스인 .git/objects에서 나왔다.

Reflog는 약 0.6MB를 차지했다. 현재 소스 파일, 구성 및 문서는 약 46.2MB, 즉 측정된 자료의 13.4%였다.

해당 개별 스냅샷에서 .git 디렉터리는 아카이브 데이터의 86.6%를 차지했다. 이는 모든 ZCode 설치 환경의 평균을 입증하지는 않는다. 그러나 이 사건을 일상적인 코드 업로드라고 부르는 것이 왜 보고된 범위를 축소하는지 보여준다.

원문 보고서에 따르면, ZCode는 로컬 애플리케이션 데이터 아래에 체크포인트를 만들고 암호화된 아카이브 옆에 평문 매니페스트를 남겼다. 이 매니페스트는 영향을 받은 워크스페이스의 절대 경로를 노출한 것으로 전해진다.

리버스 엔지니어링 결과에 따르면, ZCode는 Z.ai 서비스에서 업로드 자격 증명을 요청했다. 응답에는 객체 키, 서명된 업로드 양식, 크기 제한 및 RSA 공개 키가 포함됐다.

클라이언트는 워크스페이스를 압축하고 AES-256-CTR로 암호화한 뒤 RSA-OAEP-SHA256을 사용해 대칭 키를 래핑한 것으로 알려졌다. 이후 암호화된 객체를 Aliyun 스토리지 엔드포인트에 직접 전송했다.

전송이 완료된 뒤 콜백이 Z.ai의 백엔드에 이를 알린 것으로 보고됐다. 이 재구성이 정확하다면, 해당 업로드는 과도한 컨텍스트를 포함한 우발적 모델 요청이 아니라 설계된 애플리케이션 흐름이었다.

암호화가 공개 문제를 해결하는 것은 아니다. 구현이 올바르다는 전제에서, 암호화는 컴퓨터와 스토리지 서비스 사이의 관찰자로부터 데이터를 보호한다. 하지만 의도된 서비스 운영자가 정보에 접근하는 것을 막지는 않는다.

보고서는 일치하는 RSA 개인 키가 서버 측 통제 아래에 남아 있었다고 말한다. 따라서 저장소를 제공한 사용자는 같은 컴퓨터에 저장된 체크포인트를 복호화하거나 검사할 수 없었다.

이 구분은 중요하다. “암호화됨”은 “벤더가 접근할 수 없음”처럼 들릴 수 있지만, 두 표현은 동등하지 않다. 암호화는 관련 키를 누가 통제하는지에 따라 데이터를 보호한다.

보고서는 또한 눈에 보이는 두 가지 개인정보 보호 설정이 체크포인트 생성이나 전송을 막지 못했다고 주장한다. 이 주장은 독립적인 제품 감사를 통해 확인되지 않았으며, 한 Hacker News 참여자는 해당 체크포인트 디렉터리를 찾지 못했다고 보고했다.

이 차이는 제품 버전, 운영체제, 계정 상태, 단계적 배포 또는 특정 기능 사용을 반영할 수 있다. 원래 사례가 모든 사용자에게 적용되지 않는다는 의미일 수도 있다.

Z.ai는 이러한 조건을 명확히 설명해야 한다. 그때까지 가장 안전한 설명은 연구자들이 최소 하나의 테스트 환경에서 이 동작을 문서화했지만, 전체 확산 범위는 여전히 알려지지 않았다는 것이다.

전체 .git 디렉터리가 현재 코드보다 더 민감한 이유

Git 저장소에는 현재 파일에 더 이상 나타나지 않는 정보를 포함해 프로젝트의 기억이 담겨 있다.

개발자들은 흔히 .git을 “기록”이라고 설명하지만, 여기에는 git log의 출력보다 더 많은 것이 들어 있다. 객체, 참조, 브랜치 정보, 구성, reflog 및 기타 저장소 메타데이터가 저장된다.

Git은 본질적으로 콘텐츠 주소 지정 데이터베이스다. blob 객체는 파일 내용을 보존하고, tree 객체는 디렉터리 상태를 설명하며, commit 객체는 스냅샷을 기록으로 연결한다.

공식 Git 객체 모델은 이러한 요소가 .git/objects 안에 어떻게 남아 있는지 설명한다. 해당 디렉터리를 복사하는 애플리케이션은 작업 트리에 보이는 파일보다 훨씬 많은 정보를 받을 수 있다.

개발자가 월요일에 실수로 API 자격 증명을 커밋한 뒤 화요일에 삭제했다고 생각해 보자. 현재 파일에는 더 이상 자격 증명이 표시되지 않지만, 이전 객체는 저장소 기록을 통해 계속 접근 가능할 수 있다.

최신 사본을 삭제하는 것만으로는 충분하지 않다. GitHub의 민감한 데이터 제거 지침은 개발자에게 먼저 노출된 자격 증명을 폐기한 뒤, 조율된 기록 재작성을 검토하라고 안내한다.

같은 문제는 비공개 인증서, 내부 호스트명, 고객 식별자, 환경 파일 및 테스트 픽스처에 포함된 자격 증명에도 적용된다. 저장소는 폐기된 아키텍처, 보안 수정 사항, 미출시 제품 및 라이선스 자료도 보존할 수 있다.

Reflog는 위험을 더 확장한다. 로컬 참조가 어떻게 이동했는지를 기록하며, 공유 브랜치에서는 더 이상 보이지 않는 커밋에 대한 접근 경로를 보존할 수 있다.

로컬 브랜치는 한 번도 푸시되지 않은 계획을 드러낼 수 있다. 커밋 메시지는 고객, 취약점, 직원 또는 내부 사고의 이름을 담을 수 있다. 저장소 구성은 비공개 원격 저장소와 인프라 도메인을 식별할 수 있다.

Git LFS는 또 다른 범주를 만든다. 그 캐시에는 설계 파일, 데이터세트, 미디어, 패키징된 모델 또는 개발자가 어시스턴트의 즉각적인 컨텍스트 밖에 있다고 합리적으로 여기는 기타 바이너리가 포함될 수 있다.

따라서 보고된 196.1MB 규모의 LFS 구성 요소는 중요하지 않은 대용량 데이터가 아니었다. 프로젝트에서 텍스트 형태가 가장 적고 상업적으로 가장 민감한 자료 일부를 나타낼 수 있다.

코딩 에이전트가 광범위한 로컬 접근 권한을 합법적으로 필요로 할 수는 있다. 관련 모듈을 읽고, 테스트를 실행하고, 의존성을 이해하지 않고서는 복잡한 애플리케이션을 리팩터링할 수 없다.

하지만 이러한 로컬 권한이 프로세스에서 접근 가능한 모든 것을 내구성 있는 클라우드 사본으로 만드는 권한을 자동으로 의미하지는 않는다. 요청된 작업을 위해 파일을 읽는 것, 추론을 위해 선택된 컨텍스트를 보내는 것, 전체 저장소를 보관하는 것은 서로 다른 작업이다.

이 때문에 ZCode Git 기록 업로드 주장은 클라우드 코딩 어시스턴트가 코드를 처리한다는 관찰보다 더 심각하다. 분쟁은 범위, 지속성, 통제 및 공개에 관한 것이다.

개발자는 함수와 그 의존성을 포함한 모델 요청을 의식적으로 승인할 수 있다. 그러나 같은 개발자가 LFS 캐시, 삭제된 자격 증명, 휴면 브랜치 및 수년간의 커밋 객체 업로드는 거부할 수 있다.

엔터프라이즈 사용자는 추가적인 우려에 직면한다. 저장소에는 고객 계약, 소스 코드 에스크로 조건, 수출 통제, 데이터 레지던시 규칙 또는 직원 접근 정책의 적용을 받는 자료가 포함될 수 있다.

관련 질문은 단순히 암호화가 사용됐는지가 아니다. 보안팀은 무엇이 수집됐는지, 어디에 저장됐는지, 누가 키를 보유했는지, 얼마나 오래 남았는지, 삭제가 어떻게 작동하는지를 알아야 한다.

개인정보 보호 제어와 체크포인트는 서로 다른 이야기를 하는 듯하다

가장 날카로운 우려는 사용자가 제어할 수 있었던 것과 애플리케이션이 실제로 했다고 주장되는 일 사이의 보고된 격차다.

ZCode의 공식 문서는 워크스페이스 상태, 파일 참조, 작업 및 Git 브랜치 컨텍스트를 이해하는 에이전트를 설명한다. 에이전트 문서 역시 장기 개발 작업 지원의 일부로 상태 복구를 제시한다.

체크포인트는 정당한 목적에 쓰일 수 있다. 수십 개 파일을 편집하는 에이전트는 변경 실패 후 복구하거나, 상태를 비교하거나, 충돌로 중단된 작업을 복원할 방법이 필요하다.

그 기능이 체크포인트를 보이지 않게 처리해야 한다는 뜻은 아니다. 또한 .git의 모든 부분을 원격 아카이브에 포함해야 한다는 근거도 되지 않는다.

개인정보 보호를 고려한 설계라면 기본적으로 Git 객체와 LFS 캐시를 제외할 수 있다. 전송 전에 정확한 아카이브 매니페스트를 공개하거나, 체크포인트를 로컬에 유지하거나, 클라우드 동기화 전에 명시적 승인을 요청할 수 있다.

원격 스냅샷을 차단하는 조직 정책도 제공할 수 있다. 관리자는 저장소 수준의 제외 규칙을 적용하고 감사 로그를 통해 그 효과를 확인할 수 있다.

반면 조사는 ZCode의 아카이브 프로세스가 에이전트의 가시적 도구 루프 밖에서 작동했다고 주장한다. 보고에 따르면 에이전트의 나열된 도구에는 사용자가 승인할 수 있는 스냅샷 또는 업로드 작업이 없었다.

이 아키텍처는 명령 권한이 전송을 막지 못한 이유를 설명할 수 있다. 사용자가 셸 실행이나 파일 수정을 제한하더라도 호스트 수준의 사이드카는 모델의 도구와 독립적으로 실행될 수 있다.

이는 현재 에이전트 인터페이스의 사각지대도 드러낸다. 권한 프롬프트는 보통 명령 실행, 파일 편집, 네트워크 주소 열기처럼 눈에 띄는 작업에 집중한다.

백그라운드 서비스는 상대적으로 주목을 덜 받는다. 대화에 나타나지 않은 채 폴더를 인덱싱하고, 진단 정보를 수집하며, 세션을 동기화하거나, 복구 산출물을 만들 수 있다.

여기서 추론과 동기화의 구분이 중요해진다. 선택된 코드를 클라우드 모델에 보내는 일은 클라우드 기반 어시스턴트에서 대부분 사용자가 예상할 만큼 충분히 가시적이다.

롤백이나 인덱싱을 위해 기반 저장소 데이터베이스를 복사하는 것은 두 번째 데이터 흐름이다. 이는 별도의 설명, 범위 제어, 보존 규칙 및 삭제 인터페이스가 필요하다.

ZCode의 현재 개인정보 보호정책은 서비스를 제공하고, 의무를 이행하며, 정당한 사업상 이익을 보호하고, 안전성 또는 안정성을 개선하는 데 필요한 기간 동안 개인정보를 보관할 수 있다고 명시한다. 또한 보존 기간은 데이터 유형, 민감도, 목적 및 법적 요구 사항에 따라 달라진다고 말한다.

이러한 일반적 설명은 보고서가 제기한 질문에 답하지 못한다. 정책은 워크스페이스 체크포인트가 사용자 입력, 기술 데이터 또는 다른 범주에 해당하는지 식별해야 한다.

또한 어떤 스토리지 리전이 적용되는지, 하도급업체가 아카이브를 처리하는지, 계정 삭제 시 모든 체크포인트가 제거되는지도 설명해야 한다. 사용자는 관련 기능에 연결된 구체적인 보존 기간 또는 명확한 기준을 필요로 한다.

무엇보다 Z.ai는 개인정보 보호 토글이 체크포인트 업로드에 영향을 미치는지 문서화해야 한다. 데이터 수집 관련으로 표시된 제어 기능이 분석만 관장하고 워크스페이스 동기화에는 적용되지 않는다면, 잘못된 신뢰를 줄 수 있다.

제어 기능의 문구와 배치는 내부 구현만큼이나 중요하다. 본질적으로 다른 데이터 흐름이 모호한 용어 아래 묶여 있다면 개발자는 충분한 정보를 바탕으로 판단할 수 없다.

Z.ai가 내놓을 수 있는 가장 강력한 답변은 수사적 표현이 아닌 기술적 설명이다. 영향을 받는 버전, 활성화 조건, 아카이브 제외 항목, 엔드포인트, 암호화 주체, 보존 기간 및 삭제 절차를 열거해야 한다.

또한 보고 이후 동작이 변경됐는지도 설명해야 한다. 그 세부 정보가 없다면 사용자는 업데이트가 문제를 해결한 것인지, 단지 로컬 증거를 제거한 것인지 판단할 수 없다.

Open Weights는 폐쇄형 코딩 에이전트를 로컬로 만들지 않는다

이 사건은 모델과, 모델이 무엇을 볼 수 있고 어떤 데이터가 컴퓨터를 떠나는지 결정하는 소프트웨어를 구분한다.

GLM 모델은 Z.ai의 개발자 전략에서 핵심적인 위치를 차지하며, 일부 릴리스는 오픈 웨이트 형태로 배포됐다. 개발자는 해당 모델 파일을 검토하고, 자체 인프라에서 호환 버전을 실행하며, 호스팅 추론 엔드포인트를 피할 수 있다.

ZCode는 다른 계층이다. 이는 컨텍스트를 선택하고, 도구를 호출하며, 세션을 저장하고, 체크포인트를 관리하고, 클라우드 서비스에 연결하며, 자체 업데이트를 수행하는 하니스다.

기저 모델이 로컬에서 실행되더라도 하니스는 개인정보 보호 결과를 결정할 수 있다. 로컬 모델이 주변 애플리케이션의 텔레메트리, 인덱스, 세션 기록 또는 복구 스냅샷 외부 전송을 막아주지는 않는다.

마찬가지로 오픈 모델은 폐쇄형 Electron 애플리케이션이 백그라운드 프로세스에서 수행하는 작업을 드러낼 수 없다. 연구자는 네트워크 트래픽을 관찰하고, 애플리케이션 번들을 검사하며, 릴리스 이후 동작을 재구성해야 한다.

이것이 핵심적인 신뢰 충돌이다. ZCode의 제품 경험은 로컬 워크스페이스 이해를 강조하지만, 보고서는 개발자가 예상했던 것보다 광범위한 클라우드 캡처 메커니즘을 설명한다.

경쟁사 역시 개발자 데이터를 처리하므로, 적절한 비교는 “ZCode는 코드를 업로드하지만 다른 모든 에이전트는 로컬에 머문다”가 아니다. 이는 부정확한 주장이다.

Claude Code, GitHub Copilot, Codex, Cursor 및 기타 클라우드 연결 도구는 일부 사용자 입력과 코드 컨텍스트를 원격 서비스로 전송한다. 리포지토리 인덱스, 에이전트 세션 및 클라우드 작업 환경은 추가 사본을 만들 수 있다.

차이는 공개와 제어에 있다. 예를 들어 GitHub는 콘텐츠 제외 정책을 문서화하고, 일부 Copilot 인터페이스에서는 그러한 제외 기능을 지원하지 않는다고 설명한다.

GitHub는 GitHub 외부 리포지토리에 대한 시맨틱 인덱싱이 언제 데이터를 업로드하는지도 문서화하며, 엔터프라이즈 관리자가 해당 기능을 활성화해야 한다고 명시한다. 이러한 제어에도 한계는 있지만, 사용자는 데이터 흐름을 파악하고 평가할 수 있다.

이것이 Z.ai가 이제 마주한 기준이다. 제품이 클라우드 추론에 의존한다면, 공급업체가 어떤 코드도 컴퓨터를 떠나지 않는다고 약속할 필요는 없다.

대신 각 전송을 정확하게 설명해야 한다. 일시적인 프롬프트 컨텍스트와 영구적인 리포지토리 스냅샷을 구분하고, 관리자에게 강제 가능한 제어 권한을 제공해야 한다.

오픈 소스 하니스는 하나의 대응책을 제공한다. 코드에서 아카이브 제외 항목, 네트워크 엔드포인트 및 업데이트 동작을 확인할 수 있으며, 독립 검토자는 문서화된 설정이 구현과 일치하는지 시험할 수 있다.

오픈 소스가 완전한 보안 보장은 아니다. 모든 사용자가 모든 종속성을 검사하는 것은 아니며, 서명된 바이너리가 공개된 코드와 다를 수 있고, 침해된 업데이트도 여전히 피해를 초래할 수 있다.

폐쇄 소스 도구 역시 자동으로 악의적인 것은 아니다. 독립 평가를 받고, 상세한 데이터 맵을 제공하며, 테넌트 제어를 시행하고, 검증 가능한 네트워크 동작을 공개할 수 있다.

그러나 불투명성은 검증 비용을 높인다. 애플리케이션이 광범위한 파일시스템 권한과 자율 실행 권한을 가질 때, 그 비용은 실질적인 보안 고려 사항이 된다.

Hacker News의 논의는 양측의 관점을 모두 반영했다. 일부 댓글 작성자는 모든 폐쇄형 코딩 하니스를 용납할 수 없는 위험으로 봤고, 다른 이들은 클라우드 에이전트가 본질적으로 프로젝트 컨텍스트를 수신한다고 지적했다.

한 사용자는 ZCode를 사용했음에도 보고된 체크포인트 디렉터리를 재현할 수 없었다고 말했다. 다른 이들은 공급업체나 국가와 무관하게 샌드박스가 모든 독점 개발자 도구를 제약해야 한다고 주장했다.

이러한 반응은 서로 다른 두 가지 책임을 보여 준다. 공급업체는 데이터 흐름을 공개해야 하고, 개발팀은 에이전트가 접근할 수 있는 범위를 제한해야 한다.

어느 한쪽의 책임이 다른 쪽을 무효화하지는 않는다. 샌드박싱은 동의가 아니며, 개인정보 보호 제어가 효과적인 격리는 아니다.

즉각적인 위험은 리포지토리 콘텐츠와 제품 버전에 따라 달라진다

증거는 긴급한 검토를 뒷받침하지만, 모든 ZCode 사용자가 동일한 데이터를 업로드했다는 점을 입증하지는 않는다.

문서화된 사례는 하나의 워크스페이스와 하나의 관찰된 애플리케이션 구성에 관한 것이었다. 공개 보도는 얼마나 많은 설치 환경이 체크포인트를 만들었는지, 해당 동작이 언제 시작됐는지, 모든 운영체제가 같은 경로를 따랐는지를 확립하지 못했다.

사용자가 특정 복구 또는 인덱싱 기능을 활성화해야 했는지도 불분명하다. 보고서는 로그인 상태와 전송을 연관 짓고 있으므로 인증 상태가 중요할 수 있다.

버전 이력도 중요하다. 이후 릴리스는 이전 관찰의 타당성을 무효화하지 않으면서도 디렉터리, 엔드포인트, 제외 항목 또는 스케줄링 동작을 변경할 수 있다.

이 불확실성은 주장을 좁혀야 할 이유이지, 조사를 억제할 이유는 아니다. 비공개 리포지토리와 함께 ZCode를 사용한 팀은 사고 검토를 수행할 충분한 증거를 확보했다.

먼저 범위부터 파악해야 한다. 어떤 개발자가 ZCode를 설치했는지, 어떤 버전을 실행했는지, 언제 로그인했는지, 그리고 그 기간에 어떤 리포지토리에 접근할 수 있었는지 식별해야 한다.

다음으로 Z.ai 및 Aliyun 서비스와의 통신에 대한 엔드포인트, 프록시, DNS, 방화벽 및 엔드포인트 탐지 로그를 점검해야 한다. 로컬 체크포인트 파일이 도움이 될 수 있지만, 파일이 없다고 해서 전송이 발생하지 않았다고 단정할 수는 없다.

조직은 애플리케이션을 제거하거나 업데이트하기 전에 증거를 보존해야 한다. 업데이트는 그렇지 않았다면 조사관이 활동을 재구성하는 데 도움이 됐을 로그, 저장 경로 또는 바이너리를 변경할 수 있다.

보안팀은 노출된 리포지토리 이력에 커밋된 모든 자격 증명을 검토해야 한다고 가정해야 한다. GitHub는 최신 파일에서 자격 증명을 제거해도 무력화되지 않으므로 유출된 자격 증명은 교체할 것을 권장한다.

그 대응은 비례를 유지해야 한다. 한 개발자가 ZCode를 설치했다는 이유만으로 모든 기업 자격 증명을 교체해서는 안 된다. 먼저 리포지토리를 매핑한 뒤, 이력을 검색하고 어떤 시크릿이 활성 상태로 남아 있는지 검증해야 한다.

리포지토리 소유자는 민감하지만 시크릿은 아닌 자료도 검토해야 한다. 이전 커밋에는 고객 데이터, 취약점 세부 정보, 내부 엔드포인트, 라이선스 자산 또는 법률 검토가 필요한 협상 내용이 포함될 수 있다.

리포지토리에 규제 대상 또는 계약상 제한된 데이터가 포함됐다면, 법무 및 컴플라이언스 팀은 통지 의무를 평가해야 한다. 답은 관할권, 계약 문구, 확인된 전송 증거 및 관련 데이터에 따라 달라진다.

ZCode 테스트를 계속하는 개발자는 이를 격리해야 한다. 전용 가상 머신이나 컨테이너는 가시적인 파일시스템을 제한할 수 있지만, 네트워킹과 마운트된 디렉터리도 신중한 구성이 필요하다.

실제 자격 증명이나 상업적 이력이 없는 일회용 리포지토리를 사용해야 한다. 홈 디렉터리, SSH 폴더, 클라우드 구성, 패키지 자격 증명 또는 관련 없는 소스 트리를 마운트하지 않아야 한다.

파일시스템 제한은 체크포인트 디렉터리를 차단할 수 있지만, 취약한 방어책이다. 업데이트에 따라 경로와 프로세스가 바뀔 수 있으며, 쓰기를 거부하면 복구 동작이 비활성화되거나 애플리케이션이 작동하지 않을 수 있다.

네트워크 제어는 또 다른 계층을 제공한다. 팀은 아웃바운드 대상지를 제한하고 연결 시도를 기록할 수 있지만, 필요한 서비스를 차단하면 제품을 사용할 수 없게 될 수 있다.

더 안전한 장기 모델은 명시적 허용 목록을 사용한다. 에이전트에는 제한된 프로젝트 체크아웃, 임시 자격 증명 및 작업에 필요한 서비스만 제공된다.

이 접근 방식은 ZCode에만 국한되지 않고 engineering workflows 전반에 유용하다. 파일시스템 및 셸 접근 권한을 가진 모든 자율형 어시스턴트는 권한이 부여된 개발 종속성으로 취급해야 한다.

목표는 불완전한 증거로 악의적 의도를 입증하는 것이 아니다. 문서화되지 않은 동작의 결과를 줄이는 것이다.

세 가지 신호가 Z.ai가 신뢰 격차를 해소했는지 보여줄 것이다

다음 시험대는 Z.ai가 문서화되지 않은 데이터 흐름을 제한적이고, 가시적이며, 검증 가능한 제품 기능으로 전환하는지 여부다.

첫 번째 신호는 상세한 공개 답변이다. Z.ai는 보고된 ZCode Git 이력 업로드를 확인하거나 반박하고, 영향을 받은 버전을 식별하며, 어떤 제품 상태가 이를 유발했는지 설명해야 한다.

유용한 성명은 측정된 아카이브 콘텐츠를 직접 다룰 것이다. .git/objects, .git/lfs, reflog, 무시된 파일 및 전역 구성이 포함됐는지 밝혀야 한다.

Z.ai가 데이터가 암호화된다는 일반적인 보장만 공개한다면 핵심 우려는 남는다. 회사가 복호화 키를 통제한 것으로 보고됐으므로, 전송 암호화는 접근이나 보존에 관한 질문에 답하지 못한다.

두 번째 신호는 강제 가능한 체크포인트 제어다. ZCode에는 원격 스냅샷을 중지하고, 조직에서 관리할 수 있으며, 분석 또는 모델 학습 기본 설정과 독립적인 설정이 필요하다.

사용자는 로그나 문서화된 네트워크 이벤트를 통해 해당 설정을 검증할 수 있어야 한다. 애플리케이션은 첫 번째 전송 전에 업로드하려는 내용을 보여줘야 한다.

기본 제외 항목은 .git, LFS 캐시, 무시된 파일, 자격 증명 및 일반적인 시크릿 위치를 제거해야 한다. 사용자는 작업에 실제로 필요한 경우에만 추가 이력에 옵트인할 수 있어야 한다.

로컬 전용 복구 옵션은 이러한 긴장의 상당 부분을 해소할 수 있다. 특히 에이전트와 모델이 같은 머신에서 실행될 때, 체크포인트는 클라우드 아카이브가 되지 않고도 롤백을 지원할 수 있다.

세 번째 신호는 독립적인 재현이다. 연구자는 현재 릴리스를 지원되는 운영체제, 신규 및 기존 계정, 다양한 개인정보 보호 구성에서 테스트해야 한다.

이 작업은 원래 동작이 보편적이었는지, 조건부였는지, 또는 이미 변경됐는지를 밝혀야 한다. 또한 제품을 통해 체크포인트를 삭제할 때 서버 측 사본까지 모두 제거되는지 검증해야 한다.

제3자 평가는 특히 평가자가 범위와 방법을 공개한다면 Z.ai의 대응을 강화할 것이다. 재현 가능한 패킷 캡처와 아카이브 매니페스트는 광범위한 인증 문구보다 더 가치 있을 것이다.

개발팀에 있어 이 교훈은 하나의 애플리케이션을 넘어선다. 코딩 에이전트를 소프트웨어 공급망 구성 요소로 관리하고, 엔드포인트를 문서화하며, 비공개 리포지토리 접근 권한을 부여하기 전에 데이터 흐름을 검토해야 한다.

다섯 가지 직접적인 질문을 던져야 한다. 에이전트는 무엇을 읽을 수 있는가? 무엇을 전송하는가? 원격에 무엇이 남는가? 키는 누가 보유하는가? 각 전송을 중지하는 제어 기능은 무엇인가?

공급업체가 이 질문에 답할 수 없다면, 답할 수 있을 때까지 에이전트를 일회용 환경으로 제한해야 한다. 답변이 “암호화됨”에만 의존한다면, 누가 이를 복호화할 수 있는지 물어야 한다.

보고된 ZCode Git 이력 업로드는 아직 모든 사용자의 노출을 확립하거나 어떤 아카이브의 오용도 입증하지 못했다. 그러나 정밀한 대응을 요구하는 신뢰할 만한 불일치는 확립했다.

Z.ai는 메커니즘을 공개하고, 기본 설정을 수정하며, 실질적인 끄기 기능을 제공하고, 독립적인 검증을 지원함으로써 그 격차를 줄일 수 있다. 그때까지 개발자는 ZCode의 보이는 워크스페이스를 가능한 수집 범위의 최대치가 아니라 최소 경계로 취급해야 한다.