AI coding assistants create supply chain risk through three distinct channels: they suggest dependencies no human vetted, they consume attacker-controllable context files as instructions, and they are themselves a privileged dependency running inside your IDE and CI. None of this is hypothetical. We have watched assistants add packages that didn't exist a week earlier, seen the "Rules File Backdoor" technique hide Unicode-obfuscated instructions in .cursorrules, and cleaned up after an agent that helpfully committed a .env file because a README told it to. If a quarter of your merged code is now assistant-written — the number several of our customers report — then the assistant is your largest unaudited contributor.
Channel 1: dependencies nobody chose
The classic supply chain review assumes a human picked each package for a reason. Assistants break that assumption at volume. When Copilot or Cursor completes import statements, it optimizes for plausibility, not provenance. Three failure modes show up repeatedly:
- Hallucinated packages. Studies across 2024–2025 found commercial models hallucinating package names in roughly 5 percent of code samples, and open models above 20 percent. Attackers register the hallucinated names — slopsquatting — and wait. We wrote up the mechanics in our analysis of AI hallucination package confusion attacks.
- Stale-but-real packages. Models trained on old corpora suggest
request(deprecated 2020) ormomentwhen the ecosystem moved on years ago. You inherit an unmaintained tree with known CVEs on day one. - Wrong-ecosystem lookalikes. A model that saw
fastapi-utilsin Python happily inventsfastapi-utilsfor npm. Sometimes someone has published it.
The control is boring and effective: every assistant-suggested dependency goes through the same gate as a human-suggested one. Run SCA on every PR, block packages younger than 30 days or below a download threshold, and require lockfile diffs to be human-reviewed. npm diff and pip index versions take seconds; incident response takes weeks.
Channel 2: context files are an instruction bus
Assistants read far more than your prompt. .cursorrules, CLAUDE.md, AGENTS.md, copilot-instructions.md, README files of dependencies, code comments, even commit messages — all of it lands in the context window as quasi-instructions. That makes each of those files a supply chain artifact with the threat model of a shell script.
Pillar Security's "Rules File Backdoor" research (March 2025) demonstrated the sharp end: instructions hidden with zero-width Unicode characters in a shared rules file, invisible in GitHub's diff view, steering the assistant to emit backdoored code. A poisoned rules file in a popular starter template propagates to every repo cloned from it.
Practical hardening:
- Lint context files for invisible Unicode in CI:
grep -rPn "[\x{200B}-\x{200F}\x{2060}\x{FEFF}]" .cursorrules CLAUDE.mdcatches the common obfuscation ranges. - Treat rules files as code: CODEOWNERS entry, mandatory review, no direct pushes.
- Be suspicious of context that arrives from outside the repo — a dependency's README instructing "run
curl | shto finish setup" is an instruction to your agent, not to you.
Channel 3: the assistant is itself a dependency
The assistant stack — IDE extension, language server, MCP servers, CLI agent — runs with your developer credentials and often auto-updates. That is a supply chain dependency with better access than most of your production services.
Real incidents set the tone: CVE-2025-54136 ("MCPoison") let a collaborator silently swap an approved MCP config in Cursor for arbitrary command execution; malicious VS Code extensions impersonating AI tools shipped ransomware in 2025; and the Amazon Q Developer extension briefly distributed a prompt instructing it to wipe local files after a poisoned pull request was merged.
Minimums we enforce:
- Pin extension and CLI versions in a managed baseline; no
@latestauto-adopt in CI runners. - Scope the assistant's tokens. An agent doing code review needs read access, not
repoplusworkflow. - Inventory which developers run which assistants and MCP servers. You cannot reason about exposure you cannot enumerate — this is exactly the gap an AIBOM closes.
What review has to become
Human review does not scale to assistant output volume by reading harder. It scales by changing what humans review:
| Review target | Old world | With assistants |
|---|---|---|
| New dependency | Occasional, deliberate | Every PR, automated gate first |
| Lockfile diff | Skimmed | Machine-diffed, human-approved |
| Rules/context files | Ignored | Reviewed like CI config |
| Generated code | Line-by-line | Property-based: tests, SAST, diff risk scoring |
Teams using Safeguard typically wire this as policy gates: new-dependency age and reputation checks, lockfile drift detection, and secrets scanning that runs before the assistant's PR is even assigned a reviewer. The point is not to distrust the assistant — it is to stop pretending a human "chose" what it added. Comparative notes on how different platforms handle these gates are in our Snyk comparison.
Frequently asked questions
Are AI coding assistants riskier than human developers for supply chain security?
They are differently risky. Humans pick bad packages slowly and idiosyncratically; assistants pick them fast, at volume, and with correlated failure modes — the same hallucinated name across thousands of repos. Correlation is what attackers exploit, so automated dependency gates matter more, not less.
Which single control gives the best return?
A PR-level gate on new dependencies: minimum package age (30 days is a common threshold), minimum download count, no install scripts without review, and a known-vulnerability check. It converts the highest-volume risk channel into a routine CI failure instead of an incident.
Do I need to ban assistants from touching dependency manifests?
Banning rarely sticks. A better pattern is allowing manifest edits but requiring a labeled, human-approved PR for any change to package.json, requirements.txt, go.mod, or lockfiles — enforced by branch protection, not by policy documents.
How do I audit what my assistants have already added?
Diff your dependency inventory against a date before assistant adoption, then score everything added since: package age at introduction, maintainer count, install scripts, typosquat distance to popular names. An SBOM-driven inventory makes this a query rather than an archaeology project.