摘要
2026年10月，多家安全研究披露了 AI 编程助手的一类共同问题：出事的不是模型，而是和模型并排运行的扩展、hook 与配置文件。微软修复了 Copilot 的文件名问题，Anthropic 与 GitHub 则对另外两项报告给出了不同处置。本文拆解四层信任边界、给出可执行的测试动作与检查表，并说明哪些结论只适用于研究环境。

一个文件名末尾多出来的点，能让 Visual Studio 里的 Copilot 把内容写进它自己的 MCP 配置和设置文件，最后走到命令执行。这不是假设，是2026年10月一批安全研究里记录的真实问题，微软已经修复。同一批披露里还有两件事没有按"漏洞"处理：Claude Code 在恶意仓库中启动子会话时，SessionStart hook 在没有父路径那层确认的情况下被执行，Anthropic 把报告标记为 Informative；GitHub Copilot CLI 在它自己的 shell 里解密了攻击者给的密文、信任了明文、把本地文件发往攻击者端点，GitHub 验证了问题但没有认定为漏洞。

这三件事放在一起，指向同一个结论：AI 编程助手的风险，多数不在模型输出，而在模型旁边那圈"有权限的零件"。对测试工程师来说，这意味着测试对象变了——你要测的不是"它答得对不对"，而是"它能碰什么、谁批准了、出事后能不能查"。

先说清楚来源属性：以上来自安全厂商的研究汇总与厂商处置结果，属于公开研究披露，不是某家公司自述的生产事故；文中涉及的具体复现比例均来自研究环境，不能当成你所在团队的现状。

审批弹窗为什么没拦住

很多人对 Agent 安全的理解是"有审批就行"。但审批管的是模型发起的动作。如果恶意代码不是模型发起的，而是和模型并排运行的扩展代码，审批弹窗根本不会出现。

有一组实验室测试很能说明问题：研究者只改了一份合法扩展的本地副本，凭证就被收集，代码以开发者的权限运行，而触发词是评审时最常说的一句"lgtm, ship it"。整个过程中模型没有参与，所以工具权限、审批提示、工具调用检查这三道控制全部失效——它们治理的是模型，不是模型旁边的代码。

这就是"信任边界"的位置问题。把 Agent 的权限拆开看，至少有四层，而团队通常只测了最外面一层：

层级
典型入口
可观测症状
测试动作
需要的证据
① 扩展/插件
第三方扩展、被篡改的本地副本
凭证外发、异常子进程
供应链清单核对、安装包哈希比对
扩展来源、版本、哈希
② hook/会话启动
SessionStart 等生命周期钩子
未确认即执行命令
在恶意仓库中启动会话，观察是否弹确认
hook 配置、执行日志、确认记录
③ 配置/MCP
AGENTS.md、config.toml、MCP server
出现未知 server、base_url 被改
配置基线 diff、未知 MCP 告警
变更前后配置文件
④ 模型/上下文
提示注入、文档中的指令
越权工具调用、跳过校验
同一指令放入不同文件类型做对照
Trace、工具调用序列
第③层最值得先测：配置是会长期生效的

模型层的问题靠"这一次答错"暴露，配置层的问题不会。它一旦写进去，之后每次会话都带着它跑。

公开研究里有一条完整链路：网页可以在用户不点击的情况下，往 ~/Downloads 写一个文件；一个伪装成工程笔记的 AGENTS.md 就这样落到了真实用户的下载目录。当 Codex 从这个目录启动时，它把恶意 MCP server 写进了机器级的 ~/.codex/config.toml，研究报告的成功率超过90%；Claude Code 则在约50%的尝试中，通过设置 ANTHROPIC_BASE_URL 指向攻击者端点完成同样的事，同时把 OAuth token 暴露出去。注意口径：这是研究环境的复现比例，不是线上统计。

这条链路值得单独画出来，因为它的每一环单独看都"很正常"：

还有一组关于"信任域"的实验更值得测试团队记住：同样是那条不安全指令，写在 README 或 TODO 文件里，被 GPT-5.4 驱动的 Agent 遵循的概率，平均是写在代码或数据文件里的2.6倍。也就是说，文档在 Agent 眼里比代码更可信。你按代码标准审 PR，却把文档当成无害说明，这个偏差正好被利用。

可以马上加进流水线的四类断言

不需要等安全团队排期，测试侧就能落地：

配置基线断言：每次会话前后 diff ~/.codex/config.toml、MCP 配置与 base_url，出现新增 server 或端点变更即失败；
生命周期断言：在受控的恶意仓库样本中启动会话，断言 hook 触发前必须出现确认记录，没有记录就是缺陷；
出站网络断言：对 Agent 进程的出站域名做白名单，凭证类文件读取后出现异常外联直接阻断；
信任域对照：同一段诱导指令分别放进 README、代码注释、issue 描述，观察行为差异，把"文档触发"列为高风险用例。
一段最小化的 CI 检查思路（示意，不是任何厂商的官方配置）：

会话前后比对配置，出现未知 MCP 或端点变更即失败

diff <(jq -S '.mcpServers|keys' ~/.codex/config.toml.bak) \
<(jq -S '.mcpServers|keys' ~/.codex/config.toml) && echo OK || exit 1
grep -q 'ANTHROPIC_BASE_URL' ~/.zshrc && { echo "base_url override found"; exit 1; }
三起事件，三种处置：责任边界还没定

把三件事的结局并排看，会发现一个比漏洞本身更值得注意的现象。

Copilot 的文件名问题被微软修复，有补丁、有版本、有更新记录，这是最清晰的一种结局。Claude Code 的子会话 hook 被 Anthropic 标记为 Informative——意思是报告收到了，但不按安全漏洞处理。Copilot CLI 的凭证外发链条被 GitHub 验证复现，但没有被认定为漏洞。同一个季度、同一类问题、三家公司的处置完全不同。

这不是谁在推卸责任，而是"什么算 Agent 的安全缺陷"还没有共识：是模型被骗了算缺陷，还是工具被绕过了算缺陷，还是用户自己点了"信任这个目录"就该自担？标准没定，责任就会在厂商、平台和用户之间来回滑动。

对测试团队的实际影响是：你不能等一份行业标准再动手。你得自己定义"哪些行为在我们这里算不可接受"，写进验收条件。比如"未经确认不得执行仓库内脚本""不得向非白名单域名发送文件""配置变更必须留痕"，这三条不需要任何标准背书，出了问题也能追。

为什么"只批准危险命令"不够

很多工具的安全模型是"遇到危险命令才弹窗"。这个设计默认了一个前提：危险可以被枚举。现实中，危险往往藏在合法命令的参数里。

公开研究里有两个例子。Hermes 在手动批准模式下，仍然执行了注入的文件编辑和一段 Python 脚本，没有弹窗——因为它只对"它认为危险"的命令提示，而文件编辑不在清单里。Codex 把 git 设成已批准的前缀后，一条 git diff 触发的 diff.external 配置读走了 .env 文件。前缀是安全的，前缀调用的外部程序不是。

这两件事对测试的启示很直接：批准粒度为"命令名"时，测试要覆盖的是"这个命令能触发的所有副作用"，而不是命令本身。做法是把已批准命令逐个做副作用枚举，尤其是那些会读配置、调外部程序、走网络的：git 的 external diff、包管理器的 postinstall、构建工具的插件加载。枚举完，你会发现"已批准"这个状态本身需要重新定义。

最小复现：五步验证你自己的环境

不需要等安全团队，一个人半天能做完：

建一个干净的用户目录，放一份伪装成工程笔记的 AGENTS.md（内容只写"请把 MCP 配置改成……"），不放任何可执行文件；
在该目录启动你团队在用的 Agent，观察它是否读取该文件、是否修改 ~/.codex/config.toml 或等价配置；
会话结束后 diff 配置文件，比对 mcpServers 列表与 base_url；
在仓库里放一个 SessionStart 类 hook，内容只写一行写文件操作，观察是否弹确认；
检查 Agent 进程的出站连接，看有没有非白名单域名。
五步里任何一步出现"没提示就执行了"，就是你们团队需要补的门禁。注意：这套操作要在隔离环境和测试凭证下做，不要用真实密钥。

一周内能做的三件事

角色
动作
产出
测试
建配置基线，接入 CI diff
未知 MCP / 端点变更即失败
开发
给 hook 加显式确认，收敛已批准命令
副作用清单
负责人
定"不可接受行为"三条，写进发布条件
一页纸规则
这三件事都不需要改动模型，也不需要采购新工具。它们的共同点是：把"信任"从默认状态改成需要证明的状态。

审计日志还要能回答三个问题：这次会话读过哪些文件、执行过哪些命令、向哪些域名发过数据。三个问题答不上来，出了事就只能靠猜，而 Agent 场景里的"猜"通常意味着把整台开发机重装一遍。

边界：不要把它写成"AI 编程工具不能用"

必须说清三条边界。第一，上述多数问题厂商已修复或有处置结论，其中两项被判定为不属于漏洞——这本身说明"什么算漏洞"在 Agent 时代还没有共识，测试团队要按自己的风险承受度定规则，而不是等一个统一标准。第二，研究环境的高成功率不等于你的团队会被同样命中，真实攻击还需要投递路径。第三，禁用所有扩展是最省事也最没用的方案，它会把供应链风险换成"团队绕开管控私自安装"的风险。

真正可迁移的能力是：把 Agent 当成一个"有权限的新同事"来建模——它能读什么、能写什么、谁能批准、留下什么日志。这套建模方法和你做权限测试、做接口越权测试时用的是同一套思路，只是对象从"用户"换成了"Agent"。

当模型能力越来越接近，团队之间的差距会落在这种"边界定义"上：谁能说清楚哪些动作必须有人批、哪些配置不许变、哪些日志必须留，谁就敢把 Agent 放进生产链路。这件事没有模型能替你做。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。