保障代理身份安全

# 保护智能体身份 来源：https://codon.org.uk/~mjg59/blog/p/securing-agentic-identity/ 和许多安全行业从业者一样，过去几个月我一直在应对那些想把LLM塞进一切的人。从企业安全角度来看，这本身不是问题——真正的问题是，人们希望这些智能体能够访问日历、邮件等资源，而我们现在拥有一些非确定性的智能体，它们似乎非常热衷于完成你的指令，不管这是否是个好主意。同时，我们把能访问敏感数据的凭证交给它们，并把凭证留在磁盘上，可能被提交到git仓库，或被外泄到其他服务中去，被用来冒充智能体干各种坏事——然后你的CEO的邮件突然就人人可读，你的日子就不好过了。 正如我在上一篇文章（https://codon.org.uk/~mjg59/blog/p/preventing-token-theft/）中提到的那样，几乎所有能牢牢锁住凭证的强机制在现实世界中都不受支持。我们可以想象一个世界：智能体使用硬件（或至少是虚拟机管理程序）支持的证书来获取凭证，即使泄露也毫无价值。但遗憾的是，对于大多数使用现有身份提供商的人来说，这行不通。目前的先进做法是使用设备代码流（https://mjg59.dreamwidth.org/62175.html），由人类进行认证，然后令牌回到智能体环境中，之后它想怎么用就怎么用，你只能祈祷第二天醒来不会发生可怕的信息泄露。 （顺便说一句：我从来不喜欢、也永远不会喜欢企业环境中使用的设备代码流。身份提供商没有真正的机会检查请求令牌的系统的安全状况，因此一些身份提供商会限制以这种方式颁发的令牌。另一种常见做法是使用更标准化的流程，并将重定向URI指向localhost——这对本地系统没问题，但对远程系统来说很麻烦，即使你能用SSH转发来搞些操作。我将提议一个我认为更好的方案，你可以不同意。） 我无法让每个身份提供商和服务提供商都改变他们的安全策略，因此对他们愿意签发给我什么样的令牌，我基本上没什么选择——大多要么是JWT，要么是不透明的访问令牌，完全不支持将令牌绑定到实例的任何机制。最终必须提供给远程服务的令牌，我几乎无法控制。但这并不意味着我不能影响落入智能体环境中的令牌。我可以向智能体签发一个占位令牌，并强制它通过一个代理进行通信，这个代理会将占位符换成真实的令牌。智能体最多能做的就是外泄占位令牌——只要恶意攻击者无法访问那个代理，就无关紧要：别人拿占位令牌什么也做不了。 这个想法并不新鲜，似乎几乎每个人都自己重新发明过一遍。但许多实现涉及你提前获取真实令牌，然后把它粘贴到某个能生成占位令牌的工具中，再以某种方式提供给智能体环境——这有点笨拙麻烦，而且意味着你需要维护一个映射关系，记录占位符与真实令牌之间的对应关系——哦，我们刚发明了一个密钥存储。如果你想大规模、可靠地运行，那你刚发明了一个高可用分布式密钥存储。很多读到这儿的人现在都摇头，伸手去拿杜松子酒。我们能简化这个过程，同时提高安全性吗？我认为可以！ 还记得我说过“只要恶意攻击者无法访问那个代理，就无关紧要”吗？如果他们能访问呢？如果他们入侵了你环境中的一台机器，然后给一群员工发邮件，说服他们的智能体把更多令牌发回给自己，然后在人类读到邮件之前将其删除呢？现在你内部有了个掌握这些令牌的人，很可能也能访问代理，于是他可以冒充任何一个智能体——只要该智能体足够天真，认为把令牌发给他是个好主意。这可不妙！ 所以，我想了一会儿，想出了一个新主意。我们可以有一个代理服务来获取凭证。我们把它集中部署，远离智能体。智能体环境中的一个客户端可以请求一个令牌，这会生成一个URL，用户被导向在浏览器中打开这个URL并完成认证。当用户认证后，认证流程通过代理回传确认信息，代理得到真正的认证令牌。现在显而易见的做法是把认证令牌返回给智能体环境中的客户端，但我们不这么做。相反，我们铸造一个新的JWT，并添加一个新的声明——其中包含加密后的令牌副本。在这个过程中，我们可以复制所有原始声明，因为它们不是秘密——这样即使客户端检查令牌以了解自己有什么权限，它也能得到正确的答案。我们用自己签名密钥对新令牌签名，然后把它传回给客户端。现在客户端有了一个合法的JWT，但它完全没用——因为除了我们之外，没有其他人信任这个签名。 客户端怎么使用它？它通过代理发送API请求，在Authorization头部包含这个新令牌。代理验证令牌的签名，然后解密原始令牌，并用真实令牌替换掉假的令牌。远程API看到它期望的东西，大家皆大欢喜。智能体环境中从未出现过真实令牌，而且我们也不需要任何地方存储任何东西。唯一的状态是加密密钥，这些可以在启动时注入到环境中。需要扩展？只需启动更多这样的进程。需要支持多可用区？在不同地方启动更多这样的进程即可。代理或代理服务中从不保存持久化数据。你不需要关心分布式数据库或密钥存储。 我觉得这极其优雅，为自己的好点子沾沾自喜。然后这周早些时候我去了一家酒吧，坐下来读RFC 8705（https://datatracker.ietf.org/doc/html/rfc8705），旁边的人看到了，问我读什么，我解释了我为什么感兴趣，我们聊起了智能体身份，然后他提到fly.io有一个听起来非常类似的东西（https://fly.io/blog/tokenized-tokens/），我读了一下——天哪，确实非常相似。所以该死的fly.io，你们在3年前就把我的想法偷走了。好吧。现在我需要做得更好。 还记得吗？如果任何人能访问代理，他就能访问加密的密钥？我们也可以消除这个风险。智能体环境通常通过类似SPIFFE（https://spiffe.io/）的方式获得身份标识，从而拥有一个客户端证书。你可能猜到了我要做什么。如果我们要求智能体在向代理请求令牌时出示客户端证书，我们可以将该证书的表示嵌入到我们铸造的令牌中。然后代理可以要求客户端连接使用mTLS，并验证出示的证书是否与令牌中表示的证书匹配。如果匹配，那么使用该令牌的人就拥有与签发该令牌的环境相关联的私钥访问权。如果我们进一步确保这些证书的后端私钥由硬件或虚拟机管理器支持，从而绑定到特定实例，那么我们就有很高的把握认为该令牌只能在其预期环境中使用。即使我们的身份提供商不支持RFC 8705，我们也能做到。 如果你使用的平台中，身份提供商同时也是消费令牌的环境，那么这非常简单；但对第三方来说更麻烦。代理可能需要对第三方供应商有一定了解才能让所有人都能用。当登录不是通过你的身份提供商（感谢github）时更是如此，但这些都不是不可解决的——只是有点烦人。另外，当供应商颁发的是不透明令牌而非JWT时，这也仍然不是问题；我们可以简单铸造一个新的JWT，其中包含加密的不透明令牌作为声明，并同样包含证书绑定。不透明令牌最终是呈现给第三方的，但那是在我们验证了mTLS绑定之后。 在理想世界中，所有这些都不必要——有人会启动一个新的智能体环境，用户证明其身份，然后一个体现该身份的证书被颁发给该环境，其私钥无法被外泄。这个证书足以获取与同一私钥相关的新证书，我们仍然可以将其绑定到mTLS身份中。这会简单得多，但浏览器不支持它，所以短期内不太可能实现。 总之，即使我们无法拥有最好的方案，我们也可以比现在做得更好。而且，如果我们能就此达成标准化，而不是每个人都自己造轮子，那就太好了。完毕。