Supply chain security for AI coding tools — why provenance attestation cannot replace code review

1. Executive summary

The software supply chain is the path through which a product is built and shipped, by way of external packages, source repositories and build tools. AI coding tools also pick packages, read settings and run commands along this path. In effect, the model's judgment and tool execution have been added to the existing supply chain.

The account of the incident rests on GTIG's observation report. The checklist below is our editorial proposal from comparing the incident with the npm, SLSA and GitHub documentation; it is not the result of an experiment that measured its defensive effect.

2. What Google observed and what it inferred

GTIG reports on the financially motivated threat actor UNC6780 (TeamPCP) and its credential-stealing malware DUSTMAKER. Credentials are authentication data, such as tokens and keys, that give access to accounts or services. The report presents capabilities confirmed in the malware alongside inferences about the attacker's intent, so the two need to be read separately. [1]

MCP (Model Context Protocol) is the protocol AI apps use to connect to external tools and data. What this incident involves is the distribution path of the software used for those connections. Reading it as a flaw in the MCP specification itself would change the scope of the investigation.

GTIG raises the possibility that, as AI coding sped up development, scrutiny of third-party dependencies declined. But this report alone cannot tell you how much AI adoption raised the incident rate. It is not a causal experiment with a comparison group and a known exposure size; it is observation gathered from threat tracking and incident response.

3. What provenance attestation guarantees

Provenance is information that records who built a piece of software, from what inputs and by what process. An attestation is a statement that carries such information, and the signature attached to it is used to check that it is authentic. SLSA is a specification that defines levels of security assurance for the software supply chain. SLSA Build L3 requires a hardened build environment, including isolation between builds and protection of the secrets used for signing. The presence of a signature alone does not show that all of these requirements are met. [2]

npm's trusted publishing authenticates a CI/CD workflow you have registered so that it can publish a package. CI/CD is the automated process that checks, builds and deploys code, and a workflow is the file that defines its steps. Because it verifies the identity of the runtime environment through OIDC (OpenID Connect), it reduces the need for long-lived publishing tokens. For GitHub Actions, npm has you register the organization, repository and workflow file. [3]

GTIG's Table 1 describes DUSTMAKER as able to abuse the OIDC tokens of GitHub Actions runners to publish malicious packages. GTIG states that these packages come with validly signed SLSA Build L3 attestations (the report's wording: SLSA Build 3). This is a citation of GTIG's technical description. The public report does not provide enough information to independently re-verify that build environment's configuration against the SLSA requirements. [1]

The SLSA FAQ states that a Build level covers the trustworthiness of a single build and sets no requirement that transitive dependencies reach the same level. Transitive dependencies are packages that get installed indirectly because a package you install depends on them. So one package's Build level cannot be stretched into a security verdict on all of its dependencies. [4]

Operationally, first confirm that the provenance matches the expected repository, commit and build process, then review dependency changes and runtime behavior separately. Going back from trusted publishing to long-lived tokens is not the answer. npm itself recommends preferring trusted publishing, removing legacy publishing tokens you no longer need, and applying review steps to deployment environments. [3]

4. Workspace settings are an execution path too

GTIG reports that DUSTMAKER creates or modifies files in project settings folders such as .claude/, .vscode/ and .cursor/. Such files can be used to run startup tasks or build commands automatically, or to change how AI tools behave. If you exclude these from change review because the folder names are familiar, you can miss execution paths outside the application source. [1]

Prompt injection is an attack that gets instructions embedded in external documents or code handled as if they were the AI's real task instructions. Two cases need to be kept apart: the model reads the settings and then runs a command, or the editor's startup settings run a command directly. When the model is in the path, instruction handling and tool permissions come into play. When the editor's startup settings run a command directly, check the editor's execution settings and permissions.

GitHub's official documentation recommends pinning third-party actions to a full-length commit SHA and reviewing their source. A SHA is the value that identifies a specific commit. Pinning reduces the risk that the code a tag points to changes later, but whether the commit you picked is safe in the first place has to be checked separately. The documentation also advises applying code-owner review to workflow files and giving tokens read-only permissions by default, adding more only for the jobs that need them. [5]

5. An aborted analysis is not a pass

The malware comments GTIG found contain instructions that were likely meant to make AI security analysis tools refuse to analyze the code on safety-policy grounds. An attacker may try to change the result of an analysis, but may also try to keep the analysis from finishing at all. The observation that matters here is that such instructions were included in the malware; the report gives no actual bypass success rate. [1]

Our proposal is to separate a scan's execution status from its security verdict. The table below is not a description of any product's features; it is a status design you can use when connecting scan results to your deployment process.

For example, a deployment condition that says “the AI analysis returned an error, so treat it as having no warnings” can let unscanned code through. This is a hypothetical example for illustration. Recording the not-completed status and requiring a supplementary scan or review reduces this kind of logic error. There is no guarantee, though, that another analyzer will reliably catch the same attack, and that is no reason to disable an analysis tool's safeguards either.

Partial gaps only become visible if you keep both the list of target files and the list of files actually scanned. The operational point to check is that execution status, scan scope and findings are collected separately, instead of relying on a one-sentence summary from the AI.

6. Checklist to apply today

The items below are not a proposal to replace all your existing tools. They are a list of review steps to add to your current dependency intake and publishing process. We mark which items are direct GitHub or npm recommendations and which are our editorial proposals.

• Include workspace settings in change review. Check hidden folders for new execution settings and make sure they are not skipped in code review. An editorial proposal drawn from the GTIG case.
• Pin third-party actions to a reviewed full-length commit SHA. Review the action's source and keep applying security updates. Pinning by itself does not guarantee that the code is harmless. A GitHub recommendation. [5]
• Do not grant publishing permissions that tests do not need. Minimize default token permissions and raise them only for the jobs that need them. Do not run unreviewed outside code in privileged workflows. A GitHub recommendation. [5]
• Audit your trusted publishing registrations. Check that the allowed repositories and workflows match your current process, and remove publishing tokens you do not need. An npm recommendation. [3]
• Record provenance checks and dependency review separately. Even when provenance matches what you expected, review new packages and what they do at install time and at run time. An editorial proposal reflecting the scope of SLSA's guarantees.
• Check whether an incomplete scan is treated as a deployment pass. Simulate a timeout, an analysis error and skipped files with harmless test files, and check the resulting status. An editorial proposal you can test without any malware.

Agent execution isolation and approval design are covered in detail in our agent sandbox report. This article focuses on the paths by which outside code enters the development, publishing and scanning process.

7. What this is not yet

• We did not independently reproduce GTIG's observations. The incident and the malware capabilities are attributed to Google's report of September 9, 2026. They are not the result of Eazler analyzing affected environments or the malware directly.
• The increase in incident rates due to AI adoption cannot be calculated. The report's reading of the risk includes inference, and it provides neither a comparative experiment by whether AI was used nor total exposure counts.
• The success rate of interfering with security analysis has not been established. From the fact that malicious instructions were present and an inference about their purpose, we do not conclude that any particular AI product can be bypassed in general.
• We do not judge for ourselves whether the SLSA Build L3 case GTIG describes actually conforms. The build configuration and verification records are not public enough to check against every requirement of the specification. We do not treat publishing authentication, signatures and Build level as the same thing.
• We did not quantify the defensive effect of these recommendations. Least privilege, change review and not-completed handling all have limits in implementation and operation. Provenance attestation remains a necessary verification tool, and it does not replace a verdict on the safety of the code as a whole.
• This is not a list of currently infected packages. A project's name appearing in the report is not enough to judge whether its current version is safe. This article is meant for reviewing your intake, execution, publishing and scanning processes.

8. Sources

The account of the incident is attributed to GTIG, and product behavior to each official document. The operational proposals in the tables and checklist are our editorial interpretation from comparing these sources. We have not reproduced the malicious instructions or attack procedures from the original report.