When a coding agent fills in a half-written file, it takes its cues from the names around the gap. A variable that calls a command trusted, or describes some output as already validated, tells the agent what the missing code is for and how careful it needs to be. A team at National Yang Ming Chiao Tung University tested whether an attacker could exploit that by changing nothing in a file except its names.
They took Python files from popular GitHub projects and cut out the lines where a security decision gets made. They kept only the files where agents, asked to fill the gap, never produced the targeted weakness across repeated tries. An attacker-side agent then renamed functions, variables and parameters to suggest the data was already safe. Commands were described as trusted, output as prevalidated, hashing as legacy-compatible, saved state as trusted. Comments, strings and logic were left exactly as they were. The finished bait holds no instruction and no vulnerable line. Six agents, including Claude Code, Codex, Aider and OpenHands, were then given an ordinary request to complete each file.
Files that had never produced the flaw went on to produce it in about a third of completions once renamed, more than twice the rate seen when the same files were renamed at random. The four target weaknesses were command injection, cross-site scripting, weak cryptography and unsafe loading of saved data. Results swung widely by agent, model and weakness. Bait built with one model often worked on another, sometimes better than on the model that made it.
"NameTrap shows that, once agents consume this content, an attacker no longer needs to ship malicious code; shipping misleading names suffices."
The two defensive tests came out worse than the attack rate. The researchers added one sentence to the prompt telling the agent not to write vulnerable code. It barely moved the average, and in half the agent and model pairings the attack succeeded more often with it. Then they ran seven security tools over the poisoned files, three AI reviewers and four conventional scanners. None of the seven flagged the targeted weakness in a single poisoned file.
"Because NameTrap modifies only identifiers and introduces no vulnerable statement, present-code vulnerability detectors have nothing to report, even though the file reliably induces vulnerable code once an agent completes it."
The authors explain the effect as agents doing what they are meant to do, following the conventions of the codebase. If the names say the input is trusted, skipping the escaping looks consistent. That fits the pattern in their results. The flaws that come from a single standard-library call, like an old hash function, were easiest to induce, and the one that requires actively leaving out escaping was hardest. But the study measured what agents wrote, not why, so the explanation is plausible but untested.
The setup is also kinder to the attacker than most real work. The security-relevant lines were removed on purpose, leaving a gap exactly where the bait's names do their work. A real attack needs a developer to pull in a third-party file and ask an agent to extend it at that spot. The study cannot say how often that happens, and no bait was published, so there is no evidence of the attack in the wild. Most experiments ran on small open-weight models. Frontier vendors appeared only through their smaller tiers, GPT-5.4-mini and Claude Haiku 4.5, so whether the largest models resist is still open. "A third of the time" is a lab figure, not a field rate.
The detection result applies more widely, because it does not depend on which model a team runs. A scanner pointed at incoming code cannot find a flaw that has not been written yet. On this evidence, the check has to sit on what the agent writes rather than what it reads. The paper's own method shows why that would work. An attack only counted as successful when standard scanners flagged the weakness in the agent's output, so those same tools, run on every agent-written change before merge, would have caught each case the study counted.
That turns into three decisions. Security reminders in a rules file or system prompt are not a control and should not be reported as one. Any vendor claim that "scanning your dependencies" covers agent risk deserves the question of whether it also scans the agent's diff. And a rename-only pull request from an outside contributor, the kind that passes every test and normally gets waved through, deserves a second look when it adds words like "trusted" or "validated" near command execution, cryptography or deserialisation. That is probably the cheapest place to stop this attack, since it is exactly the kind of change a reviewer is least inclined to treat as risky.
Sources
- Chang, C., Chen, G., Hsu, C. et al., "NameTrap: Steering AI Coding Agents Toward Security Vulnerabilities via Variable Names" — https://arxiv.org/abs/2610.34253