AI 编程 Agent 指令投毒：定义、原理与防护

agent-">一、概念定义：什么是 Agent 指令投毒

Agent 指令投毒（Instruction-file Poisoning，也可归入上下文投毒、上下文注入一类）指攻击者把一个恶意的“Agent 指令文件”放进 Agent 将会读取的工作目录。这个文件用业界通行的 Markdown 形式写成，原本用于向编码型 AI Agent 声明项目结构、构建命令、编码规范、允许执行的操作等。投毒之后，Agent 启动时把攻击者的意图当作“项目本身的规范”读取并照做，于是不需要任何传统漏洞利用，就能让 Agent 读取敏感文件、安装来源不明的依赖、把代码或凭据发送到外部地址。

分三个视角理解会更清楚：

• 技术视角：这是一次针对“上下文优先级”的攻击。被攻破的不是程序的内存或进程，而是模型的决策上下文。Agent 无法可靠区分“这是开发者写的项目规范”和“这是别人塞进目录里的一段文字”，因为两者在磁盘上是同一种东西——纯文本。
• 业务视角：这是一类供应链风险，只是被投毒的载体从依赖包变成了“给 AI 看的说明书”。而且说明书的投递成本远低于一个能过扫描的恶意包。
• 使用视角：多数中招路径并不是被黑，而是用户在错误的目录里启动了 Agent，并在首次运行时点了“信任此目录”。

它之所以会被用来攻击，恰恰因为它解决了真实问题：开发者需要在项目里长期维护一份“怎么构建、怎么测试、哪些命令能跑”的说明，避免每次会话都重复解释。业界因此形成了“目录即上下文”的默认约定——这个约定带来的效率，同时也意味着：任何能往目录里写文件的一方，都获得了对 Agent 的指挥权。

二、为什么它值得后端与平台同学重视

这次事件的形态很朴素：某安全研究团队披露，客户机器上的编程 Agent 试图安装一个恶意依赖包，包名伪装成看起来无害的工具库；追查下来，指令来自 ~/Downloads 目录里一个被投放的指令文件，而这个目录恰好就是 Agent 的工作目录。研究团队用无害载荷（例如拉起计算器）复现了同类路径，成功率相当高；另一类复现则通过恶意指令文件把 Agent 的模型接口流量重定向到攻击者服务器，窃取访问令牌后由伪造的“模型”返回工具调用，实现代码执行。研究方还观察到，有相当规模的开发者在下载目录、临时目录这类位置启动过编程 Agent，其中累计会话数达到四位数。

值得重视的理由有四条，而且每一条都指向“现有防护手段天然覆盖不到”：

1. 指令文件是纯文本。 基于特征与行为特征的终端检测通常不会拦一个 Markdown 文件，代码评审也很少有人逐行读 Agent 的项目说明。
2. Agent 拥有真实执行能力。 它能跑 shell，意味着一条命令就能读出构建工具的凭据配置文件、项目根目录下的环境变量文件、部署脚本里的密钥，读取行为本身完全“合法”。
3. 非交互模式没有信任对话框。 很多团队把 Agent 以 -p 类参数写进脚本做批量重构或文档生成，这类模式通常不会弹出目录信任确认，等于把“是否信任此目录”这道人工闸门整个跳过。
4. “选对目录”是一条软约定。 没有工具强制校验工作目录，而下载目录、桌面、家目录这些位置是很多临时任务的默认起点。

三、攻击链拆解：四个环节，每一环都有对应失效点

整条链路可以拆成四步，逐步看清它为什么能走通：

环节	攻击者动作	为什么能成立
① 投递	恶意网页触发静默下载，指令文件落入下载目录	主流浏览器默认把文件直接存进下载目录，用户无需确认打开
② 落位	用户在下载目录启动 Agent（例如“帮我整理一下下载的文件”）	Agent 以当前目录为工作目录，并自动装配该目录下的指令文件
③ 取信	首次运行时弹出“是否信任此目录”，用户顺手确认	目录名看起来无害，用户没有阅读指令文件的动机
④ 执行	Agent 按指令安装依赖／读取凭据／外发数据	工具调用即真实 shell、文件与网络访问，缺少执行前的语义校验

关键结论：这不是某个版本的缺陷，官方厂商本身也建议“在项目目录里启动 Agent，不要在家目录或范围很大的上级目录启动”。也就是说，攻击面来自设计取舍，而不是一个待修复的漏洞——这决定了防护只能靠工程约定与纵深防御，而不是等一个补丁。

四、工作原理：上下文装配 → 信任决策 → 工具执行

第一步，上下文装配。 Agent 启动时会扫描工作目录及其上层若干层，寻找约定的指令文件名，把命中的内容作为系统级或项目级提示注入。这一步没有任何来源验证——它不关心文件是谁写的、什么时候出现的。

第二步，信任决策。 多数实现会在检测到“目录级配置”或“将执行的操作超出预设范围”时，要求一次人工确认。确认粒度通常是目录，而不是单个文件或单条命令。一旦确认，该目录下后续会话往往直接放行。

第三步，工具执行。 模型输出的工具调用被宿主程序翻译成真实动作：写文件、跑命令、访问网络、读取环境变量。此处默认的假设是“模型的决定代表用户意图”，于是指令与数据的边界消失了：一份本应被当作“参考资料”的文件，实际被当作“命令”执行。

五、四层防护与每层的已知绕过

第一层：启动目录约束（最有效、成本最低）
做法：只在自己创建、可完整审阅的项目目录里启动 Agent；显式传入目录参数而不是依赖当前目录；在脚本里加前置校验。

# 伪代码：启动前体检，示意用途，不对应任何具体工具的配置项
function preflight(cwd):
    if not isTrustedProjectRoot(cwd):
        abort("请切换到明确的项目目录后再启动")
    for f in collectAgentInstructionFiles(cwd, maxParentDepth = 1):
        if not reviewed(f):
            abort("存在未审阅的指令文件: " + f.path)
        if hasHiddenOrEncodedPayload(f):
            quarantine(f)

已知绕过：把会话切到项目子目录、通过符号链接指向外部目录、从 CI 脚本或包装脚本启动（cwd 由脚本决定）、先 cd 到大目录再启动。

第二层：上下文来源控制
做法：把指令文件纳入代码评审；对新增或变更的指令文件设置强制审批；用启动钩子拦截“读取凭据类路径”“执行任意网络命令”这类高危意图。

# 示意：把高危动作显式列入拒绝清单，优先级高于任何目录级授权
deny:
  - read: ["**/.env", "**/credentials", "~/.config/**/*.xml"]
  - exec: ["* curl *", "* wget *", "* 包管理器 install *"]

已知绕过：把指令藏进多级子目录、使用不同语言的同名变体文件、利用 Unicode 同形字符与零宽字符绕过关键字匹配、藏在 HTML 注释里、用超长文件淹没人工审阅、把真实指令做编码或分段拼接。

第三层：凭据与环境隔离
做法：不要把长期凭据放进环境变量或仓库内文件；CI 使用短生命周期令牌并按任务最小授权；本地开发使用独立、可随时吊销的账号；避免让 Agent 会话继承开发机上的全部凭据。

已知绕过：读取构建工具的本地凭据配置文件、读取 SSH 代理套接字、访问云主机元数据地址获取实例角色令牌。所以还要在主机侧关闭或限制元数据访问，并把会话运行在低权限账户下。

第四层：执行面与出口收敛
做法：优先在容器或一次性工作区里运行 Agent；对依赖安装要求显式确认，锁定版本并校验完整性摘要；对出网做域名白名单；开启会话级命令审计并留存日志。

已知绕过：沙箱内的高权限挂载导致逃逸、白名单域名上存在开放重定向、通过 DNS 查询外带数据、把敏感内容写进日志后再外传、攻击者预先抢注与内部包同名的公开包（依赖混淆）。

六、高风险场景清单

• 在下载目录、桌面、临时目录、~ 根目录启动 Agent；
• 在“包含很多项目的上级目录”启动，导致上层目录里的指令文件被继承；
• 把 Agent 以非交互参数写进批处理、定时任务或 CI；
• 直接克隆来源不明的仓库并在其根目录启动 Agent；
• 使用网页版或云端开发环境打开他人分享的压缩包、模板工程；
• 在装有跳板机凭据、私有仓库凭据、云访问密钥的开发机上运行高权限 Agent 会话。

七、与相关概念的区别

• 与提示词注入的区别：提示词注入的载荷通常在“被处理的数据”里（网页、Issue、日志、文档），受害者是模型输出；指令投毒的载荷在“工作目录的配置文件”里，受害者是 Agent 的整套工具链，破坏面更大且更持久。
• 与供应链攻击的区别：目标一致（借信任关系进入执行环境），但载体不同。依赖投毒需要过仓库审核、可能被扫描发现；指令文件是本地纯文本，投递几乎无摩擦。
• 与命令注入的区别：命令注入利用的是程序拼接命令的缺陷；这里没有缺陷，Agent 是“正确地”执行了它被要求的事。
• 与 MCP 等工具扩展投毒的区别：扩展投毒改的是 Agent 的能力边界，指令投毒改的是 Agent 的行为意图，两者可以叠加使用。

八、使用注意事项

1. 把“工作目录”当成权限边界来管理，而不是当成一个路径字符串。
2. 指令文件应当像代码一样有作者、有评审、有变更记录；突然出现的、不属于本项目的指令文件应视为异常。
3. 非交互模式风险更高，必须补一层人工外的自动化闸门（目录校验、依赖白名单、出网限制）。
4. 不要给 Agent 会话开放超出任务需要的目录与凭据范围；一次只授权一个项目。
5. 审计日志要覆盖“读了哪些凭据类路径”“执行了哪些网络命令”“安装了哪些包”，这三类是投毒后最典型的动作。
6. 使用云上托管开发环境时，可结合主流云平台通用的身份认证、密钥管理、日志审计、监控告警等类目能力收敛风险；例如在百度智能云上构建开发或 CI 环境时，把凭据托管、操作审计与告警作为默认配置，而不是事后补齐。

九、中招后的处置步骤

1. 立即止损：终止所有 Agent 进程与关联的 shell；断网或限制该主机的出网。
2. 确认范围：检查最近会话的工作目录、被安装的依赖及其安装时间、会话日志中的网络命令与外连地址。
3. 凭据轮换：假定本机所有可被读取的凭据已泄露——云访问密钥、私有仓库令牌、SSH 密钥、数据库口令，全部吊销重签。
4. 清理现场：删除被投毒的指令文件与恶意依赖，回滚受影响的代码提交，重建工作区而不是就地修补。
5. 排查横向影响：检查 CI 变量、制品仓库、已推送的分支与镜像中是否残留恶意内容。
6. 补防护再恢复：按上文四层收敛后再重启会话，并把本次事件写成团队级的启动目录规范。

十、总结

Agent 指令投毒的本质，是用一份纯文本文件买到了 Agent 的执行权。它之所以有效，不是因为某个产品有洞，而是因为“目录即上下文”这个便利设计天然缺少来源验证与优先级区分。因此对使用者而言，最有效的单条措施依然朴素：只在自己能完整审阅的项目目录里启动编程 Agent，非交互批处理尤其如此；在此基础上叠加目录与依赖评审、凭据隔离、执行沙箱与出口白名单，才能把这类攻击的成功率压到可接受的水平。