The interesting thing about DUSTMAKER is not that it forges a signature. It is that it does not have to.
Google Threat Intelligence Group published its AI Threat Tracker report, "From Prompting to Autonomy: The Evolution of Adversarial AI", on 8 September 2026. Buried in it is a description of a credential stealer that inverts how most people assume supply chain attacks work. DUSTMAKER does not defeat cryptographic verification. It steals the identity that makes verification meaningful, and then lets the ecosystem sign its malware for it.
What DUSTMAKER actually does to the build
GTIG describes the sequence directly:
DUSTMAKER samples contain functionality to detect when it is running in a continuous integration and continuous delivery (CI/CD) environment. If confirmed, it extracts OIDC tokens from the process memory of GitHub Actions runners. Using these tokens, DUSTMAKER authorizes itself as a trusted publisher and publishes compromised versions of packages with valid, cryptographically signed SLSA Build 3 attestations. Packages published with valid tokens will pass AI coding agent automated trust checks.
Read the last sentence twice. It is a statement about tooling, not about cryptography. The attestation produced at the end of that chain is not a forgery. It is a real signed statement, made by the real build system, under a real publisher identity, about an artifact that happens to contain a backdoor. Every verifier downstream will agree it is valid, because it is.
Two supporting details make the trail harder to pick up. GTIG reports that DUSTMAKER masquerades its CI/CD pipeline tasks under innocuous names such as "Copilot Setup", so a human skimming a workflow sees a plausible step. And it deletes workflow execution logs through automated API calls, which removes the record of the publish step behaving oddly. What survives is the signature, and the signature looks correct.
The signature was never answering that question
It is worth being precise about what an attestation is for, because the industry has spent several years encouraging people to treat it as a safety signal and it was never built as one.
An attestation is a signed statement about the provenance of an artifact: where it was built, by which workflow, under which identity. It answers a question about origin. It does not, and structurally cannot, answer a question about content. Nothing in a provenance record inspects what the source code does. If the build identity is legitimate, the statement is true, and the statement remains true when the inputs to that build are malicious.
Verification covers the segment after the identity is established. DUSTMAKER operates before it, which is why nothing downstream reports a problem.
So there is a gap between the question the signal answers and the question the consumer is asking, and the gap is invisible in normal operation. A package with valid provenance really is more trustworthy than one without it, on average, which is exactly what makes the signal worth stealing. The failure mode only appears under an adversary who has worked out that the cheapest way through a verification gate is to walk in holding a genuine key.
This is a pattern we have written about in a different setting: an approval that was valid when it was granted and no longer valid when it was used. The shape is the same. A credential answers a question at one moment, something downstream treats the answer as durable, and the window between them is where the attack lives.
Refusal as an evasion technique
There is a second finding in the report that deserves its own attention, because it is a genuinely new class of trick.
GTIG found adversarial text embedded inside a DUSTMAKER JavaScript loader. The text was not aimed at a human reviewer and not aimed at the runtime. It was aimed at LLM-based security scanners, and its purpose, in the report's assessment, was to cause those scanners to fail or skip analysis of the malicious JavaScript underneath because of safety or policy refusals. The content is extreme enough that quoting it here would serve no purpose. What matters is the mechanism: the attacker discovered that a scanner which refuses to engage with a file is, from their point of view, identical to a scanner that found nothing.
A conventional scanner has no refusal state. It parses, it matches, it reports. An LLM-based scanner has a refusal state, and that state is reachable by the file under inspection. Any analysis pipeline built on a model needs to treat "the model declined to answer" as a distinct outcome that escalates, never as a pass. That is a small piece of plumbing and it is the difference between catching this and not.
Two MCP packages, and why that ecosystem is the soft target
GTIG attributes the supply chain activity to UNC6780, also tracked as TeamPCP, a financially motivated actor that began large scale open source compromises in March 2026. Two of the named victims are MCP packages: tiktoken_mcp, published to PyPI as a trojanized fork, and azure-functions-mcp-extension, where the official organizational GitHub repository itself was backdoored.
That targeting is not incidental. An MCP server is a dependency that is installed specifically so that a model can call it, which means a compromised one starts from a position most malware has to work for. We have argued before that connected context behaves like a dependency and should be governed like one, and separately that the trust boundary belongs at the protocol rather than the prompt. This report is the version of those arguments with incident names attached.
The persistence mechanism closes the loop. GTIG describes DUSTMAKER dropping files into hidden configuration directories, naming .claude/, .vscode/, .cursor/ and .openclaw/, and creating automated build or startup commands there. Malicious configuration in those locations can instruct the assistant to run arbitrary commands. These are directories that accumulate quietly and that nobody prunes, read automatically at startup, rarely reviewed line by line, and excluded from attention precisely because they are configuration rather than code.
What an agent should actually check
None of this argues for discarding provenance. It argues for knowing what each signal covers, and for not letting one signal stand in for a question it does not answer.
Three things follow directly from the report. Treat a valid attestation as an origin claim and keep content inspection as a separate gate, rather than letting the first satisfy the second. Treat a scanner refusal as an escalation rather than a pass, because an adversary can now reach that state deliberately. And treat agent configuration directories as executable surface under review, because the report documents them being used exactly that way.
The harder point is about automation. GTIG's sentence about AI coding agents passing packages on valid tokens is a description of a control that was designed for a world where obtaining a valid token was the hard part. Once an attacker can hold a real one, a gate that checks only for its presence is not a gate. It is a filter that removes unsophisticated attackers and waves through the ones who read the documentation.
Where this leaves trust signals as context
Every signal in this chain is a piece of context an agent consumes before acting: a signature, a publisher identity, a config file, a scanner verdict. The agent cannot see how any of them were produced. It sees the conclusion, and it acts on the conclusion.
That is the work Datapace is concerned with, in its own domain of production databases: making the context an AI system acts on resolved and trustworthy, and governing what it is permitted to execute rather than trusting that it was told the right things. The lesson DUSTMAKER offers to anyone building in that space is specific and slightly uncomfortable. The more reliably a signal is consumed without inspection, the more valuable it becomes to compromise, and the ones we automate hardest are the ones worth stealing first.
Sources
- Google Threat Intelligence Group, "GTIG AI Threat Tracker: From Prompting to Autonomy, The Evolution of Adversarial AI", 8 September 2026. cloud.google.com