What ZCode Did (and Why It Matters)
Last week, a Chinese security researcher who publishes as Ferstar checked the network logs of his ZCode install and found something no developer wants to see: the AI coding assistant had silently packed his entire workspace, 42,411 files compressed into a 313MB encrypted archive, and logged 564 attempts to push it to Alibaba Cloud object storage. Z.ai, the Beijing lab behind the GLM models, apologized days later, disabled the upload path, and open-sourced the client. For anyone using agentic coding tools, the incident reads like a worst-case walkthrough of what can go wrong when an assistant gets the run of your repository.
The scary part is what got packaged. ZCode did not just grab the files you were editing. It captured the whole development environment, and Git data made up 86.6 percent of the 345.5MB pre-compression workspace:
- 196.1MB of cached Git LFS assets, often the hardest and slowest part of a repo to rebuild
- 102.2MB of commit objects plus 0.6MB of reflogs, giving a complete history of your project and its collaborators
- Only 46.2MB was source code and documents, plus global app configs that can contain credentials and API keys
The upload was designed to be uncatchable. The archive was encrypted with AES-256-CTR, and the content key was wrapped with RSA-OAEP-SHA256 using a public key the server handed down along with temporary Alibaba Cloud credentials, so the data went straight to a storage bucket instead of through Z.ai's own servers. The matching private key exists only in Z.ai's cloud, which meant users could neither read nor delete what had been taken.
The timeline shows how fast a trust crisis can move. Ferstar published his analysis on September 18. Within 72 hours, Z.ai had apologized, removed the feature, and put the entire client on GitHub; by Monday the fix was in v3.14.0 and two independent security assessments were underway.
Worse, there was no off switch. The capture ran before every prompt and again whenever a Repo Wiki task finished, up to 62 times in a single active session. Two settings looked like they should have blocked it, but Ferstar found that "Optimize Experience" only governed consent to training on user data, while "Repository Snapshot Indexing" governed what the server did with a snapshot after it arrived, so the packaging and the transfer ran regardless of how either was set. None of it was disclosed in the privacy policy.
Your AI Coding Assistant Audit Checklist
Z.ai's response was fast by industry standards. The company apologized, confirmed the uploaded data was never used for model training, disabled the repository snapshot workflow, deleted the zcode-prod bucket (confirmed by NSFOCUS), removed the Repo Wiki feature, and shipped v3.14.0 with the upload code gone. It also open-sourced the client under Apache 2.0 and commissioned security assessments from CAICT and NSFOCUS. Yet critics note the GitHub repo restarts from scratch with two commits, the pre-patch upload code wiped from history, and Ferstar says the endpoint that issued snapshot credentials now returns a 404. Trust is rebuilt in public, not announced.
The gap Ferstar described is between a setting's name and its job, and that question now hangs over every agentic tool, including the Codex and Claude Code plugins Unity ships. The apology itself promised more than fixes, too: Z.ai thanked the community, committed to an ongoing vulnerability reporting and response process, and said it would pay rewards based on the severity of issues reported. Before you grant any AI assistant access to your source, though, run through this checklist:
- Monitor egress: run the tool in a sandbox VM or container and watch outbound traffic with a proxy before letting it touch a real repository
- Verify toggles actually toggle: read the documentation, then test that each privacy and indexing setting stops the behavior it claims to control
- Audit the payload, not the prompt: check what files the tool reads and writes across a session, including .git internals and config files
- Check the privacy policy and the data-deletion story: know where data goes, who holds the decryption keys, and how you can delete it
- Keep sensitive repos out of the loop entirely: run assistants on copies, never on the canonical repository with embedded secrets
Enterprises should demand more from vendors, and Z.ai's own commitments illustrate the standard. Semgrep security advocate Cris Thomas frames it plainly: giving an AI access to proprietary source code requires clear disclosure of what leaves the machine, where it goes, how long it is retained, and who can access it, with minimum permissions on by default rather than maximum. At a minimum, hold every tool vendor to these four promises:
- A real off switch: an explicit, documented control that disables any automatic repository packaging or transmission
- Customer-held keys: encryption that the vendor cannot decrypt unilaterally, so "deleted" is something you can verify
- Independent audits with published findings, plus a severity-based bug bounty that rewards this kind of discovery
- Source transparency: public code history that preserves the pre-patch code for review instead of scrubbing it
The ZCode affair is not an AI model problem; it is an old-fashioned security architecture problem wearing a new interface. The model did what the harness was built to do, and the harness was built to ship your workspace to a bucket you could not see, keyed by a server you could not audit.
The practical fix was never a better model. It is a better checklist.
Comments