Can Variable Names Steer AI Coding Agents Toward Vulnerable Code?

A preprint observed 2026-10-27 reports that you can steer an AI coding agent toward writing vulnerable code without injecting a single instruction: rename the variables in a third-party Python file, and the agent takes the hint. The NameTrap preprint claims identifier renaming alone moved six production coding agents toward four CWE vulnerability classes, at self-reported overall attack success rates of 22.5% to 56.0%, with the bait file containing no instructions and no vulnerable statements. If you run Claude Code, Codex, Aider, OpenCode, OpenHands, or mini-swe-agent over repositories you do not fully control, the practical consequence is that patch review, not prompt configuration, is where this threat gets caught. Three additions to your review loop follow from the evidence: pre-commit security analysis on every agent-generated diff, scrutiny of edits that cluster near unusual or renamed identifiers, and a provenance record of which external files influenced each change.

The finding: renamed identifiers alone steered six agents into four CWE classes

NameTrap is a source-code poisoning attack that works purely through identifier semantics. According to the preprint, an attacker-side coding agent iteratively renames identifiers in a third-party Python file to align with a CWE-specific naming convention, probing a local model until the renamed file reliably elicits the target weakness in completions. The released bait then contains neither instructions nor vulnerable statements. If the victim’s agent reads that file as context and generalizes from its naming style, it writes the vulnerable pattern itself.

The evaluation, all self-reported by the authors, covered six agents (OpenCode, Claude Code, Codex, mini-swe-agent, Aider, and OpenHands), ten underlying language models, Python files drawn from 31 popular GitHub projects, and four weakness categories: OS command injection (CWE-78), cross-site scripting (CWE-79), broken or risky cryptography (CWE-327), and unsafe deserialization (CWE-502). Starting from files whose clean versions never produced the targeted weakness, the authors report overall success rates of 22.5% to 56.0% across the six agents, reaching 75.0% for certain agent-model configurations, and substantially better results than random renaming, neutral renaming, and the prior identifier-poisoning attack XOXO.

Two properties of that setup matter for how you read the numbers. First, the clean baselines never yielded the target CWE, so the measured successes are attributable to the renaming rather than to models being sloppy in general. Second, the attacker needed local probe access to iterate on naming conventions; this is a prepared attack against a known target context, not something that happens by accident in a tidy codebase.

Why the usual defenses look past it

Most prompt-injection defense thinking assumes a separation between instructions and data: the model is told to trust the prompt and distrust embedded strings that look like commands. NameTrap’s payload sidesteps that framing entirely. As the paper puts it, the payload “is a set of identifiers that remain valid program text and merely suggest an implementation convention, a channel that instruction–data separation does not directly target.” There is no injected string to filter, no imperative sentence to refuse. A filter looking for “ignore previous instructions” finds nothing, because the file is just code with opinionated variable names.

This is the core of the threat model worth internalizing: repository content is an input channel to the agent, and it can exert influence through program semantics rather than through anything that reads as an instruction. Agents trained and tuned to follow conventions in surrounding code are doing exactly what they were built to do when they imitate a naming style. The steering is a side effect of a feature.

The adjacent evidence is not reassuring. The PackHallu study, also self-reported, poisoned coding-agent rule files and found that state-of-the-art prompt-injection detectors “are ineffective at reliably identifying malicious rule files,” in the authors’ words. That is a different channel (explicit instructions in config files, not identifier semantics), but it undercuts the comforting assumption that screening repository content with current detectors will catch either attack.

The adjacent channel: poisoned rule files and auto-loaded configs

Identifier renaming is not the only way repository content instructs an agent. Rule and configuration files are loaded as instructions by design, and they are part of the repo an agent runs over. The PackHallu authors describe a self-reported case study in which Claude Code, with Sonnet 4.6 as backbone, was run on all 87 victim tasks from the numpy subset of BigCodeBench under a package-hallucination attack, with the malicious prompt injected at the beginning of CLAUDE.md, a file Claude Code automatically loads at session start. Anyone who can land content in that file has, in effect, written part of the prompt.

The intake surface is wide. A survey of agent configuration practices found, self-reported, that 72.8% of Cursor repositories adopt Rules files and 62.3% of Gemini repositories use Settings, while no other mechanism exceeded 20% adoption for Claude, Copilot, Cursor, or Gemini. Rule files are common, they are instructions, and they arrive with the code.

The three channels differ in mechanism and in what, if anything, currently catches them:

The row that should concern reviewers most is the last one. The identifier channel leaves no trace in the input that reads as an attack; the only reliable place to catch it is in the agent’s output, before merge.

Auditing your own exposure

If you want to know whether this threat model touches your setup, three questions cover most of it.

Which agents do you run, and over whose code? The six tested agents were OpenCode, Claude Code, Codex, mini-swe-agent, Aider, and OpenHands, per the preprint. Cursor was not in the NameTrap evaluation; it appears in the evidence only through the rule-adoption statistics above and through network-behavior measurements. Do not read the study as “Cursor was attacked.” But also do not read exclusion as safety: the mechanism (models generalizing from identifier conventions in context) is a property of the underlying LLMs, and ten models were tested. Untested agents are unmeasured, not cleared.

What does the agent read automatically? CLAUDE.md, Cursor Rules, AGENTS.md, and similar files are instruction channels you may not be reviewing with the same care as code. Given the self-reported detector results from PackHallu, intake screening with off-the-shelf prompt-injection detectors should not be your only line on these files.

How sensitive is your setup to harness and context choices? A harness-design study cites native-runtime benchmarking in which holding the model fixed and changing only the surrounding harness shifted a single model’s score on long-horizon tasks by up to 18 points, with Claude Code among the harnesses tested. The measured axis there is capability, not vulnerability, but the implication transfers: how much context the agent ingests, and which files it treats as authoritative, materially changes behavior. Agents that slurp large third-party files into context have a larger identifier-influence surface than agents working from tight, curated context.

The patch-review checklist

The NameTrap authors themselves recommend three controls, and they map cleanly onto a review workflow. Quoting the preprint, agent frameworks should “(i) treat identifiers in third-party code as untrusted input rather than as specifications, (ii) run security analysis on every agent-generated change before it is committed, since the targeted weaknesses become detectable once written, and (iii) record which external files influenced each generated edit so that reviewers can audit changes that depend on third-party code.” Two further items extend these as reasoned inference, and I will flag which is which.

1. Pre-commit security analysis on every agent-generated diff (authors’ recommendation). The four targeted weaknesses, command injection, XSS, weak crypto, unsafe deserialization, are all patterns static analyzers and security linters know how to flag once written. The attack moves the vulnerability from the repo (where it might be scanned) into freshly generated code (where it often is not). Closing that gap is the single highest-value change: agent-written diffs should pass through the same CWE-detecting gates as any contributed code, before merge.

2. Provenance logging of influencing files (authors’ recommendation). If the agent read vendor_lib/utils.py before editing auth.py, that belongs in the review record. There is supporting evidence that per-agent behavioral fingerprints are stable enough to audit: a study of documentation-portal traffic found consistent request counts per prompt across tools (one request per prompt for Aider, Claude Code, OpenCode, GitHub Copilot in VS Code agent mode, and others; two for Cursor; four for Cline). That work measured documentation fetches, not file reads, so it does not itself give you a file-level provenance log, but it shows agent activity has stable, recordable signatures that an audit trail can exploit.

3. Flag agent edits that cluster near unusual or renamed identifiers (reasoned extension, not a tested mitigation). The logic: NameTrap works by making the bait file’s naming convention salient, so a successful steer should leave a fingerprint in the diff, agent-written code that adopts the bait’s identifiers or idioms. Diffing which identifiers the agent consumed versus which it changed is a concrete version of this check. I would treat it as a heuristic to build review habit around, not a detector with a known catch rate. Nobody has measured its false-positive load, and unusual naming has plenty of innocent causes, including refactors, generated code, and contributors with different house styles.

4. Least-privilege agent permissions (supported by practitioner behavior). In a qualitative study of developer security practices, participants described restricting agent permissions as a response to unintended actions; one participant removed file write permissions after repeated experiences of the agent making changes he had not intended, framing it as preserving his own authority over the codebase. That study was about accidents, not adversaries, but the mechanism is the same: an agent that cannot write outside a reviewed working tree, or cannot commit without a human gate, limits what a successful steer can reach.

5. Structured, replayable review where the stakes justify it (implementation pattern). The ESAA-Security architecture organizes agent-assisted security auditing into four phases, 26 tasks, 16 security domains, and 95 executable checks, treating findings as structured evidence objects rather than unconstrained prose. That is heavier machinery than most teams need for routine agent diffs, but it demonstrates what “every agent-generated change gets security analysis” looks like when taken seriously: checks that are executable and replay-verifiable, not a reviewer eyeballing prose summaries.

One measurement note if you evaluate any of this yourself: report robustness, not just clean-input accuracy. The ReCode benchmark defined exactly this vocabulary back in 2022: Robust Pass@k, Robust Drops@k, and Robust Relatives@k, measuring how code generation degrades under perturbed inputs. Identifier renaming is an input perturbation, and any vendor claiming a mitigation against identifier-level attacks should be showing numbers in that frame, not a clean-benchmark score.

What the evidence does not establish

Everything quantitative here rests on one self-reported preprint. The 22.5% to 56.0% overall rates and the 75.0% peak, the comparison against XOXO and the renaming baselines: all come from the authors’ own benchmark in the NameTrap paper, over Python files from 31 GitHub projects, four CWEs, six agents, and ten LLMs. There is no documented real-world incident in the fetched evidence, no independent replication as of 2026-10-27, and no measurement of whether the attack survives contact with a defended pipeline. The evaluation is Python-only; whether identifier steering transfers to other languages at similar rates is unmeasured.

The checklist has the same status. Items 1, 2, and 4 are the paper’s recommendations or documented practitioner behavior; item 3 is my inference from the attack mechanism. None has a measured detection rate against NameTrap in deployment. If a vendor or tool claims to catch identifier-level poisoning, the right question is: show me Robust Drops@k-style numbers under renamed-identifier perturbation. The PackHallu result on detectors missing poisoned rule files is a caution against assuming existing tooling already covers this.

Treat repository identifiers and rule files as untrusted input to your coding agents. The durable shift here is not any one attack’s success rate, which may be revised as the preprint is reviewed; it is the recognition that the prompt is not the only instruction channel, and that program semantics themselves can steer. Run security analysis on every agent-generated change before commit, log which external files influenced each edit, and give extra scrutiny to diffs that pick up unusual naming from third-party code. I would start with the pre-commit gate: it is the one control on this list that catches the vulnerability regardless of which channel, renamed identifiers, poisoned rule files, or something not yet published, put it there.

Frequently Asked Questions

Which coding agents were tested in the NameTrap study?

The evaluation, all self-reported by the authors, covered six agents (OpenCode, Claude Code, Codex, mini-swe-agent, Aider, and OpenHands), ten underlying language models, Python files drawn from 31 popular GitHub projects, and four weakness categories: OS command injection (CWE-78), cross-site scripting (CWE-79), broken or risky cryptography (CWE-327), and unsafe deserialization (CWE-502).

What specific controls do the NameTrap authors recommend for agent frameworks?

Quoting the preprint, agent frameworks should “(i) treat identifiers in third-party code as untrusted input rather than as specifications, (ii) run security analysis on every agent-generated change before it is committed, since the targeted weaknesses become detectable once written, and (iii) record which external files influenced each generated edit so that reviewers can audit changes that depend on third-party code.”

What are the reported success rates for the NameTrap attack?

Starting from files whose clean versions never produced the targeted weakness, the authors report overall success rates of 22.5% to 56.0% across the six agents, reaching 75.0% for certain agent-model configurations, and substantially better results than random renaming, neutral renaming, and the prior identifier-poisoning attack XOXO.