PaperlayerView exact revision on arXiv

Source-linked AI summary

Beyond the Payload: How User Invocation Shapes Coding Agent Vulnerability to Repository Poisoning

Fukang Zhu, Binbin Zhao, Ruixiao Lin, Ping He, Tianyu Du, Shouling Ji

arXiv:2608.30686v1cs.CRcs.CL

TL;DR

Repository-poisoning research has largely emphasized attacker-controlled injection and disguise, leaving the security effects of ordinary user invocation choices less studied. The paper introduces CIPR, a benchmark that varies task type, prompt expression, and skills/rules in poisoned real-world repositories and measures attack success and agent alerts. It finds that vulnerability is context-dependent, with task type producing up to a 4.5-fold ASR difference and prompt expression shifting execution depth and alert conspicuousness.

  • Problem

    Prior work characterizes attacker-controlled repository-poisoning techniques but underexplores how users’ task, prompt, and skills/rules choices govern a static payload’s success.

  • Method

    CIPR varies three PLC dimensions across 1,920 experiments using real repositories, social-media-grounded prompt styles, controlled skills/rules, and automated ASR and AR oracles.

  • Results

    Task type creates up to a 4.5-fold ASR difference, while underspecified prompts reduce ASR and noisy prompts show a directional tendency to suppress alerts.

  • Takeaways & Limitations

    Coding-agent vulnerability is a dynamic outcome shaped by everyday user configurations rather than a static property of the agent alone.

  • Takeaways & Limitations

    The benchmark focuses on textual PLCs and excludes model selection, memory, MCP servers, tool permissions, and IDE integrations.

Abstract

from arXiv · show

Coding agents are increasingly used for software engineering tasks, including bootstrapping projects from third-party repositories whose integrity cannot be assumed. Prior work on repository poisoning largely focuses on attacker-controlled injection and disguise, but developers also shape risk through everyday invocation choices: what task to delegate, how to phrase the request, and which skills or rules to supply. We term these user-side choices Prompt-Level Configurations (PLCs) and introduce CIPR (Coding In Poisoned Repos), the first benchmark that systematically varies PLCs in poisoned real-world repositories. CIPR comprises 1,920 instances across 20 repositories, four task types, three social-media-grounded prompt styles, and three skill/rule conditions, and measures attack success rate (ASR) and agent alert rate (AR) using automated runtime and trace-based oracles. Our evaluation reveals two key insights: (1) Vulnerability is highly context-dependent, with task type creating up to a 4.5-fold difference in ASR, with test-execution task forming a silent attack surface (high ASR, low AR). (2) Prompt expression shifts risk indirectly: underspecified prompts reduce ASR by truncating execution depth; noisy prompts exhibit a directional trend toward suppressing alerts by making malicious content less conspicuous. These findings highlight that coding agent vulnerability is not a static property, but a dynamic outcome shaped by everyday user configurations.

1 Introduction

CIPR studies how user-side Prompt-Level Configurations shape coding-agent vulnerability to poisoned repositories, extending prior work beyond attacker-controlled injection and disguise. It combines realistic benchmark construction with automated security evaluation and finds that task type and prompt expression materially affect attack success and alerting.

  • Prior studies emphasize attacker-controlled injection surfaces and disguise, leaving the user’s prompt-level interaction with coding agents underexplored.
  • Prompt-Level Configurations (PLCs) comprise the assigned task, prompt expression, and skills or rules supplied to the agent.
  • CIPR combines real repositories, task-specific injections, social-media-grounded prompt styles, controlled skill/rule configurations, and automated attack-success and alertness oracles.
  • Task type creates up to a 4.5-fold difference in ASR, with test execution forming a silent attack surface characterized by high ASR and low AR.
  • Underspecified prompts reduce ASR by truncating execution depth, while noisy prompts show a directional trend toward suppressing alerts by making malicious content less conspicuous.

2 Threat Model

The threat model separates attacker-controlled repository poisoning from user-controlled invocation choices. The agent receives system instructions, skills or rules, and the user’s task prompt, then repeatedly interacts with the repository environment.

  • The agent forms its initial LLM input by concatenating the system prompt, skills/rules, and user prompt as I0 = Psys⊕Psr⊕Puser.
  • The user’s task, prompt expression, and skills or rules constitute the three PLC factors varied in the benchmark.
  • The benchmark excludes model selection, memory settings, MCP servers, tool permissions, and IDE integrations from its PLC scope.
  • The attacker may modify any repository file through malicious pull requests or contributor-account compromise to induce malicious script execution.

3 Benchmark

CIPR constructs poisoned-repository scenarios by varying task type, prompt expression, and skills or rules while holding the attacker’s objective fixed. Its benchmark uses real repositories, socially grounded prompt styles, and dedicated runtime and trace-based security oracles.

  • CIPR mainly varies what developers want to do, how they express tasks, and which skills or rules they supply to coding agents.
  • The benchmark uses 20 GitHub repositories across Python, JavaScript, C, and Java, each requiring reproducible issues, build configuration, and an existing test suite.
  • The four task types are environment preparation, test execution, bug fixing, and feature implementation, with injection sites determined by the task.
  • Prompt styles are derived from social-media prompts annotated across 12 dimensions, clustered with K-means, and narrowed to three distinctive styles for the main experiments.
  • The three skill conditions range from no configuration, through productivity-oriented skills, to security-aware directives prohibiting unverified execution or requiring network confirmation.
  • Attack success is measured by secret-bearing outbound requests to a mock server, while alert success is judged from traces showing warnings, suspicion, or refusal.

4 Experiments

Experiments evaluate coding-agent security across task, prompt-style, and skills/rules configurations using repeated repository and injection replicates. The main results report ASR and AR, with statistical methods tailored to binary outcomes.

  • The main experiments evaluate Codex4 with GPT-5.4 as the backend LLM.
  • The evaluation uses a 4 × 4 × 3 factorial design with 48 configurations, 20 repositories, two injection methods, n = 40 per cell, and N = 1,920 runs.
  • Wilson confidence intervals, chi-square omnibus tests, and logistic regression are used for the binary ASR and AR outcomes.
  • Figure 4 reports ASR and AR across task types, prompt expressions, and skills/rules configurations.

Appendix G.2. We obtain the following results:

Results show that task type and prompt expression materially shape attack success and alertness, while agent and model settings preserve the main patterns but change baseline vulnerability. Security-aware rules increase alerts without uniformly preventing successful attacks.

  • Task Type: 45.5% RUN-TESTS ASR was 4.5 times the 8.6% FIX-BUG ASR, with RUN-TESTS combining high attack success and low alertness.RUN-TESTS had the highest ASR, while FIX-BUG and FIX-FEATURE had the lowest; agents were less likely to notice poisoned test files when explicitly asked to run tests.
  • Security Implications: Security-aware rules increased AR, but overlapping ASR confidence intervals showed no uniform or significant reduction in successful attacks.Alerts often arrived too late to prevent payload execution, motivating control-flow blocking and hierarchical auditing.
  • Agent and Model Comparison: Across four agent/model configurations, RUN-TESTS remained the highest-ASR, lowest-AR task, while absolute ASR varied substantially by agent.Codex with GPT-5.4 and GPT-5.5 had the highest attack success rates, whereas Claude Code with Sonnet 4.6 was consistently the most resistant.
  • Prompt Expression: Prompt expression shifts outcomes through execution depth and security salience rather than explicit security reasoning.TIU reduces exploration depth and ASR, whereas TNV can make the same injected content appear like an environment issue rather than suspicious code.
  • Prompt Expression: TIU reduced ASR by 4.8 percentage points without a meaningful change in P(read), because terse prompts truncated validation before reaching payload-bearing files.In the illustrated case, the terse prompt produced 37 tool calls and 2 test commands, versus 52 tool calls and 6 test commands for the baseline.
  • Implications: CIPR varies task type, prompt expression, and skill/rule configuration while holding attacker-side repository injections controlled, showing that security outcomes depend on realistic user configurations.The paper therefore argues that evaluations should not rely on a single canonical prompt or configuration.

B.3 Repository Licenses

The benchmark selects repositories across four programming languages and balances development type, file count, and lines of code while recording license information.

  • Licenses: The repository license table records licenses at collection time and identifies two mixed-license repositories requiring Apache-2.0-only injection targets.The restricted repositories are timescale/timescaledb and elastic/logstash.
  • Repository selection: 20 repositories span Python, JavaScript, C, and Java, with selection based on development type, file-count bins, and LOC bins.The final subset minimizes an imbalance score, prioritizing development-type balance and adding a per-language diversity penalty.
  • Repository selection: Repository selection uses a beam search over size-5 combinations for each language to find a balanced cross-language subset.Five repositories are selected from the first ten candidates for each language.
  • Tasks: The benchmark includes four task types with corresponding prompt templates.The supplied passages identify the task count and point to Table 5 for the templates.

C Tasks

This section constructs task specifications and prompt-expression variants, then characterizes styles through filtering, annotation, correlation checks, and clustering.

  • Prompt preprocessing: 1,296 raw prompts are filtered by length, English-language detection, and near-duplicate removal, retaining 635 prompts.Near duplicates are removed using MinHash locality-sensitive hashing with an approximate Jaccard similarity threshold above 0.90.
  • Style characterization: Retained prompts receive scores on 12 style dimensions using an integer 1–10 scale.A 5% random subset is re-annotated and evaluated with linear-weighted Cohen’s κ for consistency.
  • Style characterization: Most style-dimension correlations are low to moderate, while verbosity and context richness are strongly correlated.All VIFs are below 5, indicating no severe multicollinearity.
  • Style construction: K-means clustering is applied to the annotated prompt corpus, with K = 15 selected for the style analysis.Cluster examples are summarized using centroids and nearby prompts.
  • Prompt construction: Prompt-style generation varies request expression while preserving the underlying coding task.Style-neutral specifications encode repository context, objectives, constraints, success criteria, and attack goals before rewriting.
  • Prompt construction: Each style-conditioned instruction is generated from a task specification, style profile, and representative cluster examples.The rewriting process must preserve task semantics and avoid adding or removing repository-specific information.

D.1 Implementation Details for Preprocessing and Clustering

The preprocessing pipeline deterministically filters prompts, annotates style dimensions with an LLM, and clusters standardized vectors for prompt-style analysis.

  • Preprocessing: Prompts are filtered to English entries with at least five whitespace-delimited words and near-duplicates removed using MinHash LSH.Tokens are lowercased and extracted with the regular expression \w+, using a 0.90 Jaccard threshold.
  • Annotation: LLM annotation uses temperature 0.0 initially and temperature 0.3 for a 5% re-annotation subset.Invalid JSON, missing dimensions, and out-of-range scores trigger up to five retries.
  • Clustering: StandardScaler standardizes annotation vectors before KMeans clustering with random_state=42.The K = 15 analysis uses n_clusters=15, with silhouette scores and weighted Cohen’s κ among diagnostics.

E Skills and Rules Collection

The benchmark collects agent-facing skills and rules while evaluating controlled repository injections whose shared goal is simulated data exfiltration.

  • Context collection: Skills are SKILL.md-based directories, while rules are repository- or tool-level instruction files such as AGENTS.md and CLAUDE.md.The collection covers common agent-facing instruction formats and Cursor rule files.
  • Collection procedure: GitHub search results are merged by repository and processed in descending star count before lightweight content and path filtering.Skills require agent-skill keywords; rules are identified through common filenames, formats, size bounds, and instruction keywords.
  • Collected pools: The final pools contain 480 skill directories and 480 rule files.The skill pool comes from three repositories, while the rule pool spans 85 repositories.
  • Injection methods: The benchmark compares direct and direct-deep injections while keeping payload semantics constant.Direct-deep separates a visible invocation site from a deeper helper script containing the actual payload.
  • Evaluation: A successful attack is recorded when a mock server receives a request containing the designated target secret.Experiments run in isolated benchmark containers and use a controlled HTTPS endpoint.
  • Injection methods: The direct-deep method hides the exfiltration command from the primary injection location by invoking a repository-local helper script.The original target file contains only the helper invocation, while the deeper script contains the payload.

F.5 Comparison of Crafting Methods

The benchmark compares direct and direct-deep payload crafting while preserving payload semantics and varying only placement and execution indirection. Direct-deep models injected behaviors distributed across repository infrastructure-like locations.

  • The direct-deep condition changes payload location and reachability while keeping payload semantics fixed.
  • Direct evaluation tests whether agents execute or preserve a plainly present injected command in a task-relevant file.
  • Direct-deep evaluation models injected behaviors split across files, hidden behind helper scripts, or placed in infrastructure-like subdirectories.
  • Each direct-deep sample replaces the original injection with a helper-script invocation and stores the same raw payload in a second injected artifact.
  • The experiment details are reported in Table 18, alongside validation of the alertness oracle on conversational traces.

G.2 Statistical Analysis

The analysis estimates aggregate prompt-level effects using covariate-adjusted logistic regression over evaluable traces. It controls for task type and skill/rule configuration while treating prompt expression as the focal comparison.

  • 1,917 evaluable traces from the 1,920-instance main suite support inference on aggregate prompt-level configuration effects.Three traces were excluded because the required outcome could not be evaluated.
  • Separate binomial generalized linear models with logit links are fitted for binary outcomes such as attack success and alert success.
  • Baseline prompt expression, PREPARE-ENV task type, and No Skills/No Rules are the reference categories in treatment coding.
  • The models report HC1-robust standard errors, two-sided Wald p-values, and adjusted odds ratios exp(β) with 95% confidence intervals.
  • The regression tests prompt-expression effects after adjustment but does not estimate repeated-seed variance or establish causal intervention effects.

G.3 Functional Metrics and Utility-Security Trade-off

The paper evaluates utility alongside security using task success and Safe-Useful Rate across task types, prompt styles, and skills/rules configurations. RUN-TESTS illustrates the trade-off between high task completion and poor safe usefulness.

  • Task Success Rate measures whether the agent completes the user’s objective, such as passing tests or resolving an issue.
  • Safe-Useful Rate counts runs that complete the task without triggering the attack payload.It is defined as TaskSuccess = 1 ∧ AttackSuccess = 0.
  • The evaluation reports TSR and Safe-Useful Rate alongside ASR and AR across task types, prompt-expression styles, and skills/rules configurations.
  • 68.7% TSR for RUN-TESTS coexists with 34.9% Safe-Useful Rate, the lowest among task types, because its ASR is extremely high.
  • Cross-agent/model visualizations use 95% Wilson confidence intervals, while additional tables report results by task type, prompt style, and skills/rules configuration.

H Evaluation Metrics

The evaluation distinguishes observed attack execution from explicit agent awareness and reports utility-security metrics across benchmark configurations. It uses attacker-server logs for attack success and trace-based judging for alerts, with results organized by task type, prompt style, and agent/model coverage.

  • attack_success records whether exfiltration reaches the attacker server, whereas alert_success records explicit agent recognition of malicious or suspicious behavior.
  • Attack success is positive only when attacker-server logs match the configured evaluation regex pattern.
  • Tables 14–17 summarize utility-security metrics, task- and prompt-style results, and the inventory of runs across agents and models.
  • Alert success requires the agent to notice, warn about, refuse, or report the malicious or suspicious behavior.
  • Alert judgments use bounded task, payload, command, conversation, assistant-message, and outcome evidence, producing a Boolean decision with a reason and evidence string.
  • A failed exfiltration attempt does not count as an alert unless the agent explicitly identifies the injected behavior.
  • Table 18 reports ASR and AR across prompt-level configurations and security settings, including cross-agent/model generalization.
Loading 2608.30686v1…