项目指令文件如何成为编程代理攻击入口

让 AI 编程助手遵守项目规范的 AGENTS.md，也可能把它引向攻击者指定的操作。Securetron 的 Sarah Reid 转述了一项研究：攻击者把恶意指令包装成项目约定，利用 Agent 对上下文的信任，诱导它调用工具、执行命令，甚至改变 API 请求的去向。

研究报告称，针对 Codex 的测试成功率超过 90%，但真实攻击中的投递路径尚未确认。对程序员更有用的结论是：项目文件可以提供工作信息，却不该自行决定 Agent 能动用哪些权限。

为什么一份项目说明能指挥 Agent 越界

AGENTS.md 通常记录构建、测试、目录结构和安全命令。Agent 打开仓库后读取它，便能少问几次问题，直接按项目习惯工作。

攻击也沿着这条路径发生：文件里混入一个看似正常的初始化步骤、工具选择或工作流程，Agent 把它当成项目要求，随后执行对应动作。恶意内容未必表现为明显的威胁，更可能藏在「完成任务之前需要做的准备」里。

这里发生的是提示注入（prompt injection）：原本供系统参考的文本，越过了信任边界，开始支配系统行为。文件能否造成实际损失，还取决于 Agent 手里有什么。如果会话能够读取凭据、访问源码并连接外网，后果就可能超出一次错误的代码修改。

原文用 function coloring 和 MALFEX 描述相关技术，强调恶意指令可以混入正常工作流程，把 Agent 引向攻击者选择的函数和动作。不过，文章没有给出足以独立核验的技术细节，不能据此推断具体载荷和完整攻击过程。

真正需要审查的，是文件里的要求最终会触发什么动作。

因此，「把上下文文件当代码审查」不是要求所有说明文档采用相同流程，而是承认：能影响工具执行的文字，已经具备了操作入口的作用。

改一个 ANTHROPIC_BASE_URL，为什么会牵涉令牌

原文提出的另一条风险链，发生在 API 请求的目的地。

Claude Code 使用 ANTHROPIC_BASE_URL 确定 API 端点。如果攻击者通过指令、配置变更或环境变更，让 Agent 接受了一个受控地址，请求及其携带的认证凭据或令牌就可能被发往那里。令牌被截获后，还可能遭到重放，也就是被再次拿去发起认证请求。

这条链路有一个关键前提：端点变更必须实际生效。文章没有完整交代不同认证方式下的请求行为和重放条件，因此不能把它理解为「改这个变量就一定能盗用所有凭据」。

但防守边界很清楚：API 发往哪里，不能由刚克隆的仓库自行决定。

原文建议，从可信配置核验 ANTHROPIC_BASE_URL，以及其他工具的同类端点设置。Agent 提出的 API 地址、代理配置和凭据处理方式变更，应经过人工审查；凭据应短期有效、权限尽量小，并支持快速撤销。同时，需要监测异常端点和异常令牌使用，避免等到发现重定向之后才处理。

对日常 AI 编程来说，一条「先改代理或 API 地址才能继续」的项目说明，应该触发单独核验。它修改的是通信目的地，不能仅凭「项目要求」获得信任。

超过 90% 的成功率，能证明到哪一步

Sarah Reid 转述的 Forever Security 研究报告称，针对 Codex 的测试成功率超过 90%。原文同时明确：这只是研究者测试环境中的结果，不能当作现实仓库的失陷比例。

文章没有给出样本量、完整测试任务、权限设置或成功判定标准。缺少这些信息，就无法判断这个数字能否迁移到其他模型、其他权限配置，或普通团队的工作环境。

另一个边界更重要：恶意 AGENTS.md 如何稳定抵达受害者的 Agent，尚未得到确认。共享仓库、fork 和复制项目模板是文中提到的可能路径，并不等于已经确认存在真实攻击活动。

这里要分开看两件事。研究展示了受信任文件能够引导 Agent 执行攻击者意图；现实中攻击者如何把文件送进去、以多大规模得手，文章没有证明。

前者足以支持增加防护，后者限制了我们能作出的风险判断。不能把实验结果写成正在大规模发生的劫持事件，也不能因为投递路径未确认，就忽略已经展示出来的权限问题。

我的判断

我认同文章把重点放在「谁有权决定动作」上。只在 AGENTS.md 里追加一句「不要执行恶意指令」，并不能建立可靠边界：它仍然要求 Agent 从同一份可能被修改的文本里判断哪些要求可信。

更可执行的办法，是把约束放在文件之外。用 CODEOWNERS 或同类规则审核指令文件的变更；用文件系统权限和网络出口限制约束执行；把凭据注入放到受控步骤。这些措施能限制一条错误指令最终造成的影响。

不过，原文要求 shell 执行、网络请求、包安装、凭据访问和工作区外变更都经过明确批准。普通开发会话里，逐条确认可能带来大量打断。我的取舍是，先用独立策略划定允许范围，再让越界操作触发人工复核。这个效率上的判断没有得到原文对照数据支持，不能声称它已经证明更优。

文章还包含厂商利益关系。Sarah Reid 来自 Securetron，文中介绍了其 Securetron AI-FW。Community Edition 每月可免费使用最多 100 亿 tokens，但它是专有软件，并非开源。

原文没有提供 AI-FW 与其他控制方案的对照测试，不能据此认定它的实际拦截效果。评价此类工具，应看它能否观察工具调用和 API 流量、阻止或要求批准高风险动作、记录行为，并独立执行端点与凭据策略。如果控制规则仍依赖仓库里的同一份指令，信任问题就没有解决。

能拿来做什么

• 在前端或 Node 仓库中，把 AGENTS.md 和其他 Agent 指令文件纳入 PR 审查，并用 CODEOWNERS 指定审核人。检查具体 diff，尤其关注新增命令、配置修改和外部通信要求。

• 接手陌生仓库时，先查看指令文件、配置和 setup 脚本，再启动 Agent。优先在不挂载密钥的临时环境中运行构建和测试；本次任务不需要的指令文件，可以隔离后再使用。

• 将 API 端点、模型设置、插件和 MCP server 配置放进独立审核的可信配置。遇到修改 ANTHROPIC_BASE_URL、代理或凭据处理方式的要求，先核验来源和目的地。

• 分开处理不可信代码与秘密信息。让构建、测试阶段尽量接触不到生产凭据，确有需要时再通过受控步骤注入短期凭据，并保留工具调用、命令和端点变更日志，方便追查影响范围。