The debate over Agent security over the past two years has largely centered on model misalignment, prompt injection, and external attackers. In comparison, the data handling practices of Agent manufacturers themselves have rarely been treated as a first-order risk.

The recent Z.AI ZCode incident is shifting the focus toward a direction that has seldom received serious attention: whether the makers of Agents might themselves become a source of data exfiltration.

On September 18, tech blogger ferstar published a reverse engineering analysis of ZCode. He discovered that once a user logs in, ZCode packages the entire working project along with its full modification history, encrypts it, and uploads it to a cloud server in the background.

The software interface lacks a truly functional toggle to disable this behavior, and the decryption key for the encrypted files is held solely by Z.AI’s side. Z.AI quickly apologized, stating the issue stemmed from a feature that was enabled by default, that data was destroyed after use, and promising to open-source its codebase and introduce third-party audits in the near future.

The problems exposed by ZCode are far from isolated within the industry.

Not long ago, independent security researcher cereblab demonstrated through packet capture analysis that xAI's coding Agent tool, Grok Build, uploads users' entire projects to Google Cloud Storage, including files the user explicitly told the AI not to read, as well as unredacted passwords.

Even earlier, Claude Code was found to transmit location and identity information back without user knowledge, with an Anthropic engineer later confirming it was an intentional experiment.

More critically, these issues were discovered not through regulation or security audits, but by individuals within the community, and the current security frameworks built for Agents have no rules governing the behavior of manufacturers themselves.

Where the trail began: an abnormal hard drive

On September 18, tech blogger ferstar noticed abnormal hard drive usage while inspecting ZCode's local directory. He found an encrypted file of approximately 313MB, far larger than typical sizes. The file could not be opened, but an accompanying file manifest revealed it contained roughly 42,000 files, over 80% of which were project history modification records.

These records encompassed not only project files but also cached downloads of large files and local operation logs. What was packaged was not just the project itself, but the project's entire "life story since birth."

Subsequent code analysis revealed that this history record was exempted from all security filtering rules during the packaging process.

ZCode's file filtering logic operates sequentially, with the history record directory being allowed through before key filtering and size limits. This means that filters targeting password files like .pem and .key, as well as the 1MB size cap, have no effect on anything within the history record directory.

This means a packaged file of hundreds of megabytes can be taken in its entirety, and any passwords or keys that were once committed to history and later deleted would also be uploaded as-is.

The more problematic operation comes later: the decryption key is not on the user's computer.

ferstar deconstructed the upload path: first, the client requests an upload credential and a public encryption key from Z.AI's server; then, after local compression and encryption, it bypasses Z.AI's own business server and goes directly to Alibaba Cloud's storage service, which then calls back to Z.AI's backend.

A brief explanation of the encryption method is warranted here.

A public key acts like a lock—anyone can use it to seal items in a box. A private key is the key; only the holder can open it. ZCode's approach is that the lock is temporarily issued by the server, and the key is stored only on the server side. The Agent generates an encrypted package on the user's computer, and the user themselves cannot see what's inside.

ferstar found this mechanism triggers at two points: before the user sends a request to the AI, and after a task concludes. During an active session, he observed up to 62 snapshot records.

The two seemingly related options in the interface, upon his line-by-line comparison with the code logic, were confirmed to be: one, "Optimize Experience," which only controls whether data is used for model training; and two, "Repository Snapshot Index," which only controls whether the server establishes a search index after receiving data.

When both are toggled off, local packaging and uploading continue to run as usual. The components responsible for snapshots and uploads load unconditionally at startup, with the only prerequisite being that the user is logged in.

Beyond project files, each snapshot also packages ZCode's own global configuration, carrying it across projects.

ferstar attempted to manually delete the 313MB pending file. Half an hour later, ZCode automatically regenerated a new package. When the Agent fails to upload surreptitiously, it retries persistently.

Deleted, only to be recreated—this persistence seems beyond what an optional auxiliary feature should exhibit.

Unanswered questions in the response

The article quickly gained traction in the community that evening, and Z.AI responded and apologized swiftly.

The issue originated from ZCode's "Codebase Index" feature. This feature aimed to help users generate a repository index locally, supporting session checkpoint recovery, historical version rollback, and Repo Wiki functions, including historical versions.

The Repo Wiki function could trigger repository data uploads when generating Wiki pages. Wiki pages are generated in the cloud, and after generation, the uploaded data is immediately destroyed and not retained. As this feature was enabled by default during its initial launch, some users were affected. We deeply apologize, and the issue has now been fixed.

Z.AI also promised to open-source the ZCode codebase soon, invite third-party assessors to review system operations, and compensate all users with an additional weekly quota reset, distributed the same day.

The "Codebase Index" is for creating a directory and search system for project files; "Repo Wiki" is a feature that automatically generates a documentation file for a project; "Session Checkpoint Recovery" and "Historical Version Rollback" allow users to return to a previous step during conversations with the AI.

These features themselves are reasonable, and the response was timely. However, the key issue is:

What was explained and what the community questioned are not the same thing.

Z.AI stated the index "aims to help users generate it locally." If it's generated locally, why does the entire project need to be sent to the cloud? Local indexing, local snapshots, and local rollback are technically entirely feasible, and existing tools on the market do exactly that.

Conflating "local indexing" with "uploading to the cloud" as if the latter is a natural extension of the former misses a critical explanatory step in between.

The response attributed the issue to Repo Wiki "potentially triggering repository data uploads when generating Wiki pages." However, ferstar's reverse engineering records show one of the upload triggers occurs before every user query, unrelated to generating documentation.

ZCode's current official documentation explicitly states that generating documentation does not read a project's history of modifications, only selectively filtered code context as needed. This indicates the feature technically doesn't require history records.

So why did 86.6% of the previously uploaded package consist of history records? The statement does not explain why the upload scope was so large, whether it was by design or a program error, nor does it specify from which version the fix begins.

The wording "enabled by default during initial launch" seems more like framing a mechanism-level data exfiltration as a feature toggle setting.

ferstar's code analysis shows the two interface options—one for training, one for indexing—neither controls the packaging and uploading behavior itself.

The core of the community's concern is that the controls visible to users do not control what is actually happening. This is not a problem of the same magnitude as "a feature was turned on by default."

Soon, another more sensitive piece of evidence was unearthed by the community: the changelog for ZCode v3.12.2, dated September 16, 2026, just two days before ferstar's post.

One entry read: "Optimized memory usage for repository snapshot uploads." An engineering team would hardly optimize memory for an accidental behavior. This suggests "repository snapshot upload" was an internally sustained, normal feature under continuous iteration.

After the incident gained traction, this changelog entry was deleted. Deleting public records is itself a new issue, separate from the original behavior.

"Related upload data is immediately destroyed and not retained" answers how long data is kept, but users genuinely need to know much more: Has the data already left the computer? Who has access to it during server-side processing? Who holds the decryption capability for the encrypted package? What deletion policy was executed on previously uploaded data?

Given the encryption method, with the key held server-side, "encrypted upload" proves the data cannot be intercepted by third parties during transit, but it does not imply that Z.AI itself cannot read the content.

The English version of ZCode's privacy policy describes the collection scope as text, files, and code submitted by users "through conversation." However, background snapshots are not submitted by users through conversation; this behavior falls outside the privacy policy's description. "Submitting to us during a conversation" and "background automatic packaging of the entire project" are two different matters.

The privacy policy also states that when new features involve information collection not directly or reasonably related to the original purpose, users should be separately informed and their consent obtained through page prompts, interaction flows, or other means.

Another developer, Feng Ruohang, found through code analysis that the client unconditionally requests an upload credential from the server each time a question is sent; the server grants the credential and collects data, or doesn't grant it and doesn't collect.

The 313MB file ferstar discovered was in a pending state, having failed 564 times. Feng Ruohang independently replicated ferstar's forensics process on his Mac across four workspace snapshot records, confirming at least one snapshot's status file contained a marker indicating server-side acceptance.

According to the code logic, this marker is only generated after the server confirms receipt of the upload. This means data from at least one machine did indeed leave the local environment. Z.AI's apology, promises, and compensation were all delivered within hours of the controversy escalating—a response speed not indicative of planning a long-term cover-up.

However, promises like "immediate destruction" or "not retained" cannot be verified or falsified externally. Users can only see data leave their computers; what happens afterward depends entirely on the manufacturer's self-restraint.

Whether Z.AI's promise of open-sourcing and third-party audits can change this depends on which version is open-sourced and whether the review covers the client or the server—questions that currently have no answers.

More sensitive than code data itself

If some manufacturers truly intended to collect user data deliberately, what they'd want might not be the code itself.

Public projects on major code hosting platforms already provide ample corpora for model training. Private code certainly contains trade secrets, but from a model improvement perspective, the marginal value of merely obtaining another batch of code text is low.

What's truly scarce are three things.

First, the causal chain of changes.

A project's history of modifications stores not just snapshots, but the complete process of "what it looked like before, why it changed, and what it became." This sequence with cause and effect is the ideal learning material for training programming models: given a project's current state and a modification intent, what change should the model make.

Second, usage trajectories with outcome labels.

ZCode's trigger mechanism takes a "panoramic photo" before each user query, and it also has a rollback feature allowing users to undo AI-made changes. Combined, these two actions naturally record the full loop of "query + pre-operation state + post-operation state + user satisfaction (whether undone)." This type of data is extremely expensive in AI training, typically requiring dedicated human annotation. ZCode's snapshot mechanism effectively lets users generate these labels for free during normal use.

Third, real projects never seen by any model.

Currently, public coding benchmark questions have almost all been "solved once" by various models during training, leading to inflated scores. Real, private projects that have never entered training sets are the most valuable raw material for internal capability evaluation.

These three items align closely with the composition of ZCode's upload packages. This is why the community has remained unconvinced by the "just for generating documentation" explanation.

Conversely, if the goal were truly systematic collection of training data, a more precise approach would extract only query content and code changes. There would be no need to package hundreds of megabytes of large file caches and full operation logs.

This pattern of over-collection more likely reflects an engineering team reusing generic packaging logic when developing the snapshot feature, bundling all files related to indexing and rollback into one package. Additionally, cloud storage has costs; the training value of numerous individual users' small projects and practice code is limited, and targeting paying customers—especially enterprise clients—presents a poor risk-reward ratio.

It must be acknowledged that the motivation to use this data to improve models and tools is plausible and the path is well-trodden. But given the crude nature of the upload packages, "aggressive product decisions combined with engineering laziness" fits the existing evidence better than "Z.AI deliberately intended something."

Of course, the severity of this issue shouldn't be downplayed simply because intent may be absent. It does create genuine security risks for users.

Manufacturers acting beyond boundaries

Incidents similar to ZCode have occurred more than once this year.

In July, independent security researcher cereblab conducted a complete network packet analysis of xAI's Grok Build and published all evidence and reproduction steps.

What they found was even more egregious than ZCode: Grok Build packages users' entire projects into code bundles and uploads them to Google's cloud storage. The upload scope covers all files, including those the user explicitly told the AI "not to read." In one 12GB test project, confirmed file volumes exceeded 5GB by the time packet capture was interrupted.

Testing also found that password and key files within projects were uploaded as-is without any redaction. Disabling the "improve model" option in settings did not stop the upload—it only toggled the training authorization, not whether code leaves the computer.

After the incident was exposed, Musk publicly promised to delete all uploaded data, and xAI disabled the upload function server-side.

Earlier, on March 31, during a version release of Claude Code, a configuration file oversight led to approximately 60MB of source map files being mistakenly bundled into the public installer, allowing external developers to glimpse the tool's architecture.

The community discovered that Claude Code polls the Anthropic server hourly for remote configuration, with configuration items containing multiple control switches capable of force-quitting programs and bypassing user permission prompts, all effective in the background without requiring user updates.

Claude Code was also found to read environmental signals like user proxy, gateway addresses, and China timezone, then transmit classification results back to the server via hidden characters in system prompts. An Anthropic engineer later confirmed this was an active experiment for anti-account-abuse and anti-distillation purposes.

By degree of intent, Claude Code is an experiment conceded by its maker; Grok Build hasn't denied the upload mechanism's existence; ZCode's intent remains undetermined.

By data collection scope, Grok Build transmitted files users explicitly said "don't read"; ZCode packaged 86.6% of project history; Claude Code transmitted behavioral metadata—a different magnitude but with the same breach of informed consent.

What warrants concern about all three incidents is that discovery was always accidental: one via a configuration error leaking source code, one via a security researcher's proactive packet capture, one via a blogger's suspicion about hard drive space. None came from spontaneous debugging by manufacturers, industry audits, or regulatory inspections.

When ZCode launched in July, Z.AI's marketing directly benchmarked it against Claude Code, which had faced telemetry controversy just weeks prior. ZCode positioned itself as an alternative that "frees you from remote control by manufacturers." Grok Build's upload incident also occurred in July, almost the same month as ZCode's launch.

Three months later, a problem of the same nature surfaced in ZCode itself, with an even larger data scope. The one selling trust fell first—perhaps the most cautionary tale in this year's AI tool competition.

Security rules only point outward

Agents have been granted more permissions in the past year than any previous category of software installed on personal computers.

They can read all files in the current project directory, execute command-line operations autonomously, maintain constant connection to manufacturer servers, and receive remote configuration updates in the background.

Before this, almost no consumer-grade software simultaneously met all four conditions. Security rules for these new permissions have indeed been rapidly updated over the past year.

In late 2025, OWASP released its 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, NIST launched an AI Agent standards initiative. On August 2, the EU AI Act's high-risk obligations took effect. Industry-level certification standards specifically for coding Agents have also emerged.

The number of rules is growing, but they guard against tools being exploited by external attackers—for example, hijacked by malicious instructions, or induced to exceed permissions and invoke other systems.

The entire defense line is designed on the assumption that manufacturers side with users, and threats come from outside.

The exfiltration channels of ZCode and Grok Build sit precisely in the blind spot of this assumption. They aren't on the AI tool's capability list, aren't governed by permission approval processes, run outside the tool loop entirely, and are imperceptible even to the AI assistant itself. Reviewing them against any existing security framework line-by-line, none of these behaviors would trigger an alert.

Some suggest auditing Agent data behavior the way public companies' financial statements are audited.

This analogy partially holds. The format—periodic, standardized, issued by independent third parties, comprehensible to buyers—is correct.

But financial audits examine ledgers that companies are legally required to maintain. "What data left the user's computer" is a record no regulation requires manufacturers to keep—the evidence base itself is insufficient.

Agent clients may update weekly, some even poll remote configuration hourly to change their own behavior. An annual audit report would be outdated the moment it's issued.

Behind public company audits stand securities law and auditors' joint liability. Behind Agent audits, there is currently nothing.

Open-sourcing is another widely discussed path. Z.AI promised to open-source the ZCode codebase after this incident, and OpenAI's Codex CLI and earlier Gemini CLI both adopted open-source licenses.

Open-sourcing allows the community to inspect the client for similar exfiltration mechanisms. This transparency itself creates constraint. But open-sourcing has several natural boundaries. It only covers the client, not the server—what happens after data reaches the manufacturer's servers is invisible to anyone.

If only the patched version is open-sourced without releasing the code as it existed at the time, it proves nothing about past behavior. Furthermore, users obtain compiled binaries from app stores or installers; whether those match the publicly available source code is unverifiable without dedicated reproducible builds.

More pragmatic paths currently available are more feasible.

First, require manufacturers to publicly declare which server addresses Agents connect to and which data categories are transmitted, allowing anomalous traffic to be cross-referenced with independent tools. cereblab's analysis of Grok Build used standard network packet capture tools; if manufacturers proactively provided egress statements, verification costs would drop dramatically.

Second, keep a readable, exportable exfiltration log on the user's own computer, specifying each transmission's volume, destination, and data category. This directly resolves the most glaring design issue: "an encrypted package is generated on your machine and you can't see what's inside."

Third, liability insurance mechanisms, where insurers rather than certifying bodies assess manufacturers' data behavior. Insurers must pay out for misjudgments, making "serious review" the only mechanism with direct financial incentive.

None of these proposals are technically difficult. The difficulty lies in motivation.

Currently, only two forces drive their implementation: enterprise clients' procurement reviews and sporadic community exposure. The former only covers enterprise editions; the latter relies entirely on luck.

So the underlying contradiction in this incident may be harder to resolve than any security technology solution.

In the ZCode and Grok Build scenarios, the individual developer clicks "agree," but the consequences of data leakage are borne by their employer and clients—parties who never appear in any consent flow and have no channel to learn their code was once packaged and uploaded.

The risk bearer and the authorizer are not the same person. Individual-level informed consent structurally cannot solve this problem, no matter how clearly the pop-up is written or how prominently the toggle is placed.

The realistic trajectory is likely stratification.

Large enterprises will add data behavior clauses and audit rights to procurement contracts, with costs ultimately reflected in prices. Consumer versions used by individual developers will continue in a state where no one audits and no one is accountable—yet this is precisely where most people continue coding outside work hours, and where they most easily open company projects with personal accounts.