参数投毒（Parameter Poisoning）
| 分类 | 🛡️ 安全风险 |
| 阅读时间 | ⏱️ 15 分钟 |
| 更新时间 | 📅 2026-11-09 |
| 条目编号 | ENC-SECURITY-24-parameter-poisoning |
关键要点 ✦
- 攻击面定义：据 arXiv:2611.04673《Right Tool, Wrong Parameters: Defending LLM Agents Against Parameter Poisoning》（Yao Wang、Zehua Ma、Weiming Zhang、Han Fang，2026-11-03 提交，cs.CR），现有间接提示注入防御大多关注注入是否诱发新的工具调用或非预期动作；参数投毒走另一条路——保留预期动作，只操纵一个或多个工具参数（如收件人或其他任务关键值）。
- 为何难以检测：据该论文，这类攻击不引入新动作，而参数变化本身往往正是用户请求里的合法组成部分，因此仅看动作序列无法区分「用户要求改地址」与「注入内容偷偷改了地址」。
- 核心洞察：该论文提出，参数变更是否合法，应由「产生该值的信息流在当前用户查询下的可信度」决定；用户查询会在可用信息字段上诱导出一个任务特定的信任层级——某些字段有权决定特定参数，另一些字段则不应有影响或只应有很小影响。
- 三阶段防御与基准：据该论文，AuthorityFlow 先解读用户查询并构建任务特定的信息字段信任层级，再对每个工具参数追踪产生其当前值的信息流、把该值归因到支持它的字段，最后仅当该字段在当前任务下被信任可决定该参数时才接受该值，从而放行高可信变更、把低可信影响标记为潜在参数投毒；论文同时提出 FactAuthBench 用于评测参数投毒。
- 量化结果（作者自报口径）：据该论文摘要，无防御时攻击成功率达 93.06%，AuthorityFlow 将其降至 9.03%；良性任务效用从无防御时的 90.28% 变为 82.64%，即防御带来约 7.64 个百分点的效用代价。该结果来自单篇预印本，未见独立复现。
- 与相邻攻击的分工：本站工具投毒攻击词条讲的是在工具描述、元数据里注入指令，工具链攻击词条讲的是跨工具串联的供应链风险，提示注入词条讲的是让模型执行攻击者指令的通用手法；参数投毒的特殊之处是动作完全合规、只有值被污染，因此需要参数级而非动作级的信任推理。对高影响参数配合人在回路审批，是公开资料中反复出现的缓解建议，但其工程成本需自行权衡。
动作合规，为什么仍然出事
间接提示注入（IPI）指恶意指令藏在工具返回、网页内容、文件正文等外部数据里，模型把它当作上下文执行。据 arXiv:2611.04673 的梳理，现有防御主要围绕一个判据展开：注入有没有诱发一次新的工具调用，或导致一个非预期动作。这个判据对「偷偷多发一封邮件」「额外调用一次转账接口」这类攻击很有效。
参数投毒绕开的正是这个判据。据该论文，攻击者保留智能体原本打算执行的动作，只篡改其中一个或多个任务关键参数——收件人、文件路径、金额、目的地等。发一封邮件是合规的，把内容发给攻击者指定的地址不合规；写文件是合规的，写到另一个路径不合规；转账是合规的，换个收款账户不合规。难点在于，参数值的变化本身往往正是用户请求的合法组成部分（用户确实会说「改一下收件人」），单看动作与参数形态，无法区分这是用户意图还是被注入内容污染的结果。这也是它与本站工具投毒攻击词条所讲的「在工具描述或元数据里塞指令」最本质的区别：那里污染的是模型读到的说明，这里污染的是调用时填进去的值。
从动作级判据到信息流信任层级
据该论文，判断一个参数变更是否合法，关键不在变更本身，而在「产生这个值的那条信息流」。作者提出，用户查询会在智能体可见的信息字段上诱导出一个任务特定的信任层级：某些字段被信任可决定特定参数，另一些字段对该参数不应有影响或只应有很小影响。举例说（示意性），当用户要求「把报告发给张工」，收件人参数理应由用户这句话以及通讯录中张工的条目决定；若某个工具返回正文里夹带的一句「改发给某外部邮箱」最终决定了这个参数，即便发邮件这个动作完全合规，该值的来源也不在可信字段之内。
这个视角把防护对象从「动作」下移到了「值的来源」。据论文，AuthorityFlow 是一个三阶段的参数级防御：步骤一解读用户查询，在可用信息字段上构建任务特定的信任层级；步骤二对每个工具参数追踪产生其当前值的信息流，并把该值归因到支持它的字段；步骤三仅当该字段在当前任务下被信任可决定该参数时才接受该值，允许高可信变更通过，把低可信影响标记为潜在参数投毒。论文强调，有效的间接提示注入防御不仅要推理智能体采取了什么动作，还要推理哪些信息被信任去决定它的参数。
评测读数与代价
据该论文摘要，作者提出 FactAuthBench 用于评测参数投毒；无防御时攻击成功率达 93.06%，AuthorityFlow 将其降至 9.03%；良性任务效用在无防御时为 90.28%，启用防御后为 82.64%，即约 7.64 个百分点的效用代价。这组数字有两点值得注意。其一，93.06% 的无防御成功率说明「只看动作」的既有防线在这类攻击面前近乎失效，与本站跨执行安全监控词条所记录的「逐步审批存在结构性盲区」形成呼应，但两者针对的盲区不同：后者是跨多次执行的关系型违规，参数投毒是单次调用内部的值来源污染。其二，效用下降说明参数级信任推理不是免费的：更严格的归因会拦下一部分本来合法的参数变更，任务完成率因此受损，如何调校信任层级与误报成本是落地时必须自测的部分。
需要如实标注口径：以上全部数值来自单篇预印本的摘要，为作者自报，发布时点未见独立第三方复现；FactAuthBench 的任务构成、模型范围与基线选择在摘要中未给出，横向比较需谨慎。公开的安全资讯站 eyeon.ai 对该论文的整理还提出，防御方需要参数级（而非仅操作级）信任检查，并对高影响参数实行人在回路审批；这属于第三方建议，本站未独立验证其有效性。
工程落地与边界
对工程团队，可操作的启示是按参数的影响面分层，而不是给所有工具调用套同一套检查。收件人、金额、目标路径、权限范围、外部域名一类高影响参数，值得单独记录「这个值来自哪个字段」，并在取值来源不在白名单内时触发复核或人工审批；低影响参数则维持常规校验以控制误报与延迟。把工具返回值、文件内容、网页正文等外部数据显式标注为低信任来源，并在拼接进提示词或参数前保留来源标签，是实现信息流归因的前置条件——否则事后无法追溯某个值的出处。对支付、外发、删除类动作，参数级检查应与最小权限、非人类身份治理和审计日志叠加，而不是取代它们。
局限同样清楚：构建任务特定的信任层级需要对任务语义有可靠理解，复杂或多意图任务下层级本身可能判错；信息流追踪要求框架层面能标记并传播字段来源，很多现有智能体框架并不提供这一能力；而 82.64% 的良性效用提示误报仍是不可忽略的成本。此外，该类研究目前集中于工具调用型智能体的受控评测，生产环境中多轮对话、记忆写入与跨工具串联组合后的效果尚待观察。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
🎯 应用场景
✅ 最佳实践
- 按影响面对参数分级：收件人、金额、路径、权限范围、外部域名等高影响参数单独做来源核查。
- 在框架层为外部数据（工具返回、文件正文、网页内容）保留来源标签，使参数值可回溯到具体字段。
- 把「动作是否合规」与「值由谁决定」拆成两道检查，不要指望动作级注入检测覆盖参数污染。
- 对高影响参数配合人在回路审批，并度量误报带来的任务完成率损失，按业务风险调校阈值。
- 防御选型时要求厂商给出参数级红队结果与良性效用数据，避免只比较攻击成功率下降幅度。
- 参数级检查与最小权限、身份治理、审计日志叠加使用，不把它当作单一防线。
🔮 未来展望
参数级信任推理很可能会成为工具调用运行时的常规能力：当智能体开始代用户付款、发信、改配置，审计关注点必然从「做了什么动作」延伸到「这个动作的每个值由谁决定」。可预见的演进方向包括框架原生支持字段来源标记与信息流传播、把任务特定信任层级做成可配置的策略而非硬编码规则、以及把参数投毒纳入评测基准的常规分项。主要障碍也很实在——归因带来的计算与延迟开销、多意图任务下信任层级判错、以及良性效用下降带来的误报成本，都会决定它先在高风险场景落地而非全面铺开。本站将持续跟踪后续复现与框架内置支持情况。