Author | Link, Zheng Hao
Over the past two years, the focus of discussions involving Agent safety has mainly been on model malfunction, prompt poisoning, and external attackers. In contrast, the data behaviors of Agent manufacturers themselves have rarely been discussed as a primary risk.
The recent exposure of the ZCode incident is shifting the issue towards a direction that has seldom been taken seriously before: whether the manufacturers of Agents themselves could also become sources of data leakage.
On September 18, technology blogger ferstar released a reverse analysis of ZCode. He found that as soon as a user logs into their account, ZCode will encrypt and upload the entire work project along with its complete modification history to the cloud server in the background.
The software interface lacks a truly usable off switch, and the decryption key for the encrypted files is only stored on the ZCode side. ZCode quickly apologized, stating that the problem originated from a function that was enabled by default, that data would be destroyed after use, and it promised to soon open its code repository and invite third-party audits.
The issues exposed by ZCode are no longer a rare occurrence in the industry.
Not long ago, independent security researcher cereblab proved through packet analysis that xAI's programming Agent tool, Grok Build, would upload the entire project of the user to Google Cloud Storage, including files explicitly instructed by the AI not to be read and unmasked passwords.
Earlier, Claude Code was found to transmit location and identity information without the user's knowledge, and Anthropic engineers even confirmed afterward that it was a deliberate experiment.
More critically, these issues were discovered not due to regulation or security audits but often by individuals within the community. Currently, no rules have been put in place in the industry’s security framework to constrain the behaviors of manufacturers themselves.
1. The Starting Point is Hard Drive Anomalies
On September 18, when technology blogger ferstar was inspecting ZCode's local directory, he noticed an anomaly in hard disk space usage. He found an encrypted file of about 313MB, which significantly exceeded the usual size. The file could not be opened, but the accompanying file list indicated that this package contained approximately 42,000 files, of which over 80% were project modification records.
This record not only contained project files but also included caches of large files that had previously been downloaded and local operation logs. What was packaged was not just the project itself but also its "experiences since birth."
Subsequent code analysis found that this historical record was exempt from all security filtering rules during the packaging process.
The file filtering logic of ZCode was determined in sequence; the release of the history record directory was prioritized over key filtering and size limits, meaning that the filtering for password files like pem and key, as well as the 1MB size limit, did not apply to anything within the history record directory.
This means that a file package of hundreds of megabytes could take everything away, and any passwords and keys previously submitted in the history that were deleted would also be uploaded intact.
The more troublesome operation was yet to come: the decryption key was not on the user's computer.
Ferstar dismantled the upload path of the file, discovering that first, the client would request an upload credential and a public key for encryption from the ZCode server, then complete the compression and encryption locally, subsequently bypassing ZCode's own business servers to directly upload to Alibaba Cloud's storage service, which would then callback to ZCode's backend.
A brief explanation of the encryption method:
The public key is akin to a lock; anyone can use it to lock something in a box; the private key is comparable to a key, and only the person holding the key can unlock it. ZCode's approach is that the lock is temporarily issued by the server while the key is only stored on the server side. The Agent generates an encrypted package on the user's computer, and the user themselves cannot see what is actually inside.
Ferstar found that this mechanism would trigger at two moments: one before the user sends a request to the AI, and the other after the task has ended. During an active usage process, he observed as many as 62 snapshot records.
Two options on the interface that seemed related were confirmed by him after a careful comparison with the code logic: one called "Optimize Experience" actually only controls whether the data is used for model training; the other called "Repository Snapshot Index" actually only controls whether a retrieval directory is established on the server side upon receiving data.
When both are turned off, the local packaging and uploading continue to run as usual. The components responsible for snapshots and uploads are unconditionally loaded when the software is started, with the only prerequisite being that the user is logged in.
In addition to the project files, each snapshot also packages ZCode's own global configuration, taking it across projects.
Ferstar attempted to manually delete that 313MB file pending upload. Half an hour later, ZCode automatically generated a new packaged file, with the Agent secretly attempting to upload and repeatedly retrying if unsuccessful.
Deleting it would result in rebuilding, which perhaps is not the level of persistence expected from a non-essential auxiliary function.
2. Unclear Responses
That evening, the community quickly reacted to this article, and ZCode responded and apologized promptly.
This issue originated from ZCode's "Repository Indexing" feature. This feature aims to help users generate a repository index locally to support session checkpoint restoration, historical version rollback, and Repo Wiki functionalities including historical versions.
The Repo Wiki function may trigger the upload of repository data while generating Wiki pages. After the Wiki page is generated in the cloud, the related uploaded data will be immediately destroyed and will not be retained. As this function was enabled by default during the initial launch phase, some users were affected, and we sincerely apologize for this; the related issue has now been fixed.
ZCode also promised to open the ZCode code library soon, invite third-party evaluators to review system operations, and additionally compensate all users with a weekly quota reset issued the same day.
Here, the "Repository Indexing" is to establish a catalog and retrieval system for project files; "Repo Wiki" is a function that automatically generates a documentation for projects; "Session Checkpoint Restoration" and "Historical Version Rollback" enable users to revert to a previous step during their conversations with the AI.
These functionalities are reasonable in themselves, and the response is timely, but the key point is:
What it explains and what the community is inquiring about are not the same issue.
ZCode states that this indexing system "is designed to help users generate locally." If it is locally generated, why does the entire project need to be sent to the cloud? Local indexing, local snapshots, local rollbacks are all technically feasible, and there are tools on the market that do just that.
Combining "local indexing" and "upload to the cloud" into one sentence suggests that the latter is a natural extension of the former, but it lacks an explanation of a critical link in between.
The response attributes the problem to Repo Wiki "potentially triggering the upload of repository data when generating Wiki pages." However, ferstar's reverse record indicates that one of the triggers for uploads occurs before the user sends a query each time, unrelated to generating documentation.
The current official documentation of ZCode explicitly states that during documentation generation, it does not read the history modification records of the project, instead only reading filtered code context as needed, indicating that this functionality does not technically require historical records.
So why is 86.6% of the uploaded package historical records? The explanation does not address why the uploaded range was so extensive; whether it was by design or program error also remains unclarified regarding from which version corrections began.
The terminology used in the explanation states that this feature "was enabled by default during the initial launch phase," which more resembles framing a data leak at the mechanism level as a switch setting of a feature.
Ferstar's code analysis shows that both related options on the interface manage training and indexing but do not control the packaging and upload actions themselves.
The core of the community's doubts is that the control items visible to users cannot manage what is truly happening, and this is not an issue of a "certain feature being turned on by default."
Soon another more sensitive piece of evidence was also dug up by the community, which is the update log for ZCode version 3.12.2, dated September 16, 2026, just two days before ferstar's post.
One record states, "Optimize memory usage for repository snapshot uploads." It is challenging for the engineering team to optimize memory for an unexpected behavior, indicating that "repository snapshot uploads" is an internally continuously iterated regular function.
This update log has been deleted after the incident gained traction; deleting public records is a new issue independent of the original behavior.
"Relevant uploaded data will be immediately destroyed and will not be retained," this statement responds to how long data is kept, but there are many more questions that users truly need to know, such as whether the data has already left the computer, who has access to it during processing on the server, who has the ability to decrypt the encrypted package, and what deletion policies have been executed for previously uploaded data.
From the encryption method perspective, the key being on the server side means that "encrypted uploads" only prove that it will not be intercepted by third parties during transmission, but it cannot imply that ZCode itself cannot decipher the contents.
The English version of ZCode's privacy policy uses the phrase "submitted by users through conversation" for the scope of data collected, referring to text, files, and code. However, the backend snapshot is not submitted by users through conversation; this action is not covered in the privacy policy description. "Submitting to us in conversation" and "automatically packaging the entire project in the background" are two different matters.
This privacy policy also clarifies that when new features involve the collection of information not directly or reasonably related to the original purpose, users should be notified and obtain consent via page prompts, interactive processes, etc.
Another developer, Feng Ruohang, found through code analysis that each time the client sends a query, it unconditionally requests an upload credential from the server side, collecting data only if the server issues the credential; if not issued, no data is collected.
The 313MB file that Ferstar discovered was pending upload at that time and had failed 564 times. Feng Ruohang independently reproduced Ferstar's evidence collection process on his Mac, confirming that in the snapshots from four workspaces, at least one snapshot status had already written a confirmation mark accepted by the server.
According to the code logic, this mark only generates after the upload is confirmed received by the server. This means that data had indeed left the local environment on at least one machine. ZCode's apology, commitment, and compensation were all provided within hours of the controversy arising, and the response speed did not appear to be preparing for a long concealment.
However, whether "immediately destroyed" or "will not be saved," such commitments are unverifiable from an external standpoint and cannot be falsified. What users can see is only that the data has left their computers, and what happens afterward entirely relies on the manufacturers' self-restraint.
Whether the promised open source and third-party reviews by ZCode can change this depends on which version is open sourced and whether the review covers the client side or the server side; these questions currently have no answers.
3. More Sensitive than Code Data
If some manufacturers genuinely intend to collect user data, what they want may not be the users' code itself.
Because public projects on major code hosting platforms provide ample material for model training. Private code certainly contains trade secrets, but from the perspective of model improvement, simply acquiring another batch of code text does not hold much marginal value.
What is genuinely scarce are three things.
First, the causal chain of changes.
What is stored in the historical modification records of a project is not mere snapshots but the complete process of "how it was before the change, why it was changed, and how it was changed." This sequence, bearing cause and effect, is the ideal learning material for training programming models: given the current state of a project and an intention to modify, what changes should the model make.
Second, usage trajectories annotated with results.
ZCode’s triggering mechanism takes a "snapshot" before each user query, and it also has rollback functionality, allowing users to undo modifications made by the AI. These two actions together naturally record a full loop of "query + pre-operation state + post-operation state + user satisfaction (whether undoing)." Such data is extremely expensive in AI training, often requiring specially hired personnel for annotation, while ZCode's snapshot mechanism allows users to generate these annotations for free during normal usage.
Third, real projects that have never been seen by any model.
Currently, publicly available programming assessment questions have almost all been "encountered" by various models during training, leading to inflated scores. Real, private projects that have never entered a training set are the most valuable raw material for conducting internal capability evaluations.
These three items indeed highly align with the composition of the ZCode upload package, which is why the community has consistently rejected the explanation that it was "only for generating documentation."
However, conversely speaking, if the goal is indeed to systematically collect training data, a more precise approach would be to only extract query content and code changes, and there would indeed be no need to package large file caches and complete operation logs together.
This form of excessive collection resembles the engineering team reusing a set of generic packaging logic when developing the snapshot function, packing in all files related to indexing and rollback, plus cloud storage itself incurs costs; the actual value of large numbers of personal users’ small projects and practice code for model training is limited, and the risk-reward ratio for targeting data from paying customers, especially enterprise clients, is actually very unfavorable.
It must be acknowledged that the motivation to utilize this data to improve models and tools is valid, and the paths are readily available; however, based on the roughness of the upload package, the radical product decision compounded by engineering laziness seems to fit the existing evidence more than "ZCode intentionally wanting to do something."
Of course, the severity of this issue should not be overlooked simply because ZCode lacked subjective intent; it does pose security risks to users.
4. Mass Overreach by Agent Manufacturers
Similar controversies to the ZCode event have occurred more than once this year.
In July this year, independent security researcher cereblab conducted a complete network packet analysis of xAI's Grok Build and publicly disclosed all evidence and reproduction steps.
The phenomena he discovered were even more exaggerated than ZCode; Grok Build would package the user's entire project into a code package uploaded to Google's cloud storage service, with the upload covering all files, including those explicitly told by the user in conversation to the AI "not to read." In a 12GB test project, the confirmed file size reached over 5GB up to the point the packet capture was interrupted.
The tests also revealed that password and key files in the project were uploaded as they were, without any desensitization. Even after the user turned off the "improve model" option in settings, uploads continued as usual; only the training authorization was disabled, while it did not affect whether the code left the computer.
After the event was exposed, Musk publicly promised to delete all uploaded data, and xAI disabled the upload function on the server side.
Earlier, on March 31, during a version release of Claude Code, an oversight in a configuration file led to approximately 60MB of source mapping files being accidentally packaged into the public release installation package, allowing external developers to see the architecture of the tool.
The community found that Claude Code polls the Anthropic server for remote configurations once every hour, with several configuration items containing control switches that could force the program to exit and override user permission prompts, all operational in the background without requiring the user to actively update.
Claude Code has been found to read users' proxies, gateway addresses, and Chinese time zones, and transmit classification results back to the server through hidden characters in system prompts. Anthropic engineers even later confirmed that this was a proactive experiment for countering account abuse and counter-distillation.
Subjectively, Claude Code is an intentionally acknowledged experiment by the manufacturer; Grok Build has yet to deny the existence of the upload mechanism; and there is still no conclusion on ZCode's intent.
In terms of the scope of data collection, Grok Build even transmitted files explicitly stated by the user as "do not read," while ZCode packaged 86.6% of project history. Claude Code transmitted behavioral metadata; the scales are different, but the nature also involves the right to know.
All three incidents are alarming in that they were discovered by coincidence: one due to a configuration mistake leading to source code leakage, another through proactive packet capturing by a security researcher, and the last due to a blogger's alertness to anomalies in disk space usage, with none arising from the manufacturers' proactive debugging, industry audits, or regulatory inspections.
When ZCode was launched in July, ZCode's marketing directly targeted Claude Code, just weeks after the telemetry controversy surrounding Claude Code, positioning ZCode as an alternative option "free from being remotely controlled by manufacturers." The upload incident with Grok Build also occurred in July, almost coinciding with the launch of ZCode.
Three months later, an issue of the same nature was uncovered in ZCode itself, with an even larger data scope. Those who played the trust card first encountered a setback, which likely marks the most cautionary scene in the competitive landscape of AI tools this year.
5. Safety Rules Only Apply Externally
Agents have received permissions this past year that exceed those of any software previously installed on personal computers.
They can read all files in the current project directory, execute command-line operations autonomously, while always maintaining a connection to the manufacturer's server, and can also receive remote configuration updates in the background.
Before this, very few consumer-grade software met these four conditions simultaneously, and safety rules surrounding these new permissions have indeed been rapidly updated over the past year.
By the end of 2025, the international application security organization OWASP released the first top ten risk list for autonomous AI Agents; in January 2026, Singapore introduced the first governance framework for autonomous AI Agents, requiring each Agent to carry a verifiable digital identity; in February, the National Institute of Standards and Technology in the U.S. launched an AI Agent standards initiative; and on August 2, the high-risk obligations of the EU Artificial Intelligence Act officially took effect. Industry-specific certification standards for programming Agents have also emerged.
The number of rules is increasing, but they are defensive against tools being exploited by external attackers, such as being hijacked by malicious commands or induced to exceed permission calls to other systems.
The entire defense line is designed under the assumption that manufacturers are on the user's side, with threats coming from the outside.
The data exfiltration channels of ZCode and Grok Build precisely fall within this assumption's blind spot; they are not on the capability list of AI tools and fall outside the jurisdiction of permission approval processes, running independently of the entire tool cycle, with the AI assistants themselves being unaware of their existence. Using any existing security framework to scrutinize these actions one by one will not trigger alarms.
Some proposals have suggested that Agent data behaviors should be audited similarly to how public companies' financial reports are audited.
This analogy holds partially; regular, standardized audit reports issued by independent third parties that are comprehensible to buyers would be the right form.
However, financial audits focus on legal requirements mandating companies to maintain accounting records; there are no regulatory requirements for manufacturers to maintain records of "what data left the user's computer," so the evidence itself is insufficient;
Agent clients may update weekly, some even polling remote configurations to change their behavior hourly, causing any annual audit report to become outdated at the moment it is issued.
Public company audits have the backing of securities laws and the joint liability of auditing bodies; currently, nothing exists behind Agent audits.
Open source is another widely discussed path. ZCode committed to open sourcing its code library after this incident, and OpenAI's Codex CLI and the earlier Gemini CLI both adopted open-source licenses.
Open source allows the community to inspect whether similar exfiltration mechanisms exist in the client side; this transparency in itself imposes constraints. However, open source has several inherent boundaries. It can only illuminate the client side, not the server side; nobody can see what happens after data is sent to the manufacturer's server.
If only the fixed version is open-sourced without the code at the time of the incident being published, it provides zero evidence for past behaviors, and users receiving compiled products from app stores or installers cannot verify whether they match the publicly available source code without specialized reproducibility validation.
Currently, there are several more pragmatic paths that are more feasible.
One is to require manufacturers to publicly disclose which server addresses Agents will connect to and what types of data will be transmitted, allowing anomaly traffic to be compared by independent tools. Cereblab's analysis of Grok Build was conducted using standard packet capture tools; if manufacturers proactively provided an outbound declaration, the verification costs would be significantly reduced.
Two is to leave a readable, exportable exfiltration log on the user's own computer, detailing the size, destination, and data type of each transmission, directly resolving the most glaring design flaw of "the encrypted package is generated on your machine, and you cannot see what is inside."
Three is to implement a liability insurance mechanism, allowing insurers rather than certification bodies to assess manufacturers' data behaviors; the former needs to pay for judgment errors, which is currently the only mechanism that can turn "thorough scrutiny" into economic incentives.
These solutions are not technically difficult but face challenges regarding motivation.
At present, there are only two forces pushing for their implementation: procurement reviews from enterprise clients and occasional exposures by the community. The former only covers enterprise versions, while the latter depends entirely on luck.
Thus, the underlying contradiction in this incident may be more challenging to address than security technology solutions.
In the scenarios of ZCode and Grok Build, it is the individual developers who click the "agree" button, while it is their employers and clients who bear the consequences of data leaks. The latter was not present in any consent processes from start to finish and had no channels to know their code had previously been packaged and uploaded.
The risk bearers and the grantors of authorization are not the same person; individual informed consent cannot structurally resolve this issue, regardless of how clearly the pop-up is worded or how prominent the switch is placed.
The realistic trajectory is highly likely to be stratified.
Large enterprises will include data behavior clauses and audit rights in procurement contracts, and the costs incurred will ultimately be reflected in prices; meanwhile, consumer versions used by individual developers will remain in a state where no one audits and no one is held accountable, but this happens to be where the vast majority continue to code in their spare time, and where they are also most likely to open company projects with personal accounts.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
