ZCode packed 42,411 files for upload. Who owned the data risk?

A coding agent can respect every visible tool permission and still move data through a hidden product subsystem.

That is the useful liability question raised by reports about ZCode, the coding agent from Z.ai, also known as Zhipu AI. An independent developer reported that version 3.12.3 automatically packaged whole workspaces, including Git history and locally cached assets, into encrypted snapshots intended for cloud storage. The researcher said the process ran outside the agent's normal tool loop and was not stopped by the product's two apparent privacy controls.

The largest reported archive did not upload successfully. That distinction matters. The developer's logs showed 564 failed attempts to send a 313 MB encrypted snapshot of a commercial project. A separate test involving a small public repository did reach the service, according to the same researcher.

Z.ai apologized, acknowledged that repository data could be uploaded through its Repo Wiki feature, said the feature had been enabled by default for some users, and said the problem was fixed. It also said uploaded data was destroyed after a Wiki page was generated.

No regulator or court has made findings about the incident. There is no public evidence of a successful upload of the large commercial archive, confirmed misuse of private source code, a quantified loss, a filed insurance claim, or a coverage decision.

Those limits do not make the incident unimportant. They make the question more precise: when an AI coding product moves repository data outside the user's visible authorization flow, is that an agent failure, a software-design failure, a vendor-governance failure, or all three?

Verified facts

The facts below come from the developer's technical report, Z.ai's reported response, ZCode's published privacy policy, the current public source repository, and reporting by the South China Morning Post and Tom's Hardware. Where the sources disagree or a claim cannot be independently verified, that limitation is stated.

The developer, who publishes as Ferstar, said he found more than 700 MB in ZCode's local data directory while freeing disk space. In a checkpoint directory, he found an encrypted archive and a state file showing:

• A source workspace of 345,549,173 bytes.
• An encrypted archive of 313,070,842 bytes.
• A baseline snapshot type, indicating a full snapshot.
• A failureCount of 564.

Ferstar said the archive's local manifest listed 42,411 files. His breakdown attributed 86.6% of the source workspace to the .git directory: about 196.1 MB of Git LFS objects, 102.2 MB of Git objects, and 0.6 MB of reflog data. The remaining source code, configuration, and documents accounted for about 46.2 MB.

His reverse engineering of ZCode 3.12.3 described a client workflow that requested temporary upload credentials and an encryption public key from ZCode, encrypted the snapshot locally, and attempted to upload it directly to Alibaba Cloud Object Storage. He reported that the corresponding private key remained on the service side.

The 313 MB commercial-project archive did not upload successfully, according to Ferstar's state file and network review. The 564 figure refers to failed retries, not 564 successful transfers. Ferstar separately reported that a roughly 15 KB encrypted snapshot containing 538 files from a small public repository was accepted by the service. That test shows that the upload path could work; it does not prove that private data from the larger project reached the cloud.

Ferstar said the snapshot component was created whenever a user was logged in and could capture before a prompt and after a Repo Wiki task. He also said that disabling “Optimize Experience” and “Repository Snapshot Indexing” did not stop packaging or upload attempts. These details come from his inspection and testing of version 3.12.3. They are not findings from a regulator or an independent forensic examination.

Z.ai's response, as reproduced by Chinese technology publication IT Home, said repository data might be uploaded when Repo Wiki generated pages in the cloud. The company said the feature was initially enabled by default, affected some users, and had been fixed. It said uploaded data was destroyed immediately after the Wiki page was generated. It also promised to open-source ZCode and invite third-party review.

Z.ai later published ZCode's client source on GitHub. Ferstar reported that the upload pipeline was absent from versions 3.14.0 and 3.14.3 and that he did not observe new encrypted repository snapshots during local runtime monitoring. The public repository can show what its published code contains now. Without reproducible builds or the historical 3.12.3 source, it cannot by itself prove that every distributed binary matched the published code or reconstruct the full historical data lifecycle.

ZCode's privacy policy, effective June 15, 2026, says the service collects text, files, and code that users submit through conversations to provide AI-assisted services. It also distinguishes necessary information from optional information and says separate consent may be sought for additional features or sensitive data. The policy does not, in the passages reviewed for this analysis, expressly describe automatic full-workspace snapshots containing Git history.

There is no public list of affected users or repositories. Z.ai's statement that uploaded data was destroyed is a company claim. Ferstar reported that company-cited third-party reviewers later found the relevant storage bucket empty, but the full historical data flow and any copies or backups cannot be reconstructed from a point-in-time empty-bucket result alone.

Klaimee's analysis: the hidden control plane is part of the agent

The headline risk is easy to misclassify as an autonomous model deciding to steal code. The available evidence points somewhere less cinematic and more useful.

Ferstar's account describes a deterministic product subsystem. The upload pipeline appears to have run outside the model's visible tool calls and outside the permission prompts a user would normally inspect when deciding what a coding agent may do. If that account is correct, the model did not invent the transfer. The product was designed to perform it.

That distinction changes where liability analysis starts. It should not start with the model's intent. It should start with the full deployed system:

1. What data could the desktop client read?
2. Which component selected files for packaging?
3. What user action, notice, or consent authorized the transfer?
4. Which settings actually controlled collection, upload, indexing, training, and retention?
5. Who held the decryption key and controlled deletion?
6. What evidence can prove which data left the device and what happened next?

An operator can approve an agent to read a repository for a local task without approving a vendor to create a cloud copy of the repository's entire history. Those are different permissions, different purposes, and potentially different legal and insurance risks.

This is why an agent's authorization boundary cannot be limited to its tool-call UI. Background services, telemetry, indexing, support bundles, cloud sync, update mechanisms, and vendor-side processing are all part of the system that underwriters and enterprise buyers need to evaluate.

Why it matters

Git history can be more sensitive than the current checkout. Deleted credentials, abandoned features, unreleased branches, internal hostnames, commit authors, and large binary assets may remain in .git after they disappear from the visible working tree. A full snapshot can therefore expose more than the files a developer believes the agent is using.

Encryption did not answer the authorization question. Encryption can protect data in transit and storage. Here, the reported design gave the service the key needed to decrypt successful uploads. That may be appropriate for a disclosed cloud feature, but it does not make an undisclosed or overbroad transfer authorized.

A privacy switch must control the action users think it controls. A setting called “Repository Snapshot Indexing” can create a reasonable expectation that turning it off prevents repository snapshots. If it only changes what happens after upload, the interface and the data path describe different boundaries.

The product boundary is wider than the reasoning model. An AI incident can arise from conventional software around the model. Certification or insurance that reviews only prompts and model behavior will miss collection services, update channels, file watchers, retry logic, cloud storage, and retention.

Where liability may sit

No public record allocates legal responsibility, and the answer would depend on jurisdiction, contracts, actual data transferred, the user's configuration, and evidence of harm. Several parties and duties could still come under scrutiny.

The product provider. A claimant or regulator could examine whether ZCode's notices, settings, defaults, data minimization, retention, and security controls matched the product's actual behavior. The gap between files submitted in a conversation and an automatic full-repository snapshot may be especially important. Z.ai's apology and remediation are relevant operational facts, not a final legal admission.

The customer organization. Companies that allow coding agents to access proprietary repositories remain responsible for vendor diligence, endpoint policy, source-code access, data classification, and outbound network controls. That does not excuse undisclosed vendor behavior. It does mean an enterprise may have its own contractual, privacy, or security duties to customers, employees, and code owners if protected information leaves its environment.

Developers and repository owners. Individual users may have accepted terms, but they may not own every item in a workspace or have authority to transfer it. Repositories can contain employer code, client materials, personal data, third-party secrets, and licensed assets. ZCode's own terms place responsibility on users for content they submit, which makes a silent, overbroad upload path particularly difficult to reconcile operationally.

Cloud and subprocessors. If repository data reached object storage or other providers, contracts and data-processing terms would determine roles, instructions, security duties, retention, deletion, audit rights, and breach notification. The use of a cloud storage service does not by itself establish wrongdoing or liability.

If personal data was successfully disclosed, data-protection duties could apply. The European Data Protection Board defines a personal-data breach to include unauthorized disclosure of or access to personal data. Whether any successful ZCode upload met that definition for a particular organization would require proof about the data, people, processing roles, location, and applicable law.

The relevant Klaimee risk domains

This incident maps most directly to four of Klaimee's eight risk domains.

D1 Scope violation. The reported snapshot included far more than a user-selected prompt attachment or the current source files. Full Git history, LFS objects, reflogs, and global application configuration can exceed the scope reasonably required for a coding task.

D2 Data exfiltration. The large commercial snapshot did not successfully upload, so a confirmed sensitive-data disclosure should not be inferred. The attempted transfer and the successful public-repository test still expose a data-egress path that must be assessed.

D3 Unauthorized action. The central allegation is that the client packaged and attempted to transfer repository data without a separate, effective authorization step. If the action occurred outside the agent's tool permissions, approving the agent's task would not necessarily approve the background transfer.

D8 Operational control. Default-on behavior, ineffective privacy settings, repeated retries, limited user visibility, and uncertain deletion evidence are control-plane issues. They remain material even if the language model behaved exactly as instructed.

The incident does not provide evidence of model drift, fabricated output, or adversarial manipulation. Adding those domains would overstate what the record supports.

Controls that failed, and controls that worked

Based on the available reporting, the weak or failed controls appear to include:

• Purpose limitation: the client reportedly packaged whole repositories for an auxiliary feature without a narrowly defined, visible data scope.
• Data minimization: .git, LFS caches, reflogs, and global settings were reportedly included even though local indexing can often operate without transferring them.
• Consent and settings: the controls users could see allegedly did not stop capture and upload attempts.
• Egress control: a desktop coding product could request cloud credentials and attempt direct object-storage uploads from a source-code environment.
• Retry governance: the large archive accumulated 564 failed attempts instead of stopping after a bounded number of failures and asking the user.
• Auditability: external observers could not independently verify historical decryption, deletion, replication, or backup behavior.

Some controls reduced risk or improved the response:

• The reported upload path encrypted snapshots before transfer.
• The large commercial archive failed to leave the researcher's network, according to his review.
• Local state and manifests gave the researcher evidence to reconstruct the attempted action.
• Z.ai acknowledged the issue, removed the reported pipeline from later code, open-sourced the current client, and invited review.
• The public source now gives customers more visibility into current behavior, even though it cannot recreate the closed historical version.

The stronger control design is straightforward: exclude .git and sensitive paths by default; show the exact file manifest and destination before first upload; require a separate opt-in for cloud features; make one switch actually stop collection and egress; cap retries; publish retention and deletion evidence; and let enterprises enforce outbound-domain and data-loss-prevention policy.

NIST's 2026 concept paper on software and AI agent identity reaches the same broader design point. Organizations need visibility into agent actions, data generated, and data flows, plus authorization controls tied to the specific system and delegated task. For coding agents, that visibility must include the harness and background services, not only model tool calls.

How coverage might respond

There is not enough public information to determine whether any policy would respond. Coverage depends on the insured, the actual transfer, the claim, the policy period, definitions, exclusions, retentions, sublimits, notice, and the contracts among the user, employer, vendor, and cloud providers.

A customer's cyber policy may be relevant if private repository data or personal data was successfully disclosed and the organization incurred forensic, legal, notification, restoration, extortion, business interruption, or third-party privacy costs. An attempted upload with no confirmed disclosure may still justify investigation, but it may not satisfy every policy's event or loss trigger.

Technology E&O or cyber coverage for the product provider may be implicated if customers allege that the software, privacy controls, cloud feature, or contracted services caused a disclosure or other loss. The response could turn on professional-services wording, privacy liability, media or intellectual-property exclusions, contractual-liability provisions, territorial limits, and whether the alleged conduct was intentional at the company level.

Intellectual-property and trade-secret losses can fall into difficult gaps. Some cyber forms pay incident-response costs while excluding or narrowly covering the economic value of source code, lost competitive advantage, or contractual disputes. A policy review should distinguish the cost to investigate and contain the event from the value of the allegedly exposed asset.

Purpose-built AI agent coverage should attach to the complete certified system: model, desktop client, file-access rules, background services, cloud destinations, data-retention terms, and operational controls. If an update adds a new snapshot pipeline or materially changes where code is processed, that may be a change in certified scope even if the model name stays the same.

No one should conclude from this record that a covered breach occurred, that a particular exclusion applies, or that a vendor or customer policy must pay. The defensible next step is to preserve endpoint and network evidence, determine what actually transferred, identify the owners and contents of the data, give required notices, and then test each claimed cost against the actual policy language.

Questions operators and underwriters should ask now

• Which components can read repository files besides the agent's visible tools?
• Does the product transmit full files, embeddings, indexes, diffs, logs, or Git history?
• Can the user see and approve the exact manifest and destination before data leaves the device?
• Do privacy controls stop collection and transfer, or only downstream training and indexing?
• Are .git, secrets, build artifacts, customer data, and global configuration excluded by default?
• Can enterprise policy block unapproved object-storage destinations and detect unusual upload volume?
• Are retries bounded, visible, and paused after repeated failure?
• Who holds decryption keys, and what independent evidence proves deletion from primary storage, replicas, logs, and backups?
• Do vendor contracts match the deployed product's actual data flows and subprocessors?
• Does insurance treat source-code exposure, personal-data disclosure, and investigation costs as distinct losses?

The central lesson is not that every coding agent is secretly exfiltrating code. The evidence supports a narrower and more actionable conclusion.

An agent's real authority is the sum of every component shipped around it. If users can inspect only the model's tool calls while a background service has broader file and network access, the visible permission system is not the security boundary.

Sources

• Ferstar: Inside ZCode: Silently Uploading Your Entire Git History to the Cloud, September 18, 2026, updated September 23, 2026.
• Z.ai: ZCode public source repository, accessed September 23, 2026.
• ZCode Privacy Policy, effective June 15, 2026.
• IT Home: ZCode response says the issue was fixed and code would be opened for review, September 18, 2026.
• South China Morning Post: Chinese AI firm Z.ai faces reputation hit after users spot unauthorised uploads, September 20, 2026, updated September 21, 2026.
• Tom's Hardware: Developers report ZCode workspace uploads without explicit consent, September 21, 2026.
• NIST NCCoE: Accelerating the Adoption of Software and AI Agent Identity and Authorization, February 2026 draft concept paper.
• European Data Protection Board: Guidelines 9/2022 on personal data breach notification under GDPR, final version adopted April 4, 2023.

This article provides risk and insurance analysis for general information. It is not legal advice, an offer of insurance, or a coverage determination. Consult qualified counsel and your broker about specific facts, contracts, and policy language.