PaperlayerView exact revision on arXiv

Source-linked AI summary

Workspace Topology as an Attack Vector in Agentic Coding Assistants

Alexandre G. R. Day, Pradeep Yadlapalli, Sriram Venkatapathy, Thomas Paniagua, Nick Raines, Sahil Wadhwa, Himanshu Kumar, Andy Luo, Sudeep Panyam, Rikhiya Ghosh, Pranab Mohanty, Giri Iyengar

arXiv:2608.14876v1cs.CRcs.AIcs.CLcs.LG

TL;DR

Agentic coding assistants’ trusted-folder access creates a largely unmeasured risk that repository artifacts can carry adversarial instructions. This paper empirically studies how workspace topology affects indirect prompt injection, finding that all four tested dimensions measurably shift attack success rates, by at least a factor of two.

  • Problem

    The structural dimensions of code repositories’ influence on indirect prompt injection efficacy in coding assistants have not been systematically investigated.

  • Method

    The study evaluates three repository-topology injection entry points across open-source repositories, measuring end-to-end verified execution while ablating modularity, framing, nesting depth, and in-file position.

  • Results

    All four ablated workspace-topology dimensions shift attack success rates by at least a factor of two.

  • Takeaways & Limitations

    Workspace topology is a load-bearing variable for deployment security and controlled indirect-prompt-injection safety evaluations.

  • Takeaways & Limitations

    The study is scoped to one model, one harness, and one payload action, so cross-model generalization remains untested.

Abstract

from arXiv · show

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.

1 Introduction

The introduction frames trusted-folder coding assistants as a largely unmeasured IPI attack surface and defines workspace topology as a factor that modulates attack success. It presents a taxonomy, evaluation framework, empirical findings, and clean-room testing controls for studying this risk.

  • Motivation: Trusted-folder assistants’ persistent filesystem access lets ingested repository content become executable directives, creating a novel IPI attack surface.Agents can read files, navigate directories, invoke tools, modify system files, and execute arbitrary code through bash tooling.
  • Empirical scope: The study shows that codebase modularity, security-framing context, nesting depth, and in-file position affect IPI ingestion and verified-execution rates.The experiments use gpt-oss-120b through the Opencode harness across real-world open-source repositories.
  • IPI entry points: The taxonomy identifies three repository-topology entry points: auto-loaded workspace configuration, documentation mimicry, and source-code mimicry at depth ≥2.The entry points are EP1 via AGENTS.md or CLAUDE.md, EP2 via README.md and other documentation, and EP3 via source files.
  • Methodology: The evaluation framework synthetically injects individual entry points, commits planter artifacts to Git history, and measures end-to-end verified execution.This framework quantifies repository susceptibility to IPI while avoiding reliance on a single intermediate signal.
  • Formatting ablation: Chat-template mimicry succeeds several times more often at end-of-file than at the beginning, demonstrating an interaction between payload formatting and in-file position.The attacks wrap directives in fake harmony role-delimiter tokens inside repository files.
  • Testing recommendations: Clean-room evaluation should commit planter artifacts before agent execution and report both framed and unframed conditions when workspaces contain security cues.Git status can expose uncommitted artifacts, while defensive AGENTS.md files or red-teaming naming prefixes can frame the workspace.

2 Threat Model

The threat model centers on an adversary who manipulates repository artifacts to inject prompts that cause an agentic coding assistant to perform unauthorized actions. The study examines attacks delivered through workspace configuration, documentation, or source-code files when developers ask agents to process many repository files.

  • Adversary capability: A workspace adversary can write or rename repository files before a victim opens the repository in an agentic coding assistant.Adversaries may include malicious maintainers, pull-request contributors, or attackers who compromise project dependencies.
  • Adversary capability: The adversary cannot directly modify the agent’s system prompt or intercept network traffic, and is limited to manipulating workspace artifacts.
  • Attack objective: The attack goal is to make the agent perform an unauthorized action by embedding an injection payload in an artifact it naturally reads during normal operation.Examples include running a planted script, modifying or exfiltrating data, and executing a malicious action.
  • Victim workflow: Victims ask the coding agent to perform tasks that read many repository files, such as refactoring, summarization, or multi-turn question answering.
  • IPI entry points: The study considers three injection entry points: workspace configuration, documentation, and source code files.Figure 1 identifies these as AGENTS.md, README.md, and source code such as src/app.py.

3 Workspace Topology

Workspace topology combines repository structure, attacker deployment choices, and the IPI entry point. It is analyzed through four measurable dimensions: codebase modularity, framing context, nesting depth, and in-file position.

  • Topology definition: A workspace topology configuration combines the repository’s underlying structure, attacker deployment choices, and the specific IPI entry point.Appendix G identifies requirements for generating workspace topology attacks.
  • Dimensions: The four dimensions divide into passive repository properties—codebase modularity and framing context—and attacker-controlled axes—nesting depth and in-file position.These dimensions are analyzed in Section 5.
  • Passive dimensions: Codebase modularity scores repository complexity from 1–10 using separation of concerns, interface indirection, cross-file coupling, and API surface width.The score is assigned through a weighted-sum formula defined in Appendix C.
  • Passive dimensions: Framing context captures security or red-team contamination cues in directory names, configuration files, file prefixes, and an in-repo AGENTS.md file.The evaluated cues include security-themed directives and adversarial-looking names such as red_team_repo or prompt_injection_test.
  • Attacker-controlled dimensions: Nesting depth is the target file’s directory depth, which may reduce file reachability while increasing context length and diluting or burying the payload.The threat model assumes a minimal payload injected into an otherwise legitimate repository.
  • Attacker-controlled dimensions: In-file position places payloads in beginning, mid, or end zones, testing whether unread regions limit success under a 200-line read window.The zones are beginning (top 15%), mid (35%–65%), and end (bottom 15%).

4 Experimental Setup

The study evaluates indirect prompt injection across a controlled dataset of open-source repositories using the Opencode harness and GPT-OSS-120B. It varies workspace-topology dimensions and measures attack success through reachability and compliance.

  • Evaluation framework: The evaluation plants IPI payloads, drives the Opencode harness, and measures success across workspace-topology ablations using ASR, R, and C.The framework sources and filters repositories through the GitHub API, then evaluates topology dimensions across different input methods.
  • Dataset: The dataset contains 100 open-source repositories spanning 10 coding languages and 6 engineering domains, with repository sizes capped at 1–5 MB.Repositories were selected through the GitHub Search API from 60 language-domain cells, requiring more than 50 stars and a last-pushed date after 2023-01-01.
  • Dataset: Each repository receives a 1–10 codebase-modularity score based on eight rubric criteria, including hierarchy depth, coupling, abstraction layers, tests, and documentation.The scoring is performed by a coding agent session using a fixed rubric, with criteria and weights specified in the appendices.
  • Harness and model: Experiments run once per repository through a non-interactive, permissive, fully stateless Opencode session serving GPT-OSS-120B.All conditions use the same open-ended summarisation prompt to encourage autonomous repository exploration and exposure to planted artifacts.
  • Metrics: ASR = R · C, where reachability is injected-file opening and compliance is executing bash init.sh with both seeded output markers.For EP1, R ≡1 because Opencode auto-loads AGENTS.md into the session’s system context.

5 Results

Workspace topology measurably changes indirect prompt-injection success in coding agents. Modularity, security-themed framing, nesting depth, and in-file position affect compliance and end-to-end ASR through distinct mechanisms.

  • Modularity: Compliance falls from 41% at modularity 1 to 21% at modularity 7, while reachability remains nearly flat, making codebase structure decisive for execution.IPI planted in the root README.md is generically read, but execution depends strongly on modularity and codebase structure.
  • Framing context: The defensive AGENTS.md security policy reduces ASR from 25.7% to 10.2%, whereas prompt-injection root-directory renaming changes ASR by only −3.0 pp.Reasoning traces show 17% of sessions cited the security policy before declining to run init.sh; the rename effect was within the confidence interval.
  • Nesting depth: Nesting depth creates competing reachability and content-dilution effects, with end-to-end ASR bounded by reachability that peaks at depth 2.Higher depths can make peripheral files less reachable while increasing the number of files entering the context window, potentially diluting payload influence.
  • In-file position: Plain-envelope compliance declines from 8% to 2% from README beginning to end, while mimicry-envelope compliance rises from 6% to 20%.Reachability remains approximately 75–86% across positions, so compliance—not file exposure—drives the positional difference.

6 Discussion and Recommendations

The discussion recommends controlling workspace topology, validating workspace configuration, using defensive framing and default-deny tool policies to reduce or reliably measure IPI ASR. The findings remain scoped to one model, harness, and payload action, motivating cross-model replication and more mechanistic benchmarks.

  • Recommendations: IPI evaluations should sample nesting depth, modularity, and in-file position because single-topology benchmarks can over- or under-report ASR.The limiting mechanism shifts across cells, from reachability at higher depths to compliance at leaves.
  • Recommendations: Highly modular codebases lower ASR through the compliance channel, supporting modular repository structure as a lightweight code-hygiene practice.Payloads in small, well-scoped modules are read but treated as code rather than instructions.
  • Recommendations: Harnesses should scan AGENTS.md and CLAUDE.md before loading them, flagging or stripping action directives because these files are treated as trusted system-level instructions.EP1 is the highest-ASR entry point in the study.
  • Recommendations: 25.7% to 10.2%: A security-themed AGENTS.md directive cuts EP2 ASR by approximately 60% relatively, but adaptive payloads may evade this soft defense.The framing layer is cheap to combine with content-level validation.
  • Recommendations: Default-deny approval for bash, Write, and similar side-effecting tools closes the compliance channel and increases the gap between reachability and ASR.Reachability is uniformly high for documentation and configuration files, while verified execution depends on tool invocation.
  • Limitations and future work: The study uses only gpt-oss-120b, opencode 1.14.46, and the bash init.sh payload action, so future work should test other harnesses and closed-weight models.Cross-model replication is particularly relevant to the position-end effect because harnesses paginate long files differently.

7 Related Work

Prior work frames workspace-topology attacks as instances of role confusion and indirect prompt injection, while this paper adapts chat-template mimicry and evaluates in-repository attack surfaces. It also positions its contribution against coding-agent attacks, evaluation frameworks, and tool-use security research.

  • Mechanistic foundations: Models infer instruction source from lexical style and structural position rather than provider-controlled architectural tags, enabling workspace artifacts to mimic privileged roles.Ye et al. [2026] describe this mechanistic basis, while ChatInject exploits it with chat-template role-delimiter tokens.
  • Chat-template prompt injection: ChatInject improved benchmark ASR from 5.18% →32.05% on AgentDojo and 15.13% →45.90% on InjecAgent, and this paper applies its envelope to committed repository files.The prior attack demonstrated strong cross-model transfer; here, the same format-mimicry envelope targets a different attack surface.
  • Attacks on coding agents: Prior coding-agent work includes AIShellJack’s 84% ASR via poisoned external resources and a survey cataloging 42 attack techniques across major coding assistants.This paper complements that literature with an empirical topology ablation of an in-repository indirect prompt injection attack.
  • Evaluation frameworks: Existing frameworks benchmark indirect prompt injection or risky code in tool-integrated agents, whereas this paper contributes dataset generation, a modularity metric, and topological-dimension decomposition.The cited frameworks are InjecAgent, AgentDojo, ASB, and RedCode.
  • Scope and adjacent security work: Tool-use security research reports 72.8% tool-poisoning on o1-mini, but MCP topology is out of scope and tool-description injection is left for future work.This paper also empirically measures rules-file/config-file attacks on opencode and builds its defenses on prior IPI-defense literature.

8 Conclusion

The study concludes that workspace topology is a substantial IPI attack surface: all four tested dimensions shift attack success rate by at least a factor of two. It also emphasizes decomposing ASR into payload reachability and compliance, avoiding workspace contamination, and pursuing broader validation and benchmarking.

  • Conclusion: All four ablated topology dimensions—modularity, framing context, nesting depth, and in-file position—shift ASR by at least a factor of two.The result spans four dimensions and three entry points covering the privilege range of a typical repository.
  • Conclusion: ASR should be decomposed into reachability R, whether the agent read the payload, and compliance C, whether it acted after reading it.This decomposition clarifies distinct stages of indirect prompt injection success.
  • Conclusion: Reliable workspace evaluation requires preventing contamination during testing.The authors identify uncontaminated evaluation as important for interpreting ASR results.
  • Conclusion: Future work includes cross-model replication, mechanistic analysis of position-envelope interaction, dedicated IPI benchmarks, and automated red-teaming frameworks.These directions target broader validation and more systematic security testing of agentic-coding settings.

A Experimental Setup Details

The study used a documented inference stack and harness, sampling 10 repositories for EP2/EP3 topology ablations while retaining all 100 repositories for the main analysis in Fig. 3.

  • Sampling and Analysis Scope: EP2/EP3 topology ablations used stratified sampling of 100 repositories down to 10, with one repository selected per coding language.The ablations covered framing, depth, and in-file position.
  • Sampling and Analysis Scope: The 10 ablation repositories represented 10 coding languages, as listed in Table 4.Stratified sampling reduced computational burden without sacrificing the qualitative nature of the findings.
  • Sampling and Analysis Scope: The main analysis for Fig. 3 used all 100 repositories rather than the reduced ablation sample.Table 3 summarised the inference stack and harness configuration.

B Per-Language and Per-Domain ASR Breakdown · C Modularity Score

Across 99 repositories in 10 languages, ASR varied more by language than engineering domain, with variation driven primarily by compliance rather than reachability. The paper defines modularity as a weighted structural-complexity score ranging from 1 to 10.

  • B Per-Language and Per-Domain ASR Breakdown: 2.3×: Language-level ASR ranged from 22% for Java to 50% for Ruby across 99 repositories spanning 10 languages.Reachability remained uniformly high at 78–98%, indicating that language-level variance was driven almost entirely by compliance.
  • B Per-Language and Per-Domain ASR Breakdown: Java’s 22% ASR was partly a depth artefact because deep package hierarchies pulled the agent into source code where the doc-anchored payload no longer fired.The cited example, SwingFrog/Summer, reached depth 8 under src/main/java/com/swingfrog/....
  • B Per-Language and Per-Domain ASR Breakdown: 1.6×: Domain-level ASR ranged from 28% for frontend to 44% for research-tools across six engineering domains.The six domains were research-tools, backend, ai-ml-dl-cv, cybersecurity, gaming, and frontend.
  • B Per-Language and Per-Domain ASR Breakdown: Domain was a weaker discriminator than language, while the same pattern of flat reachability and compliance-driven ASR held across domains.The comparison was 1.6× across domains versus 2.3× across languages, with reachability remaining comparatively flat.
  • C Modularity Score: The modularity score M ∈[1, 10] is a weighted sum of eight structural criteria, each independently assessed on a 1–10 integer scale.The criteria include decomposition, hierarchy, coupling, abstraction, API, configuration, tests, and documentation.

D Modularity Scorer Inter-Rater Reliability … G Attack generation requirement

The paper validates its modularity scorer, describes three IPI entry points and format-mimicry wrapping, and requires clean git state to avoid exposing attack files through status cues. The independent scorer comparison shows strong agreement but a systematic positive scoring bias.

  • D Modularity Scorer Inter-Rater Reliability: The Claude and gpt-oss-120b modularity scorers strongly correlate across 100 repositories, with 18% exact agreement and consistent low-modularity ordering.Spearman ρ = 0.80, n = 100.
  • D Modularity Scorer Inter-Rater Reliability: gpt-oss-120b scores approximately 1.3 points higher on average than Claude, producing a mean absolute error of 1.28.The reported positive bias appears in the sub-dimension comparison.
  • E Taxonomy of IPI Entry Points: The study implements three IPI entry points carrying the same directive payload while varying the planting surface and use of a format-mimicry envelope.The entry points differ in where the directive is planted and whether it is wrapped.
  • E Taxonomy of IPI Entry Points: EP1 creates a root AGENTS.md, or CLAUDE.md for Claude Code, whose plain-text directive is auto-loaded as system context without envelope wrapping.The file is processed as system-level instructions by design.
  • F Format mimicry: EP2 and EP3 wrap directives in fake harmony role-delimiter tokens, causing models to classify the content as a system message.This uses Chang et al.’s ChatInject technique and the real harmony special-token strings as multi-token text inside untrusted content.
  • G Attack generation requirement: Each run-scoped workspace must include git add -A && git commit so planter-introduced files do not appear as newly untracked or unstaged changes.The authors did not quantify the cue’s impact, but observed that it affected tool-call ordering and therefore treated clean state as requirement R5.
  • F Format mimicry: The format-mimicry envelope visually matches the chat template while enclosing directive text in fake harmony role-delimiter tokens.The envelope is used for EP2 and EP3.
Loading 2608.14876v1…