Source: arXiv — 2026-07-16
Summary
Researchers present the first systematic study of "package-install-time" supply-chain attacks against AI coding agents, where an attacker edits only a README, requirements file, or Makefile to redirect the agent toward installing a malicious or vulnerable package during ordinary project setup. Testing 12 attack scenarios across 5 attack classes on production coding-agent harnesses, they find the same underlying model can catch an attack under one harness and fall for it under another — meaning safety here is a property of the harness-plus-model combination, not the model alone.
Key Takeaways
- The attack requires no code injection and no unusual permissions — just editing the plain-text setup documentation an agent naturally reads and trusts when getting a project running (README, requirements.txt, Makefile).
- Twelve scenarios span five distinct attack classes, giving a real taxonomy rather than a single proof-of-concept exploit.
- The headline finding is architectural, not model-specific: identical models pass or fail the exact same attack depending on which agent harness is wrapping them — the harness's tool-permission model and how it handles setup-time file reads matters as much as the model's own judgment.
- This directly complicates any "just use a safer model" mitigation strategy, since the paper shows the harness itself is a first-class part of the attack surface.
Reel Script
Hook (17s / 38 words) You don't need to hack a coding agent to compromise it — you just need to edit its README. A new study shows this works even against production agent harnesses, and the model isn't always what stops it.
Core Concept (65s / 140 words) When a coding agent sets up a new project, it reads the setup files — README, requirements.txt, Makefile — the same way a human developer would, and it trusts them the same way too, because that's literally what those files are for. This paper shows that's exactly the weakness: an attacker doesn't need to inject code or exploit a permission bug, they just need to edit those plain-text instructions so the agent installs something malicious as a normal part of "getting set up." Think of it like a fake sign at a building entrance telling visitors to go through a side door instead of the front desk — nothing about the sign looks broken, it just quietly redirects trust. The researchers built 12 different attack scenarios across 5 distinct attack classes to map how many ways this actually works in practice.
Hands-On (60s / 130 words) The most important artifact in the paper isn't a single exploit — it's the comparison table. They ran the same attacks against the same underlying models, but wrapped in different production agent harnesses, and found the pass/fail result flipped depending on the harness. A model that correctly refused a malicious setup instruction in one harness fell for the identical attack in another. That means the harness's own design — how it handles reading setup files, what permissions it grants during install steps, whether it treats documentation as untrusted input — is doing real safety work, independent of which model is underneath. If you're evaluating "is this coding agent safe," testing the model alone tells you less than you'd think; you have to test the model-in-that-specific-harness.
Takeaway (23s / 50 words) If your team lets a coding agent run project setup unattended, a malicious README is now a real, demonstrated attack path — not a theoretical one. Go check whether your harness treats setup-file instructions as trusted, and whether that trust is actually earned.