工作区拓扑：AI 编码助手间接提示注入的新攻击面

当天发生了什么

2026-08-14 20:30（UTC），arXiv 收到论文《Workspace Topology as an Attack Vector in Agentic Coding Assistants》的 v1，主分类 cs.CR，备注称已被 CAMLIS 2026 接收。作者指出，编码代理越来越多地被用于快速吸收和利用第三方代码，而它们在开发者工作区内拥有广泛的文件系统访问权限，因此存在恶意内容被摄入的风险。论文把「工作区拓扑」定义为一个新的攻击面，包含目录深度、代码库模块化程度、注入内容在文件中的位置和上下文措辞，并在覆盖 10 种语言、6 个工程领域的开源仓库上，用三种注入入口、开源权重模型和开源代理框架做了实证研究。结论是：工作区拓扑会可测量地影响间接提示注入的成功率，模块化程度高的环境攻击成功率显著更低；上下文措辞和工作区中的安全提示也会改变成功率。

对保护应用逻辑的人意味着什么

很多独立开发者已经让编码代理在自己的工作区里读第三方 SDK、示例代码，甚至帮忙修改构建脚本和混淆配置。这篇论文提醒：代理读到的每一段外部文本都可能是指令载体，而代理所在的工作区里往往就放着签名配置、发布脚本和保护规则。如果代理被诱导修改了 keep 规则、关闭了某项检查，或把敏感文件内容带出，受影响的正是你为保护应用逻辑所做的工作。论文也有清楚的边界：实验使用的是开源权重模型和开源代理框架，摘要没有给出具体的成功率数字，商业代理的表现可能不同；模块化降低风险是相关性结论，不等于可以依赖的防护。

可以落地的检查

第一，把签名密钥、商店凭据和发布配置放在代理会话无法访问的位置，例如独立的发布机或密钥管理服务。第二，引入第三方代码时，在隔离的目录或容器中让代理处理，再由人工审查后合入。第三，对混淆配置、keep 规则、签名和公证脚本设置强制评审，代理提交的改动同样适用。第四，定期检查代理运行时的文件和网络访问记录，确认它没有读取与当前任务无关的敏感文件。对保护设置出现的任何无法解释的改动，都按事件处理，并在下次发布前回滚。

行动清单

• 签名密钥与发布凭据放在代理无法访问处
• 在隔离目录或容器中处理第三方代码
• 对保护与签名相关配置的改动强制人工评审
• 定期审查代理的文件与网络访问记录