工具调用如何失控：跨工具污染与 Prompt-to-Anything 的权限链路

原创

lidasimida
lidasimida

安全学习之路

2026年10月3日 19:09
广东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

先给结论：工具调用真正危险的地方，不是模型会不会说错

Agent 的风险不只在于模型生成了一段错误文字，而在于这段文字可能继续影响工具选择、参数提取和外部状态。一个工具的描述、返回内容、错误消息、检索材料或摘要，都可能进入下一轮模型上下文；当执行器同时开放了私有数据读取、外部通信或状态修改时，原本属于“内容”的东西就可能沿着工具链变成动作依据。

本文把这个过程称为“信任落差”：系统把内容交给模型时，往往只验证了格式和来源通道，却没有验证这段内容是否有权改变任务目标、调用参数或数据去向。信任落差不是某个协议独有的漏洞，也不是“模型看见一句话就必然执行”的简单因果，而是模型决策、宿主策略、工具权限、数据流和外部副作用共同形成的工程问题。

理解这类风险，至少要分清三件事：模型提出了什么调用，宿主允许了什么调用，工具实际改变了什么状态。前两者可以不一致，工具返回结果也可能继续影响后续调用。公开研究和披露已经分别展示了工具描述干扰、外部消息污染和跨工具数据流等现象，但它们的攻击者能力、工具权限和实验设置不同，不能合并成一个“所有 MCP 都会被攻破”的结论。[R01][R02][R04][R13][R14][R15]

一、先看懂一次工具调用是怎么发生的

模型提出调用，执行器决定执行

把 Agent 的一次动作拆开，最容易避免“模型输出等于系统执行”这种误解。用户先提出任务，宿主程序把系统约束、工具定义、历史上下文和必要材料组织给模型。模型根据这些输入生成自然语言，或生成一个结构化的工具调用提议。提议通常包括工具名称和参数，但它仍然只是待处理的决策结果。

随后，宿主或协议客户端验证工具是否存在、参数是否符合 Schema、当前主体是否拥有对应能力、目标对象是否在允许范围内，以及这次动作是否需要人工确认。通过这些检查后，执行器才会调用工具。工具执行可能只读数据，也可能发送消息、修改仓库、更新工单或触发其他系统。返回结果再次进入上下文，成为下一轮模型决策的材料。[R01][R03]

这条链路可以用四个状态描述：提议、校验、执行、观测。提议阶段适合发现模型是否被外部内容带偏；校验阶段决定策略是否真的挡住了不当动作；执行阶段才会产生副作用；观测阶段要记录真实状态，不能只保存模型的解释。若只记录最终回答，无法判断问题发生在模型、策略还是工具本身。

图一 工具调用中的信任边界

图一显示了一个关键事实：工具定义和运行凭证不是一回事。工具描述可以告诉模型“这个工具做什么”，但不应成为权限授予的唯一依据；Schema 可以约束参数类型，但不等于收件人、文件、仓库和数据流已经获得业务授权。MCP Tools 规范把输入校验、访问控制、结果校验和审计分别放在不同的责任点，不能把其中一个字段当成全部安全边界。[R01]

工具描述、Schema 和权限不是一回事

工具定义通常包含名称、用途描述、输入 Schema 和可能的注释字段。它解决的是“模型如何发现和组织调用”，不是“这次调用在业务上能否发生”。例如，Schema 可以要求 recipient 是字符串，要求 repository 使用固定格式，也可以通过枚举限制动作类型；但它无法仅凭字符串类型判断某个收件人是否属于用户授权范围，更不能判断被发送的文件是否允许外发。

可以把三种检查分开：

• 结构检查：字段是否存在，类型是否正确，值是否满足基本格式。
• 能力检查：当前主体是否能调用这个工具，是否能访问这个对象。
• 目的检查：本次数据是否允许流向这个接收者，动作是否符合用户授权目标。

这三项的失败模式不同。结构检查失败通常是参数错误；能力检查失败通常是权限不足；目的检查失败则可能表现为“调用完全合法，但做了不该做的事”。安全系统如果只做第一项，就会把业务越权误认为输入格式问题。

控制面、数据面和权限面

为了分析跨工具污染，可以把一次调用拆成三条面：

观察面	主要内容	应当回答的问题	常见误判
控制面	任务目标、工具选择、调用顺序、审批状态	为什么会调用这个工具	只看最终回答，忽略模型提议和被新增的动作
数据面	文件、消息、Issue、网页、摘要、参数值	哪些数据被读取、转换和传出	只要内容来自可信服务器就当成可信指令
权限面	身份、令牌、对象 ACL、接收者和额度	谁能对什么对象做什么动作	把工具白名单当成对象级授权

控制面决定“做什么”，数据面决定“带什么”，权限面决定“能否做”。跨工具污染往往让控制面或数据面发生变化，而真正造成损失的条件通常出现在权限面：执行器没有验证对象范围、接收者或外部副作用，或者给了一个过宽的凭证。OWASP 对提示注入和过度代理能力的分类，正好说明了输入污染与动作后果需要分别治理。[R16][R17]

二、外部内容为什么会变成模型的指令

工具描述入口：模型看到的不只是用户话术

工具描述是最早被忽略的一类输入。很多系统在启动时把一批工具的名称、说明、参数和示例一次性提供给模型。只要描述可以被第三方服务器维护、动态刷新或在接入时未经审查地加载，它就不再只是静态文档，而是会参与模型决策的上下文。

Invariant Labs 的工具投毒披露展示了一个受控现象：恶意工具不需要先被模型调用，工具描述中的文字就可能影响模型如何使用另一个看起来可信的工具。披露中的重点不是某个具体产品被普遍攻破，而是说明“未执行的工具也可能通过元数据影响决策”。因此，工具接入审核不能只看是否会执行本地命令，还要看描述、参数说明和变更是否被纳入版本管理。[R13]

这一入口的判断证据有三层：第一，恶意描述是否真的被加载到模型上下文；第二，在不改变用户任务和其他工具的条件下，模型提议是否发生变化；第三，执行器是否依靠独立策略阻断了不当动作。只看到描述里存在可疑文字，只能算风险线索；只有调用轨迹、策略决策和实际状态一起变化，才能说明影响链路成立。

工具返回内容入口：可信通道不等于可信作者

第二类入口来自工具返回的数据。一个官方或可信维护的服务器，可能忠实地返回用户写入的 Issue、聊天消息、网页正文、工单备注或文档内容。服务器在协议层是可信的，返回内容的作者却可能是外部用户。模型如果没有明确区分“数据”与“指令”，就可能把作者写给人的文本当成任务要求。

这也是间接提示注入的核心：攻击内容不直接出现在系统提示或用户消息里，而是先进入网页、邮件、消息、代码注释、文档或工具结果，再由 Agent 读取。Greshake 等人的研究把这种外部内容进入模型控制输入的路径系统化；InjecAgent 和 AgentDojo 则把工具集、任务效用、攻击目标和防御效果放进可重复的评测环境。它们说明问题可以被实验化，但不等于任何研究中的成功率都能直接当成企业生产概率。[R04][R05][R06]

对于返回内容，至少要保留作者、来源对象、采集时间、原始内容摘要和进入下游的字段。模型可以提取“文件名”“邮箱”“仓库名”等候选值，但不能因为这些值来自工具返回就自动获得授权。数据字段需要继续带着来源和信任级别，直到执行器完成目的和权限检查。

摘要、记忆和检索入口：污染可能被压缩后继续传播

系统常常不会把原始内容原样传给下一个 Agent，而是先经过摘要、任务交接、向量检索或长期记忆。压缩并不会自动消除控制影响，反而可能丢掉来源和上下文，只保留一句“下一步应该发送文件”之类的结论。下游模型看见的文字变短了，却更难判断它是用户目标、外部作者意见，还是上游模型的推断。

因此，摘要对象至少要有四个字段：原始材料标识、摘要作者或生成器、允许保留的事实字段、不能改变的授权边界。检索结果要标明是“参考材料”还是“任务指令”，记忆条目要有写入主体、有效期、适用范围和撤销方式。Spotlighting 等来源标记方法可以帮助模型识别不可信材料，但研究本身不把它当成确定性授权机制；NCSC 也强调，提示注入不能简单套用 SQL 参数化的解决思路，真正的动作约束仍应由外部确定性控制完成。[R12][R19]

污染入口	进入上下文的材料	可能影响的对象	最小验证证据
工具描述	名称、说明、示例、注释、版本变更	工具选择和参数解释	描述快照、上下文记录、调用提议差异
工具返回	消息、Issue、网页、文档、错误文本	任务目标、提取值和后续动作	来源对象、原始返回、字段传播轨迹
摘要交接	上游摘要、计划、分类标签	下游 Agent 的控制输入	摘要版本、来源映射、下游输入
检索与记忆	历史条目、向量命中、长期状态	后续任务和持久化行为	写入者、有效期、召回记录、撤销结果

三、什么是跨工具污染

工具 A 不需要直接攻击工具 B

跨工具污染不是指工具 A 在网络层直接调用工具 B，而是工具 A 的描述或返回内容影响了共享上下文，模型随后调用工具 B，宿主再用已有权限执行。工具 A 甚至可以是只读工具，工具 B 也可以是官方工具；连接它们的是同一个决策过程和同一个执行账户。

最典型的链路是：工具 A 返回外部作者内容，模型把其中一句话解释为后续步骤，生成工具 B 的参数，执行器只验证了参数格式和令牌有效性，工具 B 于是读取或写入了超出任务目的的数据。这里没有必要假设模型获得了新的系统权限，也没有必要假设协议被破解。问题是已有能力被不可信材料重新组合。

图二 跨工具污染的两条入口

图二把两条入口分开：上方是元数据路径，下方是业务内容路径。进程沙箱可以限制工具 A 自身能访问什么，但不能单独决定 A 的文字能否影响工具 B 的参数；数据流策略则负责判断某个来源的数据能否流向某个接收者。两层控制必须同时存在。

控制流改变与数据流改变

跨工具污染至少有两种形态。第一种是控制流改变：原任务只要求读取公共内容，模型后来新增了读取私有仓库、修改记录或公开发布的动作。第二种是数据流改变：工具调用顺序没有变化，但文件对象、收件人、仓库名、查询条件或提交内容被外部材料改变，造成原本不允许的数据流。

公开 GitHub MCP 披露更接近第一种：研究者描述的链路是公共 Issue 牵引 Agent 读取用户本来就有权限访问的私有仓库，再向公共 PR 写入内容。这个案例的关键边界是：它不是绕过 GitHub ACL，也不是说明 GitHub MCP 服务器被攻破，而是公共输入和已有私有读取、公共写入能力被组合成了有害的工作流。[R15]

CaMeL 论文给出了第二种形态的机制反例：即使动作计划固定，外部内容仍可能影响文件名或收件人等参数。固定“读取、提取、发送”的顺序不代表参数已经获得授权，必须继续追踪值的来源和允许去向。[R10]

图三 正常调用也可能产生不当结果

图三说明，调用结构正确、工具可信和令牌有效，都不足以证明结果正确。需要把材料作者与范围、真实调用和参数、策略与批准记录、最终外部状态串成一条证据链。任何一段缺失，都只能把结论降级为待验证。

Prompt-to-Anything 是解释性概括，不是标准名称

本文用 Prompt-to-Anything 概括一种跨层现象：提示或被污染的上下文先影响模型，再被模型转写成工具调用、参数或计划，最后由宿主和外部系统落实为读取、发送、修改或执行。它不是已确认的协议、漏洞编号或统一学术术语，也不意味着任意提示都能直接控制任意系统。

从提示到外部后果，中间至少要经过五个条件：内容进入模型上下文，模型将其解释为行动依据，工具和参数确实可达，执行器允许这次动作，外部系统产生可观测状态变化。缺少任意一环，影响都可能停在模型文本层。工程验证应逐环记录，而不是看到一段可疑文字就宣布“已经执行”。

四、四个公开案例看清风险如何落地

下面的案例记录分为三种材料：公开披露的事实、根据公开机制整理的脱敏验证记录，以及建议在隔离环境执行的验证步骤。公开披露没有给出完整原始 JSON、模型版本或逐条日志时，表格只表达字段关系和故障位置，不代表官方日志逐字内容。文中的邮箱、仓库、消息和文件均应使用合成对象；不连接真实收件人、真实私有仓库或生产系统。

为了便于理解，先把“污染”想成一条传递链：外部内容先进入模型上下文，模型再把它改写成工具名称或参数，执行器最后决定是否真的调用工具。服务器之间通常没有直接互相调用；真正需要检查的是“谁提供了内容”“模型看到了什么”“哪一个工具实际执行了”“外部状态有没有改变”。

案例一：未调用的工具描述影响可信邮件工具

实验边界。 Invariant Labs 的工具投毒披露设置了一个可信邮件工具和一个带有误导性说明的工具。公开事实是：恶意工具的描述可能在未被调用的情况下影响可信工具的调用；公开材料不等于本文已经在本地复现。建议验证环境只使用合成邮箱、测试附件和记录型邮件适配器，模型、邮件工具、凭证和用户任务在对照组与实验组保持一致。[R13]

先把对象对应起来。 可以把可信邮件工具看作工具 A，例如 send\_mail；把攻击者控制的“加法工具”看作工具 B，例如 add。工具 B 的功能本身并不重要，关键是它的描述被客户端提供给了模型。工具 B 不需要取得邮件凭证，也不需要直接调用工具 A；如果它的描述改变了模型对 send\_mail 的理解，模型仍可能只提出工具 A 的调用。

正常基线。 用户提出：“把 report.txt 发送到内部测试邮箱 [email protected]。”正常情况下，模型只需提出一次可信 send\_mail 调用；执行器检查收件人属于测试 allowlist、附件来自测试目录，记录型适配器返回“已记录”，而不是连接真实邮件系统。基线至少保存工具描述版本、模型提议、策略决定和最终记录状态。

单变量变化。 在实验组新增一个未被任务使用的测试工具，只替换该工具的描述快照；不改变用户任务、可信邮件工具、模型参数和凭证。不要在文档或测试中放入真实密钥、真实文件路径或可外传的敏感内容，只使用不可用的合成字段和固定测试标记。

脱敏验证记录。 下表是根据公开机制整理的验证格式，不是 Invariant Labs 的原始日志：

步骤	观测到的调用或状态	参数来源与策略判定	如何定位问题
1	宿主加载可信 send\_mail 与新增测试工具的描述	描述快照出现版本差异；测试工具尚未被调用	只能证明元数据进入模型可见上下文，尚不能证明有副作用
2	用户任务保持不变，模型提出 send\_mail	基线收件人为测试邮箱；实验组比较收件人、附件和正文是否变化	第一个偏离点在模型提议层，而不是邮件工具执行层
3	执行器检查字段类型、收件人范围和附件来源	只做 Schema 检查可能放行；对象策略应拒绝未授权收件人或附件	判断执行器是否把“格式合法”误当成“目的合法”
4	记录型适配器保存发送请求，不连接真实邮箱	允许时记录成功；拒绝时记录策略编号和拒绝理由	只有状态记录显示目标对象改变，才能谈实际副作用

故障定位。 如果实验组在第 2 步的提议发生变化，说明工具描述到可信工具参数之间缺少上下文隔离；恶意工具并没有“直接调用”邮件工具。如果第 3 步仍然放行，问题升级为执行器缺少收件人和数据来源校验；如果第 3 步拒绝，则只能说明执行闸门挡住了副作用，不能反推模型没有受到影响。

修复与回归。 对工具描述做版本锁定、来源标记和变更审批；把高风险工具按服务器或任务隔离上下文；邮件执行器独立校验收件人、附件对象和外发策略。回归时重跑“无污染基线、描述变化、恢复原描述、撤掉外发能力”四组条件，分别确认模型提议、策略判定和记录型适配器状态。若撤掉外发能力后仍能产生异常提议，只说明模型层仍可受影响；若记录型适配器从未写入目标状态，则不能声称邮件已经发送。

人工复核重点。 核对描述快照是否真的进入模型上下文，比较两组调用提议的差异，查看执行器使用的对象 ACL 和策略版本，并以记录型适配器的实际状态作为副作用证据。扫描出可疑描述只能算风险线索，不能直接写成邮件已发送。

案例二：WhatsApp 实验中的两种不同入口

材料与边界。 Invariant Labs 对 WhatsApp MCP 公开了两组实验。实验一关注恶意服务器元数据或变更如何影响可信 WhatsApp 工具；实验二关注外部消息经可信工具返回后，如何继续影响 Agent。两组实验分别对应元数据入口和业务内容入口，不能合并为一次攻击，也没有破解 WhatsApp 端到端加密。下文用测试号码、合成联系人和记录型发送接口描述验证，不复现原始注入内容。[R14]

实验一：描述变化牵引可信发送工具。

先把工具 A 和工具 B 对应起来。 工具 A 是可信的 whatsapp-mcp，它提供类似 list\_chats、read\_messages、send\_message 的能力；工具 B 是攻击者控制的另一个 MCP 服务器，它可以只提供一个看起来正常的 add、calculator 或文本处理工具。这里的“加载工具 B”不是执行它，而是 Agent 客户端启动或刷新连接时，向 B 请求工具清单，并把 B 返回的名称、说明和参数 Schema 与 A 的工具一起交给模型。

实际链路可以按五步理解：第一，客户端连接 A 和 B；第二，客户端分别读取两台服务器的 tools/list；第三，模型同时看到 A 的 WhatsApp 工具和 B 的工具描述；第四，用户提出一个正常的消息任务；第五，模型可能提出 A 的 send\_message 调用。B 可以从头到尾没有被调用，风险仍然可能发生在第四步到第五步之间。

公开的 WhatsApp 实验使用了 Cursor 等 Agent 客户端和 WhatsApp MCP，攻击者服务器采用了“先正常、后变化”的 sleeper 设计。第一次接入时，B 的描述看起来无害；后续启动或刷新时，描述发生改变。这里要把两件事分开：同一研究团队在邮件演示中明确使用过 add 工具影响可信 send\_email；WhatsApp 披露强调的是攻击者控制的 sleeper MCP 影响 WhatsApp 工具，不能把 add 直接写成 WhatsApp 官方工具名。

正常基线是：用户要求读取测试会话并把摘要发送给固定的 qa-recipient；list\_chats 只返回合成消息，send\_message 只写入内部发送记录。实验组只改变同时接入的非可信服务器描述，并记录它是否被实际调用。

步骤	调用轨迹	关键参数与证据	预期判定
1	加载可信消息工具与非可信服务器描述	保存服务器标识、描述版本和加载时间	非可信服务器未被调用，不代表其描述不可见
2	list\_chats 读取测试会话	会话 ID、消息来源、返回条数和来源标签	只读动作；返回内容与元数据入口分开记录
3	模型提出 send\_message	比较 recipient、正文长度和是否夹带上下文外字段	这里是元数据影响是否穿透到参数的观察点
4	执行器执行或拒绝发送	记录接收者策略、审批绑定和记录型发送状态	“已提出”与“已写入发送记录”必须分开

用一个直观的对照看第 3 步：正常情况下，模型应提出 recipient = qa-recipient，正文是测试摘要；如果只改变 B 的描述后，模型提议的收件人、正文长度或是否附带上下文外字段发生变化，说明 B 的描述已经影响了 A 的参数。此时还不能说消息已发送，因为第 4 步仍可能被执行器拒绝。

如果第 3 步出现收件人改变或正文长度异常，首先检查工具描述上下文；如果第 4 步根据接收者 allowlist 拒绝，说明出口闸门有效。公开披露中确认界面可能没有展示完整参数，因此验证时必须保存执行器收到的结构化参数，而不能只截取界面上的短文本。这个案例真正要观察的是“B 的描述是否改变 A 的调用”，而不是“B 是否成功执行”。

实验二：消息正文牵引后续动作。

这组实验不需要安装恶意 MCP 服务器，入口是一个外部发送者写入的消息。受控验证中，先把合成消息放入测试会话，再让 Agent 执行“列出最近测试消息并生成摘要”的正常任务；只改变其中一条消息的正文，其他会话、模型和工具保持不变。不要把原始注入语句或消息对象拼接细节放进生产系统。

步骤	调用轨迹	关键参数与证据	故障位置
1	list\_chats 返回测试消息	消息 ID、作者类型、会话范围、正文来源标签	外部作者内容进入工具返回结果
2	模型生成摘要或下一步提议	对比正常消息与变化消息的工具集合和参数	返回内容被当作控制输入的候选点
3	执行器校验后续动作	检查新联系人、外发目标和审批是否来自用户授权	若只看格式，可能放行不当接收者
4	记录型发送接口保存结果	保存接收者、正文长度、来源 ID 和状态	只有记录成功或真实状态变化才构成出口证据

两组实验的共同现象都是“Agent 可能发出不应发出的消息”，但第一组的入口是工具元数据，第二组的入口是业务返回内容。报告必须分别写出入口、模型提议、执行器决策和最终状态，不能把它们简化成“WhatsApp 被攻破”。

修复与回归。 消息读取、联系人选择、发送动作和接收者授权要分开；外部消息只能作为待分析材料，不能自动增加联系人、改变发送对象或绕过确认。回归时分别恢复正常描述、恢复正常消息、撤掉发送能力，并检查异常提议是否被拦截、正常摘要任务是否仍完成。修复后如果消息正文仍能改变模型建议，但发送接口始终拒绝，这表示“模型可受影响、外部副作用被阻断”，两者都应记录。

人工复核重点。 查看消息作者与工具服务器的身份是否被混淆，核对 list\_chats 的返回内容如何进入下一次模型输入，确认审批是否绑定实际接收者和正文摘要，并以发送记录或目标系统状态判断是否产生副作用。公开实验能说明风险路径，但不能推出所有 WhatsApp 集成或当前版本都存在同样问题。

案例三：公共 Issue 牵引私有仓库读取

实验边界。 GitHub MCP 公开披露的场景以公共 Issue 作为外部输入，Agent 读取用户权限范围内的私有仓库内容，再向公共 PR 写入。公开披露报告了公共 Issue、私有仓库读取和公共 PR 写入的组合；建议验证只使用 public-fixture-repo、private-fixture-repo 和内部模拟 PR 目标，私有文件内容使用无敏感性的固定标记。分析材料应包括 Issue 内容、用户授权范围、工具调用顺序、读取对象、发布目标和最终公开状态。[R15]

先把对象对应起来。 这里至少有四个对象：攻击者可以写入的公开仓库 public-repo，用户自己拥有的私有仓库 private-repo，连接 GitHub MCP 的本地 Agent，以及用户已经授权给 GitHub MCP 的凭证。公开披露中的“私有仓库”是 GitHub 上的私有仓库，不等于 Agent 直接读取 D:\ 盘上的本地代码；只有系统另外开放了本地文件工具时，才会出现本地文件读取这一条路径。

攻击者做的事情也不必是上传脚本或破解 GitHub。只要公开仓库允许外部用户创建 Issue，攻击者就可以把一段面向 Agent 的文本写入 Issue。Issue 被返回后，模型可能把这段文本误认为用户的新任务。公开 Issue 是入口，不是权限来源；私有仓库读取能力仍然来自用户原本授权的 GitHub 凭证。

正常基线。 用户只要求“查看公共测试仓库的 Issue，并总结问题”。预期调用是 list\_issues 和 get\_issue，不应读取 private-fixture-repo，也不应调用 create\_pull\_request。先验证这个基线，才能判断后续新增读取和公开写入到底是不是由外部 Issue 牵引。

这里的工具名称是便于读者理解的示意名称。不同版本的 GitHub MCP 可能把它们命名为 Issue 查询、Issue 读取、仓库文件读取和 Pull Request 创建等不同名称，最终应以实际 tools/list 返回的工具清单为准。判断重点不是名称，而是四种能力是否同时存在：读取公开 Issue、读取私有仓库、读取私有文件、向公开仓库写入。

脱敏重构调用轨迹。 下面的对象名和字段是验证用占位值，不是公开披露中的原始仓库名、Issue 内容或 PR 文本：

步骤	工具动作与对象	正常预期	实际风险或定位证据
1	list\_issues 读取 public-fixture-repo	只获取公共 Issue 列表	外部作者内容进入模型上下文
2	get\_issue 读取指定测试 Issue	提取标题和正文供总结	正文被解释成后续任务的控制输入
3	私有仓库读取工具访问 private-fixture-repo	原任务没有授权，策略应拒绝	若成功，说明公共输入扩大了已有私有读取能力
4	get\_file 读取私有测试文件	只允许明确授权的对象	记录文件 ID、ACL、来源标签和返回状态
5	create\_pull\_request 指向内部模拟目标	原任务不应发布 PR	若策略只看“创建 PR”权限，可能放行私有来源到公共目标
6	检查模拟 PR 内容与可见性	应无私有测试标记或应被阻断	只有目标状态确认后才能认定发生数据外流

故障定位。 第一个边界问题在第 2 步：get\_issue 返回内容被当作控制输入；第二个在第 3 步：公共 Issue 的来源没有约束后续私有读取；第三个在第 5 步：执行器没有检查“私有来源到公共目标”的数据流。权限反证必须分别跑：去掉私有读取权限，链路应在第 3 步停止；去掉公共写入能力，即使读取成功也不能进入 PR。这样才能证明问题是能力组合和数据流控制，而不是 GitHub ACL 被绕过。

用普通话描述这条异常轨迹，就是：用户只让 Agent 看公开 Issue；Issue 正文让 Agent 去看私有仓库；Agent 读取了用户本来就能访问的私有文件；随后又把测试内容写进了公开 PR。这里没有“Issue 直接读取私有仓库”这一步，真正发生的是模型把 Issue 内容转换成了后续工具调用。

修复与回归。 公共 Issue 总结任务只开放指定公共仓库的只读能力；私有读取和公共发布使用不同的凭证、不同的审批域和不同的执行器。发布前检查每个字段的来源标签、目标可见性和任务授权摘要。回归必须同时验证正常总结仍完成、私有读取被拒绝、公共 PR 创建被拒绝，以及只读结果不会自动扩大下一步工具范围。

人工复核重点。 逐项核对用户原始授权、Issue 作者、私有文件 ACL、模型提议、执行器拒绝理由和模拟 PR 最终状态。不能把“用户本来就有私有读取权”写成“平台权限绕过”，也不能把单个公开案例的路径外推成所有 GitHub MCP 部署的必然结果。

安全验证的最小例子。 在私有测试仓库中只放置 PRIVATE\_FIXTURE\_CANARY\_001 这样的无敏感测试标记，在公开测试仓库中创建一条测试 Issue，要求系统只总结 Issue。安全系统应在读取 Issue 后停止；如果日志出现“读取私有测试文件—创建公开模拟 PR—PR 中出现测试标记”，就能证明私有来源到公共目标的策略失效。这个方法不需要真实隐私数据，也不需要把结果发布到真实公开仓库。

案例四：固定计划中的收件人与文件参数被污染

材料与边界。 CaMeL 论文用受控任务说明，即便先固定了“读取材料、提取字段、发送结果”的计划，外部材料仍可能影响文件名或收件人等参数。这里的证据是论文中的双模型参数操纵反例、值来源传播和策略约束设计，而不是某家企业已发生的邮件泄露事件。下表使用 example.invalid 地址、测试云盘对象和记录型发送工具，属于论文机制的脱敏验证设计，不是论文原始运行日志。[R10]

正常基线。 用户要求：“把上次测试会议中 Bob 要的文件发送给 Bob，邮箱和文件名在会议记录里。”会议记录、联系人目录和云盘都使用测试对象。预期计划是查找会议记录、提取已授权联系人和文件引用、读取对应测试文件、向允许的测试联系人发送；每一步都要保存来源和对象 ID。

用一个简单比喻理解这个案例：计划像一条固定的流水线，“先读会议记录，再找文件，最后发邮件”；污染没有改变流水线的顺序，而是把流水线中的“收件人”和“文件”两个标签换掉了。即使邮箱格式正确、文件 ID 格式正确，也不能说明它们就是用户要求的收件人和文件。

固定计划下的调用轨迹。 这里最关键的对照是：动作顺序不变，只改变会议记录里可被抽取的候选值。

步骤	工具动作与候选值	应记录的证据	失败或阻断位置
1	搜索测试会议记录 meeting-fixture-A	记录对象 ID、作者、时间和原始文本哈希	只证明材料被读取，不授权其中所有文本
2	受限提取返回收件人和文件引用	正常值、候选值、字段来源片段和置信状态	若自由文本直接成为参数，数据流边界缺失
3	get\_file 读取云盘对象	文件 ID、ACL、来源标签和任务授权	仅凭文件名字符串不能证明对象获授权
4	send\_email 使用固定计划发送	收件人、文件 ID、来源映射和审批绑定	发送前必须同时检查来源、对象和接收者
5	记录型工具返回结果	发送记录 ID、状态和目标可见性	没有目标状态证据，不能认定已外发

字段级对照。

字段	正常测试值	污染后候选值	执行器应检查
meeting\_note	meeting-fixture-A	同一记录中的外部作者文本	来源对象和可处理范围
recipient	[email protected]	记录文本中出现但未在联系人 allowlist 的地址	联系人授权与任务目的
document\_ref	drive://fixture/approved-report	外部文本声称的其他对象引用	云盘 ACL、对象标签和用户授权
send\_email	按计划调用	不应因格式正确而自动放行	来源标签、接收者和文件对象的组合策略

故障定位。 控制流没有变化，send\_email 仍按原计划出现；变化的是 recipient 和 document\_ref 的数据来源。如果执行器只检查邮箱格式、文件 ID 格式和令牌有效性，就可能把“类型正确”误当成“目的合法”。CaMeL 的价值正在于把值来源、能力标签和策略检查带入发送前决策；它不是消除所有注入风险的万能方案。

修复与回归。 提取组件只返回受限对象引用和来源 ID，发送组件只接受已授权的对象 ID 与联系人集合，不接受任意自由文本。重新运行正常会议记录、候选值变化、撤掉文件读取权限和撤掉发送能力四组条件：正常任务应保留效用；值变化应在发送前被拒绝或要求重新确认；撤权后应在对应步骤停止。人工复核原始记录、抽取值、来源映射、文件 ACL、接收者授权和最终发送状态。

结论边界。 这是论文中的受控机制反例，证明固定计划不能替代数据流授权；它不证明某个企业已经发生邮件泄露，也不证明所有双模型架构都会出现相同结果。报告必须把“参数候选被改变”“发送调用被提出”“策略是否允许”和“目标状态是否改变”分开记录。

五、从提示到外部后果还差哪些条件

读取、发送、修改和执行不是同一种后果

风险分析必须按动作类型分级。读取公共资料和读取私有资料的影响不同；把内容写入内部草稿和发送到外部地址不同；修改测试仓库和修改生产配置不同；模型生成命令文本与命令真正进入 Shell 或其他解释器更不是一回事。OWASP LLM05 对输出进入下游解释器的风险单独分类，就是为了避免把“模型输出危险字符串”直接等同于“代码已经执行”。[R18]

后果层级	需要确认的事实	不能直接推断的结论
文本层	模型是否输出了不当建议	不等于工具被调用
提议层	是否生成了工具名和参数	不等于执行器批准
执行层	策略是否允许，工具是否返回成功	不等于外部对象已经改变
状态层	目标系统是否出现可观测变化	不等于影响范围已被完整确认
影响层	数据是否到达未授权接收者，状态是否造成业务损失	不能只依据模型自述定级

在报告中，建议把结论写成“线索、证据、根因、影响、修复建议、反证”六种状态。比如“模型曾提出读取私有仓库”是提议证据；“执行器拒绝，因为对象不在任务范围”是反证；“公共 PR 已包含私有文件片段”才是外部状态证据。这样既能避免低估，也能避免把模型输出夸大成真实泄露。

需要一条可回放的证据链

一条合格的证据链至少应包含：任务授权摘要、材料来源和作者、工具定义版本、模型输入摘要、模型调用提议、结构校验结果、权限策略决定、审批绑定、工具返回、目标系统状态和最终回归结果。每一段都应有时间、版本或关联 ID，敏感内容按最小必要原则脱敏存储。

这条链路的价值不只是追责。它能回答“哪一个入口改变了哪一个字段”“策略在哪一步被绕过或缺失”“如果撤掉某个权限，后果是否还存在”。没有这些记录，防御团队只能反复猜测模型行为，无法判断应该改提示、改工具、改凭证、改数据流策略还是改业务流程。

六、防御应当落在数据与权限交汇处

第一优先级：先约束可做的事

最小权限是执行层的第一道闸门。按任务限定可用动作、对象范围、数据接收者和操作额度；把读取、发送、发布、删除、付款和配置修改拆成不同能力；让每个能力使用尽量短时、尽量窄的凭证。外部文字不能自行扩大令牌范围，模型也不能通过自述“用户已经批准”来替代执行器的授权检查。[R01][R02][R17]

对象级授权必须比工具级白名单更细。白名单回答“能否调用邮件工具”，对象策略回答“能否把这份文件发送给这个收件人”。公共仓库与私有仓库、内部邮箱与外部邮箱、测试环境与生产环境都应有显式分区。对于高影响动作，批准记录要绑定实际对象和关键参数，参数改变后重新确认。

第二优先级：控制数据流和接收者

数据流策略直接解决跨工具传播：来源是什么，数据属于哪个对象，准备流向哪个接收者，动作是否属于原始任务。策略判断需要使用执行器掌握的身份、ACL、对象标签和目的地信息，不能只读取模型解释或自然语言理由。

对“读取私有文件并发布到公共目标”“读取聊天记录并发给新联系人”“读取内部工单并修改生产配置”等组合，应当默认进入更严格的审批或拒绝路径。即使每个单独动作都允许，组合后的数据流也可能不允许。Simon Willison 提出的“私有数据、不可信内容、外部通信”三项能力组合适合作为工程提醒，但它不是形式化定理，也不是所有风险的充要条件。[R20]

第三优先级：隔离上下文并保留来源

不可信材料处理组件只拿到必要的只读工具；规划组件尽量不直接读取原始自由文本；执行组件只接受受限枚举、对象引用和已验证的数值。摘要和任务交接要保存来源编号与信任级别，避免把上游模型的结论包装成“系统指令”。

CaMeL 和设计模式研究说明，固定动作计划、双模型、Map-Reduce、代码计划和上下文最小化各有保护范围。先规划再执行可以限制新增动作，却仍需验证污染参数；双模型减少权限暴露，却不能自动证明下游值可信；Map-Reduce 适合并行处理材料，却不能免除结果真实性检查。设计模式应根据数据流和副作用选择，而不是按名词数量堆叠。[R10][R11]

第四优先级：把批准、执行和审计分开

审批界面应展示真实工具、真实对象、关键参数、数据来源、目标接收者和副作用，而不是只展示模型生成的自然语言解释。批准要与这一次调用绑定，工具名、对象、参数或目标改变就失效。执行后还要记录实际状态，区分“用户批准”“策略允许”“工具返回成功”和“目标系统已改变”。

日志至少记录 trace\_id、任务授权摘要、材料来源编号、工具定义版本、调用名称、对象标识、参数摘要、策略决定及理由、审批绑定、返回状态和副作用状态。日志本身也可能包含私有材料，应该分级存储、脱敏和限权访问。审计的目的不是把所有模型思考永久保存，而是让关键安全事实可回放。

图四 把约束放在工具执行之前

图四的核心不是增加一个“更聪明的提示词”，而是让执行策略掌握模型无法自行声明的事实：主体是谁、对象属于谁、数据要流向哪里、动作是否获得批准。来源提示、内容检测和注入分类器可以作为辅助信号，但不能替代权限和数据流闸门。[R12][R19]

七、如何做一次受控验证

验证目标是边界，不是尝试生产攻击

测试应在独立工作区完成，使用模拟邮箱、虚构仓库、测试消息、合成文档和不会对外发布的记录型工具。不要复用生产凭证，不要连接真实收件人、支付系统或敏感仓库。安全验证的目标是确认数据流、权限和阻断点，不是对真实目标施加影响。

先建立无污染基线：固定模型版本、系统配置、工具定义、任务数据、凭证范围、采样设置和调用预算，记录正常任务完成率、工具集合、对象范围和最终状态。再一次只改变一个入口：工具描述、工具返回、摘要交接、检索命中或记忆条目。每组测试都要比较模型提议、策略决定和真实执行，不能只看最终回答。[R05][R06][R07]

八组验证项和判定方式

验证项	只改变什么	需要记录什么	结论边界
正常任务基线	无污染材料	工具、对象、状态、耗时	只证明基线条件下任务成立
描述影响	一个工具的描述或版本	上下文快照、提议差异	说明元数据是否影响决策，不等于真实副作用
返回内容影响	可信工具携带外部作者内容	来源、字段传播、后续调用	说明业务内容是否成为控制输入
固定计划参数	计划不变，提取值来源变化	文件、收件人、对象引用	说明数据流策略是否检查参数来源
摘要交接	原始材料经摘要进入下游	摘要版本、来源映射、下游输入	说明摘要是否丢失信任边界
检索与记忆	单任务与后续任务的状态	写入者、有效期、召回和撤销	说明污染是否被持久化
审批变化	批准后修改对象或关键参数	批准绑定、重新确认和执行结果	说明批准是否会被复用
权限反证	移除私有读取或外部发布能力	阻断位置、拒绝理由、任务效用	说明真实闸门在哪里，不等于模型未受影响

权限反证是最容易被忽略但最有价值的一项。若移除私有读取权限后，Agent 仍能生成类似建议，但无法获得私有内容，说明模型层和执行层的结果不同；若移除外部发布能力后，数据只能停留在内部草稿，说明出口权限发挥了作用。报告应分别写出“模型受到影响”“不当动作被提出”“执行被阻断”和“外部状态改变”，不能把它们合成一个布尔值。

图五 先证明正常任务 再核验污染条件

指标要绑定分母和实际执行

建议至少报告：正常任务完成率、污染条件下的安全完成率、不当动作提议率、实际执行率、误拦截率、额外延迟和残余风险。AgentDojo 的任务效用、攻击下效用和定向攻击成功率提供了评测思路；企业工程测试还应增加“提议与执行分离”的观测。[R06]

所有指标都要写清测试任务、攻击者能力、模型版本、重复次数、调用预算、成功判定和分母。不能把论文中一个限定场景的成功率当成生产风险概率，也不能用“一次没有成功”证明系统不会受注入。若报告使用 MSB 等 MCP 专项研究，应同时写明研究版本、工具集合和威胁模型；公开资料里标注的会议收录状态也应按作者声明与独立确认分别表达。[R09]

工具怎么选：每个工具都要有明确职责

工具或研究框架	输入和输出	适合解决什么问题	不能证明什么
AgentDojo	任务、工具环境、污染条件；输出轨迹、效用和安全判定	做可重复的 Agent 任务对照评测	不代表企业全部工具和权限
InjecAgent	工具上下文和间接注入测试项；输出评测结果	比较工具集成 Agent 的间接注入表现	不等于真实生产权限复现
ASB	多入口攻击和防御设置；输出攻击、防御与效用指标	补充输入、工具、记忆等不同入口	不同攻击者能力不能混算
ToolEmu	工具规格和任务场景；输出模拟风险轨迹	工具尚未接入时预演高风险动作	模拟结果需要隔离环境确认
MSB	MCP 工具及不同阶段的测试设置；输出专项评测结果	分析工具名称、描述、参数、响应等入口	不代表所有 MCP 部署
Snyk Agent Scan	Agent 组件配置和元数据；输出组件风险分析	做接入前的组件和描述检查	不是运行时授权或副作用证明

工具选择的重点不是“越多越专业”，而是每个工具的输入、输出和盲区都能与验证项对应。AgentDojo 适合评估任务与工具轨迹，ToolEmu 适合没有真实工具时的模拟，扫描器适合接入审查；它们都不能替代真实执行端的权限检查。Snyk Agent Scan 的 README 还提示，发现组件时可能启动配置中的 stdio 服务器或访问远程端点，所以审查陌生配置本身也应放在隔离环境，不能把安全扫描器当成无副作用的读取器。[R21][R22]

六步实施顺序

1. 画出一条真实工作流的数据来源、工具能力、执行账户、对象权限、接收者和外部出口，先找跨源读取与发布的组合。
2. 为任务定义允许动作和对象，例如整理公共 Issue 时只开放指定公共仓库，不同时开放不相关的私有仓库读取和公开发布。
3. 为工具定义、返回内容、摘要和记忆记录来源、版本、作者和有效期；新服务器、描述变化和权限变化进入接入审核。
4. 在执行器前放置策略层，验证身份、对象、来源、目的地、额度和审批绑定；拒绝理由应能回链到确定性策略。
5. 在模拟环境运行八组验证，先做正常基线，再做单入口变化和权限反证，分别记录提议、允许、执行和状态。
6. 将确认的问题转为权限调整、数据流规则、界面修复或工具设计修改，重测原失败场景和正常基线，并保存残余风险。

八、读者最容易误解的八个问题

使用 OAuth 就不会受提示注入影响吗

不会。OAuth 解决的是令牌和受委托访问的一部分问题，不能自动判断外部文档、消息或 Issue 是否有权改变当前任务。凭证授权、内容来源和任务目的必须分别审核。[R02][R15]

使用官方工具就不必验证结果吗

仍然需要。可信服务器可能正确返回第三方作者写入的内容，服务器身份不能替代内容作者和业务目的校验。官方工具可以降低实现来源的不确定性，但不能证明每个参数和数据流都符合本次任务。[R01][R15]

Schema 严格限制是不是就安全了

不是。Schema 能约束字段和类型，不能单独证明收件人、文件、仓库或查询条件符合授权目的。结构合规与业务授权是两个判断。[R01][R10]

没有调用恶意工具就安全了吗

不一定。只要恶意描述被提供给模型，元数据就可能影响其他工具的决策；但是否形成真实副作用，仍要看工具可达性、策略和权限。[R13][R14]

双模型能完全隔离污染吗

不能这样保证。双模型可以缩小单个组件的权限和上下文，但自由文本仍可能通过参数、摘要或异常通道影响下游。真正的保护取决于值来源、允许接收者和执行策略是否同时受约束。[R10][R11]

固定工具列表能解决所有跨工具问题吗

不能。固定列表能减少可调用动作，但如果列表中同时存在私有读取和外部发布能力，仍需要对象范围、数据流和接收者策略。工具白名单不是完整的业务授权模型。[R06][R17]

安全扫描器误报很低就够了吗

不够。还要观察漏报、任务效用、实际执行、权限阻断、额外延迟和日志完整性。扫描器适合发现线索，不能替代受控运行时验证。[R21][R22]

论文里的攻击成功率可以当成企业风险概率吗

不可以直接这样用。任务分布、工具集合、模型版本、攻击者能力、测试预算和执行权限不同，论文结果只支撑其限定设置。企业应把公开基准当作方法参考，再用私有工作流和权限反证完成验收。[R05][R06][R08][R09]

工具调用的安全边界最终落在一句很朴素的话上：模型可以提出动作，但不能自己定义授权；工具可以返回内容，但内容不能自动变成指令；执行器可以提高自动化程度，但必须知道动作涉及谁、哪个对象、流向哪里以及后果是什么。把这条链路记录完整，才有可能把“模型被影响”进一步判断为“动作被阻断”或“外部状态真的改变”。

专业术语注释

• LLM：大语言模型；本文中负责理解上下文和生成调用提议，不等同于执行器。
• Agent：智能体；把模型推理、工具调用、状态处理和外部系统连接起来的应用系统。
• MCP：模型上下文协议；用于发现、描述、调用外部工具并传递结果的协议。
• tools/list：MCP 中用于获取服务器工具清单的请求；返回工具名称、描述和输入 Schema，不等于执行这些工具。
• Prompt Injection：提示注入；不可信输入使模型偏离预定任务或约束的风险。
• IPI：间接提示注入；攻击内容通过网页、消息、Issue 或工具结果等间接来源进入模型上下文。
• Tool Poisoning：工具投毒；在工具描述、参数说明或相关元数据中加入误导性内容，影响后续调用决策。
• Schema：结构约束；描述字段、类型和格式，不能自动判断业务授权。
• ACL：访问控制列表；规定主体可以访问哪些对象或执行哪些操作。
• OAuth：授权框架；用于管理受委托访问令牌和授权流程，不替代任务目的校验。
• RAG：检索增强生成；将外部检索材料加入生成过程，不等于材料可信或有权指令。
• Provenance：来源记录；标识数据来自何处、由谁提供以及经过了哪些转换。
• CaMeL：面向 Agent 的能力与数据流约束方法；通过隔离、来源追踪和策略减少不当传播。
• ASR：攻击成功率；必须同时说明攻击目标、分母、预算和实际成功判定。
• ASB：Agent Security Bench；面向基于大模型 Agent 的攻击与防御评测框架。
• MSB：MCP Security Bench；面向 MCP 工具调用不同阶段的安全评测研究。
• AgentDojo：Agent 提示注入评测环境；提供任务、工具、攻击目标和执行轨迹。
• InjecAgent：间接提示注入评测基准；用于评估工具集成 Agent 的间接注入风险。
• ToolEmu：工具环境模拟框架；用模拟工具状态和响应预演潜在执行风险。
• Spotlighting：不可信来源突出标记方法；帮助模型识别来源，不能替代执行端授权。
• Prompt-to-Anything：本文的解释性概括；指提示影响经模型变成工具调用并最终形成外部动作，不是已确认的标准名称或漏洞编号。
• PR：Pull Request，合并请求；GitHub 中提出代码或内容变更的记录，也可能成为公开数据出口。
• Issue：问题记录；用户或外部作者提交的讨论材料，不是自动具备系统指令权的消息。
• JSON：JavaScript 对象表示法；结构化数据格式，不能保证字段和值可信。
• stdio：标准输入输出；本地 MCP 服务器通过进程输入输出通信的方式，启动时可能执行配置中的命令。
• Shell：命令解释器；只有模型输出到达可执行入口并按相应规则运行，才会形成命令执行后果。
• RCE：远程代码执行；必须有实际执行入口和执行证据，不能仅凭模型文本认定。

参考资料

[R01] MCP Tools

官方规范；规范版本 2025-11-25。支持：调用生命周期、description、inputSchema、structuredContent；区分 MUST 与 SHOULD。

[R02] MCP Security Best Practices

官方规范；规范版本 2025-11-25。支持：授权与语义注入是不同边界；本地执行与最小权限。

[R03] Tool use with Claude

厂商官方文档；2026-10-02 核对的动态文档。支持：模型生成调用结构；执行发生在应用或服务端，而不是文本自动执行。

[R04] Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection

原始论文；2023-02-23 首发；arXiv v2 2023-05-05。支持：间接注入的历史与外部内容成为控制输入。

[R05] InjecAgent: Benchmarking Indirect Prompt Injections in Tool-Integrated Large Language Model Agents

会议 Findings 论文；ACL 2024 Findings；2024-08。支持：1,054 测试项、17 用户工具、62 攻击者工具；受控研究结果不外推生产。

[R06] AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents

顶会基准赛道论文；NeurIPS 2024 Datasets and Benchmarks Track；arXiv v3 2024-11-24。支持：97 任务、629 安全测试项；任务效用、攻击下效用、定向攻击成功率。

[R07] Identifying the Risks of LM Agents with an LM-Emulated Sandbox

顶会主会论文；ICLR 2024 Conference。支持：ToolEmu 用于风险场景预演；不是专门的跨工具提示注入真实执行评测。

[R08] Agent Security Bench (ASB): Formalizing and Benchmarking Attacks and Defenses in LLM-based Agents

顶会主会论文；ICLR 2025 Conference。支持：覆盖输入、工具和记忆；不同实验攻击者能力不同，不得混算。

[R09] MCP Security Bench (MSB): Benchmarking Attacks Against Model Context Protocol in LLM Agents

已读原始研究，收录状态有保留；arXiv v2 2026-03-24；作者备注 Accepted by ICLR 2026，会议官网尚未独立确认。支持：工具名称、描述、参数、响应和检索入口；304 良性工具 + 405 攻击工具 = 709 总工具；模型数量口径待对齐。

[R10] Defeating Prompt Injections by Design

原始防御论文；arXiv v2 2025-06-24。支持：CaMeL 的控制与数据流隔离、来源传播、工具调用策略；不声称全面解决注入。

[R11] Design Patterns for Securing LLM Agents against Prompt Injections

原始架构研究；arXiv v3 2025-06-27。支持：固定动作、先规划再执行、Map-Reduce、双模型、代码计划、上下文最小化的不同保证。

[R12] Defending Against Indirect Prompt Injection Attacks With Spotlighting

原始防御研究；arXiv v1 2024-03-20。支持：输入来源标记降低误服从概率；不能当作确定性授权机制。

[R13] MCP Security Notification: Tool Poisoning Attacks

原始研究披露；2025-04-01。支持：未调用的恶意工具描述影响可信邮件工具；实验而非全产品现状。

[R14] WhatsApp MCP Exploited: Exfiltrating your message history via MCP

原始研究披露；2025-04-07；正文 2025-04-09 补实验二。支持：恶意服务器元数据与恶意消息返回内容是两种入口；没有破解端到端加密。[R15] GitHub MCP Exploited: Accessing private repositories via MCP

原始研究披露；2025-05-26。支持：公共 Issue -> 私有仓库读取 -> 公共 PR；用户令牌已有权限，无须平台 ACL 绕过。

[R16] OWASP LLM01:2025 Prompt Injection

安全风险指南；2025 分类；2026-10-02 核对。支持：注入类别、影响与防护；风险分类不证明具体产品受影响。

[R17] OWASP LLM06:2025 Excessive Agency

安全风险指南；2025 分类；2026-10-02 核对。支持：权限和自主程度决定注入后果。

[R18] OWASP LLM05:2025 Improper Output Handling

安全风险指南；2025 分类；2026-10-02 核对。支持：模型输出进入解释器、浏览器、数据库等执行点时必须验证。

[R19] Prompt injection is not SQL injection it may be worse

国家安全机构技术分析；NCSC 2025-12-08。支持：不能照搬 SQL 参数化为语义注入万能解；外部确定性约束优先。

[R20] The lethal trifecta for AI agents private data untrusted content and external communication

资深工程师分析，非标准非定理；2025-06-16。支持：三能力组合用于直观解释；不是一切 Agent 风险的充要条件。

[R21] AgentDojo official repository README

官方开源项目；2026-10-02 核对。支持：工具执行轨迹和可扩展任务评测；实际采用须固定代码版本。

[R22] Snyk Agent Scan official repository README

官方开源项目；2026-10-02 核对；README 版本锚点 b4cda5cdb8f7f9ce52ded6a3a377cfe0fa368dcb。支持：旧 MCP-Scan 仓库指向 Agent Scan；扫描会启动 stdio 服务器或访问远程端点，并非无副作用纯静态操作。

---