Zod 4.6.7: provenance, code safety and AI clone resistance are different claims

Separate today's release from last month's incident

The official GitHub release records v4.6.7 at 16:30:32 UTC on October 12, 2026: 00:30:32 on October 13 in Beijing, at commit b500a2e; its full identifier is linked in the release record. npm separately records publication at 16:29:37.778 UTC. These are different clocks. This article covers the release and new clarification, not a new attack on October 13. We did not install or execute suspicious code.

A commit in release notes is not proof of a malicious distributed package

GitHub's September advisory says the malicious Zod repository changes never reached npm publishing. At 17:17:12 UTC on October 12, or 01:17:12 Beijing on October 13, the maintainer explained reverted commits in generated notes, history cleanup and 4.6.7, reporting an effect on 4.6.6 provenance. Registry metadata still lists attestation links for both versions. We did not cryptographically validate them. Neither current-package malware nor certification of either version is established here.

Verifiable origin still requires code review

npm documents provenance as a verifiable connection to source and build information, not a guarantee of malware-free code. Keep three questions separate: did we receive the expected bytes, do they connect to the expected source and build, and is their behavior acceptable? The first two do not establish the third. A digest, a signature indicator and a provenance link are not interchangeable, and none directly measures AI clone resistance.

For protection services, unreadability is not an excuse to skip review

Our engineering recommendation is to separate delivery acceptance from clone-resistance acceptance. Delivery records the input hash, authorized transformation, tool version, output hash and customer-side signing steps. Clone resistance compares functionally equivalent unprotected and protected builds under identical model, tool, time and spending budgets, using withheld behavioral tests. Complex control flow and unreadable strings are observations, not substitutes for either result. New installation scripts, network access or broader permissions require independent explanation and validation, even when presented as security features.

Let an AI agent help build without granting it every permission

A practical small-team workflow starts with an agent inventorying versions, official changes, file lists and installation hooks without automatically installing unknown historical commits. An explicit dependency policy then decides what may execute. Isolate builds from production secrets and customer content, and separate review, build and release authority. Disabling scripts can break legitimate dependencies: test a disposable copy and approve necessary scripts individually. Inspect the actual artifact and your own regression results rather than treating an agent's completion message as delivery evidence.

What we can—and cannot—conclude today

This is public-source review and engineering analysis, not a comprehensive Zod audit or an Anti-AIClone protection report. We ran no third-party attack, customer-app assessment or new security scoring. Provenance addresses origin; safety review addresses execution; replication experiments measure how much can be rebuilt under stated conditions. Separate evidence fields are more useful than one claim that encryption makes everything safe. Offline applications can use this delivery and assessment approach without adding a server dependency.

Your checklist

• Record repository events, GitHub releases and registry publication separately; do not relabel an old incident as a new attack.
• Pin delivered versions, hashes and build associations; an attestation link is not a passed verification.
• Start with a read-only agent inventory; authorize and isolate any installation hooks before execution.
• Assess delivery integrity, runtime behavior and fixed-budget replication separately.
• Validate legitimate functionality, offline behavior and signing compatibility first.
• Retain unknowns and failures; this article is not product certification or a new score.