外观
能力门控不是授权：LLM Agent 框架中的混淆代理失效
摘要
本文区分工具能力门控（capability gating）和真正的逐调用、逐参数授权。作者审计 LangChain/LangGraph、LlamaIndex 和 Stripe Agent Toolkit 的公开固定版本，发现默认工具分发可以暴露能力，却不等于在动作边界执行 fail-closed 授权。论文提出 ScopeGate，将 scope、授权、金额上限、幂等性和默认拒绝固定到可信的策略执行点。
在 mocked、不可路由的副作用接收端上，ScopeGate 拒绝了 48/48 静态绕过和 29/29 自适应未授权尝试，并报告 10/10 Latam-GPT containment 与 0/10 benign false-deny。结果是受限测试环境中的控制证据，不是现实支付 breach 率，也不证明 prompt injection 已被治愈。
核心创新与差异
原研究贡献：论文通过跨框架审计和可运行测试说明，工具是否被暴露、工具 Schema 是否存在，与某一次调用是否获得授权是不同控制。ScopeGate 把授权检查移到模型输出之后、工具副作用之前，并将 scope、金额上限、幂等性和 default deny 作为动作边界的确定性条件。
本站分析：本文新增的是 confused-deputy 失效的跨框架一手证据和可运行的控制对照。最先失效的控制是把 capability exposure 或 Schema 当成授权；主要修复责任在框架集成者和确定性策略执行层，而不是要求模型独自判断是否有权执行动作。
威胁模型与攻击链
攻击者控制检索文档、网页、邮件、工具输出或 Agent handoff 中的内容，但不修改 Agent 代码。攻击者的目标是诱使模型提出带有攻击者参数的工具调用，例如未授权 payout。被保护资产包括付款、退款、凭据、外联和基础设施副作用。
信任边界位于模型生成的 tool_call 与可信策略决策点/策略执行点（Policy Decision Point/Policy Enforcement Point, PDP/PEP）之间。攻击链是：不可信内容进入模型上下文；模型把其中的指令转成工具调用和参数；框架的 capability gate 仅确认工具可用。如果没有逐调用、逐参数的 fail-closed 授权，执行层就可能接受超出用户授权的动作。ScopeGate 在动作真正发出前重新检查授权和参数条件。
实验设计与实际过程
作者审计：研究固定了三个框架的公开 pinned commits，检查默认 dispatch 是否能执行同样的未授权 payout。随后在 ScopeGate 上执行静态绕过、自适应未授权尝试、Latam-GPT containment 和 benign false-deny 测试，并加入 NaN、类型混淆、工具名和幂等性边界条件。
所有副作用接收端均为 mocked、不可路由的 sinks，没有真实支付或第三方攻击。论文公开代码和 run_proof.sh；本页未执行独立复现，以下数字均为作者实验。论文将 ASR 作为尝试率使用，不能把它解释为真实 breach 率。
关键结果与实际影响
- 三个框架的默认 capability gating 未提供逐调用、逐参数值的 fail-closed authorization；默认 dispatch 可以执行相同的未授权 payout。
- ScopeGate 拒绝静态绕过 48/48、自适应未授权尝试 29/29，并在 Latam-GPT containment 测试中报告 10/10。
- benign false-deny 测试为 0/10，说明在该小规模测试中没有观察到良性请求被拒绝；这不是一般部署中的误拒率估计。
- 测试覆盖 NaN、类型混淆、工具名和幂等性等动作边界，实际影响是把授权责任从可能被诱导的模型输出移到可信的确定性执行点。
这些结果证明的是 mocked sinks 和有限攻击预算下的控制行为。它们不能证明任意框架、任意工具或真实支付系统都存在同样的可利用缺陷，也不能证明上游 prompt injection 风险已经消失。
Recognition Without Enforcement补充了识别与执行之间的实证差距：模型能够识别伪造权威或指令冲突，并不保证在当前 Harness 配置下拒绝对应动作；作者还比较了不同配置和外部引用监控器。该增量可被反驳地表述为“相同输入的拒绝结果会随执行配置和是否存在模型外监控而变化”，而不是“模型完全不理解攻击”。论文为单一团队作者实验、尚无独立复现，所测模型、配置和监控器不能代表全部框架；但它进一步支持把识别信号仅作为策略输入，由可信执行点作最终授权。
防护措施与验证方法
工具集成应将 capability gating 仅作为能力发现或路由控制，另在可信 PDP/PEP 处执行逐调用、逐参数授权。策略至少应绑定 scope、当前用户授权、金额或资源上限、幂等性和 default deny；对于 NaN、类型混淆、工具名替换等输入，应在动作执行前拒绝或规范化。
验证应同时运行静态和自适应未授权尝试，并报告攻击尝试数、拒绝数、良性请求数和误拒绝数。测试环境要使用不可路由或隔离的副作用接收端，固定公开 commit、语料和迭代预算；上线前还需在真实授权模型、真实工具实现和多种内容投递路径上复测。
局限与待验证问题
- ASR 在论文中表示攻击尝试率，不是真实 breach 率；0/48 和 0/29 受测试语料与 40 次迭代预算限制。
- Stripe 的远程内部实现没有被审计，研究只覆盖选定公开版本和单一内容投递路径/单作者语料。
- mocked、不可路由 sinks 没有验证真实支付、邮件或基础设施副作用中的部署行为。
- ScopeGate 的结果不等于 prompt injection 被治愈；仍需验证多步 handoff、工具链、身份变化、重放和策略更新。
- 代码和
run_proof.sh公开，但本页没有独立复现记录；实验没有真实支付或第三方攻击，伦理风险主要通过隔离环境控制。