AI-generated Scripts in Code Creation

Do they Facilitate Supply Chain Attacks?

My short answer: Absolutely. That said, at the time of researching this article (October 2025), I didn't know of any confirmed case where this exact approach had been used. What I mean by that will become clear shortly. First, though, it helps to clarify what I mean by Supply Chain in this context.

The Supply Chain

In short, Supply Chain describes the entire path of an artifact: from building to storing it in a package repository. At some point, the software ends up in centralised repositories from which ready-made modules can be consumed. These modules can be pulled into your own programs or scripts via the command line or configuration files. Common examples include:

• npm for JavaScript
• Cargo for Rust
• PyPI (pip) for Python
• PowerShell Gallery for PowerShell
• NuGet for the .NET family
• Terraform modules for Terraform

The Risk of Compromised Packages

These mechanisms make our life a lot easier. At the same time, they carry real risks when packages within the chain are compromised. This has been recently brought to light by multiple incidents in npm ecosystems, where compromised individual packages were included millions of times.

One example is the documented supply chain attack on npm packages in September 2025, which exploited compromised maintainer accounts. Palo Alto Networks provides a technical analysis on this: npm Supply Chain Attack.

Attacks like these can also pave the way for larger data breaches. As happened in October 2025, where a data leak at a Discord third-party provider exposed access to Discord user data. A summary of the incident can be found at CypherLeap: Discord Third-Party Data Breach 2025.

More recent reports show that similar attack patterns are still observed and are not necessarily limited to a single platform. As discussed in Aviatrix report on npm / PyPI / RubyGems Supply Chain Attacks 2025 (January 2026), which further identifies typosquatting packages and the abuse of build- and CI/CD workflows.

Where AI Becomes relevant

So what does all of this have to do with AI? Fair question. Let’s take a quick look at how AI generated code and scripts are put together in the first place.

Don't worry, I'm not about to spend 200 pages explaining how a large language model (LLM) works. What matters here is: why a specific piece of code lands in the output, while others are not?

AI Generated Code and what it's made of

To put it short: An LLM draws from vast amounts of available data, such as GitHub or Stack Overflow. This data is then ranked, for example by programming language, popularity (GitHub Stars) or contextual relevance (Stack Overflow signals). Based on that hierarchy, the model decides which code snippets to use for the requested result. So far, so good. But how does this translate into an actual attack risk?

New Attack Vectors

Once it is clear which sources an LLM tends to favour, several new attack vectors emerge. One option is to create a GitHub project in the target language and push it to the highest rating. That project then references a supply chain module created by the attacker. Behind it could sit a program that duplicates and exfiltrates data behind the scenes. However, there is no guarantee that AI will actually suggest this code. This is where another method comes into play:

LLM poisoning

As the name suggests, the goal of LLM Poisoning is to contaminate data an LLM is trained on and deliberately influence the model. Scientific studies show that even a relatively small number of manipulated documents can be enough to do so. This recent study found that 250 contaminated files were enough to make a significant difference. This makes it possible to steer the AI toward using a specific piece of code in its generated output. I won’t go into the mechanics here. Those with academic curiosity will find plenty to dig into in the linked paper 😉 Instead, let’s look at what such an AI-assisted attack could look like in practice.

Example attack (Terraform)

Let's use Terraform as a concrete example. In this scenario, the AI is asked to create a Terraform script that connects to Azure Entra ID and manages groups as well as Microsoft Privileged Identity Management (PIM). A perfectly normal request, except that, in this case, an attacker has deliberately tailored their setup to exploit this exact scenario.

Insertion

The attacker creates a custom Terraform module that, alongside the intended behaviour, silently creates an additional account and assigns it global directory permissions. That account is then exfiltrated and used to harvest data and open further attack paths via the Graph API. The whole thing is fed into the LLM using the methods described earlier.

Module Confusion

The legitimate module is published as [hashicorp/azuread]. The manipulated version is named [hashicoгp/azuread]. The difference is hard to spot, but if you look really close, you'll realise, one ‘r’ comes from the Cyrillic alphabet. This causes references to quitely point to the attacker's module, which – once suggested by AI – can end up in thousands of projects.

Since the code runs without errors during testing, it is rarely questioned further. After all, who takes a closer look at working code just because it came from an AI?

Final Thoughts and Conclusion

I must admit that in this case, spotting the trap would not have been easy at all, as the sources look almost identical. To ensure being on the safe side though, it helps to copy module names directly from the Terraform website. The same attack pattern can be applied to many different supply chains and scenarios.

The takeaway is simple: AI is a tool that is helpful, but not one to be trusted blindly. Especially with system-critical components.