简介：本文讲解AI编程Agent指令文件投毒的基本原理、常见风险场景和防御要点。读完后，开发者能判断哪些目录不适合启动Agent，理解非交互模式下的风险，并掌握目录隔离、权限收紧、沙箱运行和出站流量监控四层防护方法，以及疑似中招后的处置顺序。
本文仅用于防御性安全研究和开发者自查，不提供可复现的攻击步骤。请勿在生产环境或未获授权的系统上尝试复现相关场景。
AI编程Agent在工作目录中通常会读取项目指令文件，例如 AGENTS.md 或功能相近的 Markdown 文件。这类文件记录项目背景、编码规范和工具使用习惯。Agent启动时会把它们放进上下文，再和用户的请求一起交给底层大模型处理。
项目指令文件并不是模型的系统提示词。它属于上下文输入，信任级别低于开发者在对话中直接下达的指令，也低于工具自身的安全策略。指令文件投毒指的是，不可信的内容进入了Agent会读取的位置，并借助自然语言诱导Agent执行原本不打算执行的操作。
这类风险的根源在于设计行为。Agent按照项目指令办事，是它的核心能力之一。问题在于输入来源是否可信。因此，单靠升级某个软件版本无法彻底解决问题，需要从使用方式和权限边界上入手。
这类风险有三个特点，使它容易被忽略。
第一，纯文本文件不含可执行代码。传统杀毒软件和端点检测响应（EDR）系统主要扫描可执行文件、脚本特征和已知恶意行为，通常不会把一段Markdown说明当作威胁。代码评审时，评审人员习惯关注业务逻辑，很少逐行审查面向AI的指令文本。
第二，Agent通常拥有较高的本地权限。为了完成编码任务，Agent往往需要执行Shell命令、读写项目文件、访问依赖管理工具。一旦它被诱导执行非预期操作，本地的 .env 文件、包管理器的全局配置、云平台凭证都可能成为读取目标。
第三，非交互模式减少了人工确认。部分团队会把Agent命令行工具放进定时任务或CI脚本中，以批处理方式运行。这种模式下，工具通常不会弹出信任确认，进入上下文的指令可能直接转化为操作。
公开的安全研究已经证明，这类攻击面真实存在。实际成功率高度依赖工具版本、配置方式和测试条件。除非能查到原始报告、样本规模和测试环境，否则不应引用具体数字来判断自身风险。
从防御角度看，一次成功的指令文件投毒通常需要几个条件同时成立：
只要切断其中任意一个条件，风险就会明显下降。后文的防护策略正是据此设计。
很多开发者会把指令文件投毒和开源包投毒混为一谈。两者的触发点和防护重点并不相同。
| 对比维度 | 传统供应链投毒 | 指令文件投毒 |
|---|---|---|
| 攻击入口 | 恶意依赖包通过依赖声明被引入 | 不可信的指令文件进入Agent工作目录 |
| 触发时机 | 安装依赖或加载模块时 | Agent读取上下文并规划任务时 |
| 检测信号 | 依赖清单变动、包签名与校验和异常 | 指令文件的来源、内容变化与未追踪文件 |
| 主要防护 | 依赖审查、版本锁定、完整性校验 | 目录隔离、权限收紧、沙箱运行、出站监控 |
两类风险可以同时存在，因此防护也需要覆盖两条路径。
没有单一措施能完全消除风险。建议组合使用以下四层策略。
第一层：启动目录隔离
第二层：权限最小化与确认机制
第三层：沙箱与容器化运行
第四层：出站流量监控
可以用下面的清单快速自查：
| 防护层 | 检查项 | 合格标准 |
|---|---|---|
| 启动目录 | Agent启动位置 | 位于具体项目子目录，不在家目录或下载目录 |
| 指令来源 | 新获取的代码 | 已 |