AI代理能访问你的代码，不等于有权动它

两件事在几天内接连发生，合在一起勾勒出我反复遇到的一个空白。

Plugin4Shell（AIR Security，9月17日披露）是一个零点击远程代码执行漏洞，影响 Claude Code、Codex、GitHub Copilot 和 Gemini CLI。其机制简单得近乎无聊：市场将插件固定在一个经过审查的40位十六进制提交SHA上，代理针对该SHA执行git checkout，然后从不验证工作树是否真的落在了该提交上。控制插件仓库的攻击者可以创建一个与固定SHA完全同名的分支，并将其设为默认分支。当该名称既是有效引用又是对象ID时，git优先选择引用，于是checkout落在攻击者控制的代码上，而固定似乎仍然有效。

修复也同样简单：在checkout后解析HEAD，若不匹配固定提交则中止。Anthropic 在 Claude Code 2.1.179 中发布了修复，OpenAI 在 Codex 0.146.0 中发布了修复。披露时，GitHub Copilot 尚无修复，而 Google 表示不会修补已弃用的 Gemini CLI。

严格来说，这是一个供应链完整性问题，而非授权问题。它在此处相关的原因是爆炸半径：在编码代理内部执行的恶意代码可以访问该环境可用的资源，包括源代码、云凭证、SSH密钥、内部仓库和生产系统。

NIST IR 8587 于9月15日定稿，由 CISA 的 JCDC 联合制定，提供了保护身份和访问令牌免受伪造、窃取和滥用的指南。它涵盖的控件包括密钥管理、受众限制、更短的令牌生命周期、加密绑定、撤销和持续访问信号。但有两个范围边界对代理系统很重要：API密钥明确不在其令牌模型之内，并且AI代理所采取行动的授权未得到全面解决。

NIST 正通过一个 NCCoE 项目分别研究代理身份和授权，探索现有身份与授权机制如何应用于软件和AI代理。但这项工作仍处于概念/项目阶段，而非最终的实施指南。

IDC 的 Yih Khai Wong 在 CSO 对 IR 8587 的分析中更直接地指出了根本问题：“令牌加固假定令牌持有者是已知、有界的参与者。”代理系统使这一假设变得复杂。

有效凭证可以确立身份或授予对系统的访问权。它不一定能确立：在当前策略下，针对这个目标的这个操作已获授权。对于敏感操作，我希望在执行前知道谁授权的、具体授权了什么、授权覆盖哪个目标、是否仍然有效，以及实际执行的操作是否与授权内容匹配。

执行之后，我还希望有一个独立系统能够重建该操作被允许的原因，而不必信任代理对自身的描述。

这个问题能否通过正确实施 IAM/PDP/PEP 得到充分解决，也就是说我们看到的主要是部署和执行上的失败？

又或者，在代理拥有访问权与代理被授权行动之间，仍然缺少一种强制执行原语？

—— 高票评论（帖子共10条讨论）——

[+2] u/PLBjt：我在这里会将身份与授权分开：IAM 能告诉你代理代表哪个主体行事，但策略网关仍需要将确切的工具、参数、目标和时间窗口绑定到已批准的意图上。在执行前检查该绑定，并生成只能追加的决策记录，供独立系统重放；否则，有效凭证仍可能被用于未经授权的操作。代价是延迟和更脆弱的集成，但对于高影响工具这更可取，而低风险读取可以使用更轻量的路径。

[+2] u/Fancy-Win9202：你遇到的根本问题其实不是git checkout漏洞，而是在造成损害之前，你无法知道代理实际执行了什么。Plugin4Shell只是机制，更深的空白在于大多数代理设置对以下方面毫无可见性：哪个插件的哪个确切版本运行了，它声称了哪些权限，以及在你发现之前它接触了文件系统中的什么。你最终是否构建了某种执行审计追踪，将每个代理操作与触发它的特定插件版本和提交关联起来？还是这仍然属于“出事后再解决”的类别？

[+2] u/usually_guilty99：我认为被忽略的正是这个区别：访问不等于授权。抱歉我可能像个复读机。有效令牌告诉我代理能够触达什么，而不能告诉我在当时、当前策略下，针对这个特定目标的这个特定操作是否被批准。

下一个控制平面或许必须紧贴执行之前：操作、目标、爆炸半径、授权和预期后置条件全部绑定在一起。然后独立于代理验证结果状态。