签名但不安全：多智能体 LLM 交接中的需求完整性
Signed but Not Safe: Requirement Integrity in Multi-Agent LLM Handoffs
论文速读
据论文全文整理（AI 生成），以原文为准
论文提出签名需求清单（signed requirement manifest）的多智能体 LLM 交接方案，并在可精确评分的合成任务上比较自由文本、结构化 JSON 与签名清单三种交接形式。
- 企业多智能体流水线中，用户需求经 orchestrator、subagent、merger 多次转手，可能被摘要丢失、被中间 agent 改写、被间接 prompt injection 篡改或被 merger 忽略，最终提交违反原始需求的决策。作者要区分两类失败：无对抗的丢失（loss）与蓄意篡改（tampering），并比较不同 handoff 形式的防护效果。
- 作者用合成、可精确打分的任务做预注册对照实验，比较自由文本摘要、结构化 JSON、以及 signed requirement manifest 三种 handoff。manifest 由 orchestrator 把每条需求抽成原文引用加可执行 predicate，由可信代码做 provenance 过滤、规范化并用 HMAC-SHA256 签名，merger 的决策由确定性代码而非 LLM 校验；另设 unsigned manifest、LLM checker 和 oracle manifest 对照。
- Qwen3-8B 上，攻击下 signed manifest 把 unsafe commit 从结构化 handoff 的 69.4% 降到 9.0%，且 conformant commit 无净损失；签名专门挡住传输中篡改（unsigned 79% 违规，signed 0%）。同一轨迹上确定性 verifier 比 LLM checker 检出更多违规、误报更少。剩余风险全部来自签名前的抽取错误；预注册的 pre-signing injection 使各模型 signed manifest 违规率大幅上升，且全部源于签名前已被污染的 manifest。gpt-oss-20b 上收益仅来自抗篡改，抽取失败还带来效用损失。
- 仅两个确认性模型家族，第二个在缩减 cut 上运行且无 pilot；任务为合成、有限域、可写成 predicate 的需求，只有单一两分支拓扑和固定五种威胁脚本；假设 orchestrator 与 harness 可信。作者指出抽取步骤是信任边界，签名只保护传输、不保护抽取，需从认证输入抽取或签名前让用户确认 manifest；更强模型上良性条件下的收益消失，只剩抗篡改。
论文提出签名需求清单（signed requirement manifest）的多智能体 LLM 交接方案，并在可精确评分的合成任务上比较自由文本、结构化 JSON 与签名清单三种交接形式。Qwen3-8B 上，签名清单把攻击下的不安全提交从结构化交接的 69.4% 降到 9.0%；在传输中篡改场景，未签名清单在 79.2% 的篡改运行中提交违规，签名清单为 0%。同一批轨迹上，确定性校验器检出 78.7% 的违规决策，LLM 校验器为 59.0%，误报率分别为 7% 和 50%。剩余 11.2 个百分点的风险来自签名前的需求提取错误；预注册的签名前注入把签名清单违规率从 14.6% 升到 37.5%（Qwen3-8B），论文据此指出提取步骤才是信任边界。第二家族 gpt-oss-20b 的支持主要来自抗篡改，提取失败在 22% 的任务中带来效用损失。
推荐理由论文把多智能体交接中的需求丢失与传输篡改分开测量，并指出签名只保护签名之后的环节，提取阶段仍是信任边界。