This report is about what development teams do every day
Teams that use AI coding assistants add external MCP servers and editor extensions, clone a repository and build it right away, and ask the AI to “set this environment up.” The entry point this report describes is inside those everyday actions.
In September 2026, Google Threat Intelligence Group (GTIG) published a report on AI threat activity describing how UNC6780 (TeamPCP), a financially motivated actor, targets AI development tools. GTIG observed that since March 2026 this actor has carried out repeated supply-chain compromises on PyPI, npm, and similar registries, compromised legitimate developer accounts to publish tampered forks of MCP servers, and injected malicious code into organizations’ official repositories. MCP (Model Context Protocol) is a common mechanism for connecting AI assistants to external tools and data.
DUSTMAKER, the credential-stealing malware described in the same report, has several capabilities. It places files in a project’s .claude/, .vscode/, and .cursor/ directories to plant commands that run automatically when an IDE or AI extension opens the workspace, and it uses instructions in configuration files to have an AI assistant execute commands. It also publishes tampered packages as a legitimate publisher, using tokens extracted from CI/CD environments. The code also contained strings that GTIG assesses were meant to interrupt analysis by AI-based security scanners.
This is not a report that MCP, Claude Code, Cursor, or VS Code were themselves compromised. It is a report that the external assets developers trust and pull in, and the configuration areas their tools read, were used.
Configuration, external content, and execution permissions are connected
In a development environment, three things move together: external content such as packages, MCP servers, and cloned repositories; the configuration files inside the project that tools read; and the execution permissions granted to the tools and to the AI assistant. Pull in external content and its configuration files come with it.
A configuration file can cause code to run in two ways, and they work differently.
- Automatic startup and build processing — where the configuration defines startup or build hooks and the tool is set to run them automatically, the processing runs at whatever point was configured: opening the workspace, building, and so on. No AI judgment is involved, and it is the same class of problem as malicious code slipped into a conventional build script.
- Command execution through the AI — prompt injection refers to the AI treating externally sourced text as instructions from the user. It can happen even without command-execution permissions, for example by steering the output. The path highlighted in this report is the one where that AI is allowed to execute commands and follows external text in doing so.
Both paths need execution approval and limited permissions. They are worth checking separately because you look in different places. The automatic path is on the side of the tool’s settings and the external content you bring in; the AI path is on the side of the AI’s permission settings and the practices that keep external text from being treated as instructions. And the reach of whatever does run is determined not only by credentials but by its execution permissions and the destinations it can reach.
Three areas to check
The items below are our reading of the report. The right-hand column is what each check lets you determine.
| Area | What to check | What it tells you |
|---|---|---|
| External tools | The inventory and origin of MCP servers, extensions, and dependencies (official or a fork, and who the publisher is) | Whether “the name looks similar” is the only basis for trusting them |
| External tools | Whether you have a practice of reviewing the configuration areas of a cloned repository (.claude/, .cursor/, .vscode/, and the like) before opening it, and how automatic execution is enabled or disabled | Whether you know what can run automatically, and when |
| Credentials | The inventory, scope, and expiry of tokens and keys on developer machines and CI runners | What could be reached if something were executed |
| Credentials | Which CI workflows hold permissions such as package publishing | Whether there is a path for a tampered version to be published as a legitimate publisher |
| Execution permissions | The execution scope granted to the AI assistant, the actions that run without confirmation, and the destinations it can reach | The extent of the impact if a command is executed through the AI |
| Execution permissions | Whether changing workflows or deleting logs requires approval, and whether it can be audited afterwards | Whether traces of an attack remain or can be erased |
Where to start
We suggest starting with a single table that maps the AI tools and MCP servers you use to their destinations, the credentials they use, what they are allowed to run, and who administers them. Laid out that way, you can confirm from a list rather than from guesswork: whether any MCP server has an origin and an administrator you cannot account for, whether any token has no defined scope or expiry, and which actions the AI can run without confirmation.
Then set priorities against that table: stopping tools whose origin you cannot confirm, narrowing the scope and expiry of tokens, revisiting publishing permissions in CI, and reducing what the AI runs automatically. The rule of thumb is to replace “we added it because it was convenient” with “we need it for the work, and we can account for its origin and its permissions.” Update the table whenever a new tool is added, and the review stays current.
Talk to us
Our AI security consulting includes a security assessment of AI coding practices, which assesses risks in the AI usage procedures and code review processes of your development teams. To discuss a review of your own development environment, use the contact form.
Reference materials
- Google Threat Intelligence Group, GTIG AI Threat Tracker: From Prompting to Autonomy – The Evolution of Adversarial AI, Google Cloud Blog, published September 8, 2026 (per Google’s published metadata). Checked September 21, 2026.
The factual summary in this article is based on the sections of that report covering AI-assisted development and supply-chain risk, together with its Tables 1 and 2. The checklist and the suggested first steps are U-Rec, Inc.’s analysis and proposals drawn from the report.