AI coding agents and supply chain attacks: fake packages and what to check

Short answer: a supply chain attack compromises something you depend on instead of attacking you directly. AI coding agents raise the exposure because they install packages quickly and sometimes suggest names that do not exist, which attackers can register. Verify every new dependency, pin versions with a lockfile, disable install scripts where you can, and do not give an agent your production secrets.

What is a supply chain attack?

Your application is mostly other people's code. A typical web project pulls in hundreds of packages through its dependency tree. If an attacker can get malicious code into one of them, it runs on your machine or your servers with your permissions. Attack routes include:

• Typosquatting: a package named reqeusts waiting for a typo.
• Dependency confusion: a public package with the same name as your internal one, at a higher version.
• Account takeover: a maintainer's credentials are stolen and a malicious version is published.
• Hijacked abandoned packages: the original owner leaves and the name is transferred.
• Malicious install scripts: code that runs during npm install through postinstall.
• Compromised build or CI: the project is clean but the released artifact is not.

What changes with AI coding agents?

Language models sometimes recommend a library that does not exist. Researchers have measured this across several models. The name often sounds plausible and repeats across prompts. An attacker who notices a recurring invented name can publish a real package with that name and wait. The next person whose assistant suggests it, and who runs the install without checking, executes the attacker's code.

Agents also install without pausing. A person may notice an odd name when typing it. An agent in auto-approve mode runs npm install some-package as part of a longer task.

What should you check before adding a package?

• Does it exist on the official registry, and does the name match the project's own documentation exactly?
• How old is it, how many people download it, and does it have a linked source repository with real history?
• Who maintains it, and was there a sudden change of owner or a burst of releases?
• Do you need it at all? A ten-line function is cheaper than a dependency.
• Does it run install scripts? Look at scripts in its package.json.

Which habits reduce the risk?

• Commit the lockfile and install with npm ci, pnpm install --frozen-lockfile or the equivalent in CI. Builds then use exactly the versions you reviewed.
• Pin or tightly range versions, and review dependency updates as pull requests.
• Disable install scripts by default (npm config set ignore-scripts true, or pnpm's allow-list for build scripts) and enable them only for the packages that need them.
• Scan: npm audit, Dependabot or Renovate, and a tool like OpenSSF Scorecard or Socket for behaviour signals.
• Use a private registry or proxy that can hold back brand-new package versions for a few days. Many compromises are caught within hours.
• Use scoped names for internal packages and configure the registry so those scopes only resolve internally. That blocks dependency confusion.
• Turn on two-factor authentication and trusted publishing for packages you publish.

How should you set up an agent?

• Run it in a container or a throwaway development environment, not on the machine that holds your SSH keys and cloud credentials.
• Keep production secrets out of its environment. Give it a development token with minimal scope.
• Require approval for commands that install packages or touch the network, at least until you trust the setup.
• Review the diff of package.json and the lockfile on every change the agent makes.
• Treat what it reads from the web or issues as untrusted. See what prompt injection is.

What if you installed something suspicious?

• Remove it and check the lockfile diff.
• Rotate every secret that was available on that machine or in that CI job, because install scripts can read environment variables and files.
• Check recent outbound connections and new files in your home directory, shell profile and cron.
• Report the package to the registry.

Rotating credentials is the step people skip. It is the one that matters.