最近三周一直在思考智能体身份认证授权（agent id）的事情，感觉这个挺重要的。但是思考下来的结论就是，我可以看别人做，但是我不做。

智能体最开始是没有任何身份和权限机制的，因为它只是个问答机器人。现在大家让智能体与某个CLI或MCP Server交互，CLI/MCP通过REST API操作后端业务系统，而同一个Agent，会被不同的用户使用。如果没有用户身份绑定，后端服务根本不知道这个请求背后是谁。就会出现水平越权和垂直越权问题。通过引入OAuth认证，解决了一小部分问题。

还有一些问题没有得到解决。比如说Agent会长期在后台工作，包括定时触发的任务、事件驱动的任务等等，根本没有人实时输入oauth认证。另外，一个智能体会连接无数的mcp业务系统，直接把无数个永不过期的mcp认证信息写在智能体配置文件里面不合适，管理负责且泄露了麻烦很大。所以肯定需要引入一个第三方的认证系统，让智能体可以为每个任务申请一个临时的身份令牌。这其实和当前云厂商的aksk方法类似，和linux不使用root帐号工作也类似。

这么想下去，智能体的身份其实类似于之前的零信任体系。不仅仅是web应用的零信任，而是服务器上进程级别的身份识别和授权。每个Agent实例获得独立的身份凭证，这个凭证与用户的OAuth Token建立绑定关系，但两者相互独立，类比SPIFFE/SPIRE对工作负载身份的处理。实现方法有两条路。一是SDK模式，客户在研发智能体的时候购买第三方身份sdk，自动附加Agent身份头，业务代码零感知，但是对于员工自己乱搞的智能体就无能为力了；二是eBPF内核级透明注入，在操作系统层面拦截网络调用，无需任何代码改动，适合无法修改代码的存量系统，也是零信任架构在Linux侧的经典做法。强制性更高，但对运行环境有要求。

但是这个sdk或者注入只是解决了Agent侧的问题，但权限边界的定义必须在业务系统侧完成。假设HR部门发布了一个CLI给员工的Agent集成，行政部门发布了一个MCP Server供集成。如果要做第三方的Agent身份管理，权限划分必须和HR系统、行政系统相配合——但是第三方安全产品又不知道HR系统内部有哪些权限粒度。我能想到的解决办法，可能是业务系统提供api暴露权限划分，让agent id产品基于拉取到的权限分层来设置agent的权限。或者在业务系统建立几个新的用户，映射为Agent的某个id。不论如何，业务cli的后端rest api或者业务mcp server前面都需要部署一个gateway，做权限的控制和审计。

其实想到这里，我就已经不愿意做这个产品了。产品复杂度极其高，交付难度极其大，但是客户原意付多少钱呢？更让我觉得没意思的是，大模型厂商一定会从模型往下做智能体再往下做智能体身份方案，不会给第三方厂商留空间。我经常讲，国内的移动安全市场和云安全市场是伪概念，大模型相关的安全市场一定也是伪概念。以云为例，国内公有云厂商一定是封闭的，cwpp、waf、ndr基本上上不去，都是云厂商自己在卖。结局也不过就是他们的产品线非常广，人力成本巨高，把云的综合利润做成了白菜价，而没有专注把云做精。至于私有云，那还是云吗？卖的依旧是堡垒机防火墙杀毒软件，其实是传统安全。

所以我的结论是，大模型安全市场也是伪概念，第三方独立安全公司尽量别去搞，包括智能体身份产品、大模型网关产品等等，至少我不去折腾。我想做的是什么呢？用大模型做好安全，做精安全，把以前用规则、用机器学习没法做到的一些事情，用大模型做出来，这是真正让我觉得有趣的地方。