Workspace topology as an attack surface for indirect prompt injection in coding agents

What happened on this date

At 20:30 UTC on 2026-08-14, arXiv received v1 of "Workspace Topology as an Attack Vector in Agentic Coding Assistants" (primary category cs.CR), with a comment that it was accepted at CAMLIS 2026. The authors note that coding agents are increasingly used to ingest and build on third-party code while holding broad filesystem access inside developer workspaces, which creates a risk of ingesting malicious content. They define workspace topology as a new attack surface, covering directory depth, codebase modularity, the position of injected content within a file and context framing, and study it empirically across open-source repositories in 10 languages and 6 engineering domains, using three injection entry points, open-weight models and open-source agent harnesses. They find that topology measurably affects indirect prompt injection success: highly modular environments showed significantly lower attack success rates, and context framing and security cues in the workspace also changed the rates.

Why it matters for people protecting app logic

Many independent developers already let coding agents read third-party SDKs and sample code in their workspace, and even edit build scripts and obfuscation settings. The paper is a reminder that any external text an agent reads can carry instructions, and the workspace the agent sits in often holds signing configuration, release scripts and protection rules. If an agent is steered into changing keep rules, disabling a check or carrying sensitive file contents elsewhere, the damage lands precisely on the work you did to protect your app's logic. The paper's boundaries are clear too: experiments used open-weight models and open-source harnesses, the abstract gives no specific success-rate figures, commercial agents may behave differently, and the finding that modularity lowers risk is a correlation, not a defense to rely on.

Concrete checks

First, keep signing keys, store credentials and release configuration somewhere agent sessions cannot reach, such as a separate release machine or a key management service. Second, when bringing in third-party code, let the agent work on it in an isolated directory or container, and merge only after human review. Third, require review for obfuscation configuration, keep rules and signing and notarization scripts, including changes proposed by agents. Fourth, periodically review the agent's file and network access records to confirm it did not read sensitive files unrelated to the task. Treat any unexplained edit to protection settings as an incident and roll it back before the next release.

Your checklist

• Keep signing keys and release credentials out of agent reach
• Handle third-party code in an isolated directory or container
• Require human review for protection and signing config changes
• Review agent file and network access logs periodically