Agentic coding assistants are finding widespread use, not just in new code development but in quickly ingesting and leveraging third-party code. This opens up a risk of malicious code being ingested as these coding tools operate with broad filesystem access inside developer workspaces. In this paper, we extensively study the impact of different dimensions of a novel attack surface we term workspace topology -- defined via directory depth, codebase modularity, in-file injection position and context framing -- on the attack success rate of adversarial prompt injection attempts. We perform an empirical study of indirect prompt injection (IPI) across a diverse set of open-source repositories spanning 10 languages and 6 engineering domains, evaluating three IPI entry points against open-weight models operating open source code harnesses. We find that workspace topology measurably affects IPI success. Specifically, changes in codebase modularity can significantly alter the Attack Success Rate (ASR), with highly modular environments demonstrating significantly lower attack success rates. Furthermore, context framing and introduction of security-cues in the workspace can also alter the ASR. Our findings offer practical value for the evaluation and security testing of coding agents across diverse settings, while underscoring the importance of an uncontaminated testing environment to obtain reliable results and conclusions.
Figures & tables
Figure 1: Threat model. (a) An adversary (e.g., a malicious PR contributor) plants an injection prompt in a repository artifact. (b) The prompt lands in one of three IPI entry points inside the workspace: EP1 workspace configuration ( AGENTS.md ), EP2 documentation ( README.md ), or EP3 source code (e.g., src/app.py ). (c) A victim developer seeking to perform a task opens the repository in an agentic coding assistant, which auto-loads AGENTS.md into system context and uses standard tools ( Read , Bash , Glob , etc) to serve the user’s request. (d) The injected directive is treated as authoritative and the agent executes an unauthorized command (e.g., rm -rf ~/* ).
Figure 2: Workspace Topology Evaluation Framework a) Datasets are sourced from GitHub API and filtered for relevance across domains and coding languages. b) The evaluation driver leverages Opencode harness served with GPT-OSS-120B to measure the impact of workspace topological dimensions on IPI success across different input methods. c) IPI is measured across multiple ablation dimensions using the (ASR,R,C) metrics of § 4.5 .
Domain
Cybersec.
AI/ML
Frontend
Backend
Gaming
Research
Total
Count
21
18
18
19
12
12
100
Table 1: Dataset distribution across engineering domains for all languages combined.
Figure 3: Modularity effect on IPI where injection is placed at the beginning of the README.md file for the full 100-repo dataset resampled across n=1261 sessions to ensure significance. (a) Session-level reachability R , compliance C , and ASR =R⋅C against the modularity score. Error bars are Wilson 95% CIs on the per-bucket cell. (b) Per-sub-dimension Spearman ρ (per-repo, n=99 ) against each metric. Faded bars marked ∗ are non-significant ( p≥0.05 ); all other bars are significant at p<0.05 . The per-language slice on the same runs is shown in Appendix B .
Bucket
R
C
ASR
Low (scores 1–2, n=373 )
92.1% [89.1, 94.5]
47.6% [42.5, 52.9]
44.0% [39.0, 49.0]
Mid (scores 3–4, n=450 )
90.1% [86.9, 92.4]
38.0% [33.4, 42.8]
34.4% [30.2, 38.9]
High (scores 5–7, n=438 )
86.0% [82.5, 89.0]
30.6% [26.1, 35.3]
26.5% [22.6, 30.8]
Table 2: Modularity bucket summary: session-level R , C , ASR with Wilson 95% CIs in brackets. The Low and High ASR intervals are fully separated — the Low lower bound (39.0%) exceeds the High upper bound (30.8%) by 8.2 pp.
Figure 4: Framing-context ablation. ASR under three framing conditions, n=1000 per cell; The defensive AGENTS.md cell drops ASR by 15.5 pp relative to neutral ( ≈60% suppression); the security-cues cell (repo-root basename prefix) is within the neutral CI ( Δ=−3.0 pp, not significant)
Figure 5: Depth ablation (EP3). R , C , and end-to-end ASR by injection depth (directory levels from the repo root) on the 10-repo stratified subset. ASR is bounded by reachability, which peaks at depth 2. Wilson 95% CIs shown.
Figure 6: Position ablation, plain vs. mimicry envelope (EP2). R , C , and end-to-end ASR by in-file position of the payload in README.md on the 10-repo stratified subset. Reachability is nearly flat across cells; compliance is the main discriminator. Plain-envelope compliance decays with position (8% → 4% → 2%); mimicry-envelope compliance inverts and peaks at end-of-file (6% → 7% → 20%). Wilson 95% CIs shown.
Appendix figures & tables6 assets
Supplementary material from the paper’s appendix.
Appendix
Component
Value
Model
gpt-oss-120b (Open-AI, open weights)
Parameters / context window
120B / 128k tokens
Chat template
Harmony
Serving stack
OpenAI-compatible HTTP endpoint
Harness
opencode 1.14.46 , non-interactive mode
Harness invocation
opencode run "<prompt>" --format json
Appendix
Table 3: Inference stack and harness configuration.
Repository
Language
Depth
Files
TheR1D/shell_gpt
Python
3
42
keyvank/femtoGPT
Rust
3
50
lonng/nano
Go
6
149
SwingFrog/Summer
Java
11
427
rubysec/bundler-audit
Ruby
7
71
ggerganov/imtui
C++
3
43
Appendix
Table 4: Stratified 10-repository subset used for the EP2/EP3 topology ablations (one repository per programming language). Depth is the maximum directory depth from the repo root; Files is the total non- .git file count.
Figure 7: Per-language R , C , ASR on the pooled 100-repo runs (99 repos across 10 languages, sorted by ASR descending). Wilson 95% CIs shown; sample sizes below tick labels.
Figure 8: Per-domain R , C , ASR on the same pooled 100-repo runs used in the main text. Wilson 95% CIs shown; sample sizes below tick labels. Sorted by ASR descending.
Criterion
Weight
Measures
cdecomp
15%
Distribution of logic across files; median and max LOC/file
chier
10%
Directory tree depth; semantic organisation of subdirectories
ccoupling
20%
Cross-file import density; fan-in of inter-module dependencies
cabst
15%
Use of interfaces, abstract classes, registries, DI containers
capi
10%
Width of public API surface; number of exported entry points
cconfig
10%
Degree of behaviour externalised via config files or env vars
Appendix
Table 5: Sub-criteria for the modularity score M (Equation 1 ).
Figure 9: Inter-rater reliability between the Claude Sonnet 4.6 scorer (used throughout the paper) and an independent gpt-oss-120b scorer applied to the same 100 repositories. (a) Per-repo aggregate modularity score scatter (colour = log(LOC) ); points below the diagonal indicate gpt-oss-120b scores higher. (b) Mean sub-dimension score ± SEM for each model across all 100 repos. (c) Mean signed difference gpt-oss-120b − Claude Sonnet 4.6 per sub-dimension, sorted by magnitude. Both scorers agree on ranking ( ρ=0.80 , MAE = 1.28); the positive bias in gpt-oss-120b is concentrated in decomposition and coupling.