Plugin4Shell 与 NIST IR 8587：仅相隔数日，究竟谁授权了AI代理的行为？

两件事在几天内相继发生，共同勾勒出一个我反复遇到的差距。Plugin4Shell（由AIR Security于9月17日披露）是一个零点击RCE，影响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得到充分解决，意味着我们看到的主要是部署和执行失败？还是在代理拥有访问权与代理被授权行动之间仍然缺少一个执行原语？