去年某大厂出过一件事：凌晨2点，一个自动化脚本把核心依赖库升了级，CI流水线全绿，代码合进了主分支。第二天早上，生产环境炸了。运维查了三小时日志，结论只有一行——agent=true。
agent=true。这就是全部信息。
没人知道是哪个agent干的，不知道它当时代表谁操作，不知道它有没有权限做这件事。团队花了两天时间，把编排器日志、应用日志、模型提供商日志、目标系统日志拼在一起，才勉强还原出时间线。这不是问责，是考古。
现在的AI代理，用着20年前的身份方案
大多数团队给AI代理的身份认证，还停留在" glorified API client"（ glorified API客户端，即"高级点的接口调用者"）级别：共享API密钥、模糊的服务账户、一个bearer token（持票人令牌）在工具之间传来传去。简单自动化够用，但代理一旦能写代码、审批工作流、访问内部工具、触碰客户系统，这种方案就开始崩了。
问题很具体：
五个代理共用同一个token，日志里分不出谁是谁。一个代理被入侵，所有动作看起来都一样。代理经常代表用户、团队或其他服务行事，但这种委托关系埋在应用逻辑或元数据里，既难检查也难审计。代理很少需要人类级别的完整权限，但没有细粒度的身份和策略执行，团队只能给 blanket permissions（ blanket permissions，即"一揽子权限"），因为省事。
事后追责时，团队要从四个地方挖日志：编排器、应用、模型提供商、目标系统。拼出来的故事漏洞百出，责任链条断成几截。
加密身份：给代理发一张"数字工牌"
代理需要的身份模型，得用密码学回答三个问题：这个代理是谁？它代表谁行动？它被允许做什么？
技术上不复杂。一个可验证的代理身份，通常包含：唯一标识符（不是"agent-001"这种字符串，而是密钥对）；代表关系链（谁授权了它，授权范围是什么）；能力声明（它能调用哪些工具，参数边界在哪）；动作签名（每个请求用私钥签名，可验证不可抵赖）。
对比两种方案：
没有加密身份：给代理一个GitHub token，它能做任何token持有者能做的事。日志里看到"有个token调了API"，仅此而已。
有加密身份：代理用专属密钥对发起请求，请求里附带委托链（"我代表用户X，在Y项目的Z仓库操作"），策略引擎实时校验权限，动作被签名后记录在审计日志。PR打开时，你能回答：哪个具体代理？在什么委托权限下？针对哪段代码？签名是否有效？
这就是"有个自动化做了点什么"和"这个特定代理，在此委托权限下，执行了此动作"的区别。
身份有了，还得有策略
身份只是命名，策略才是边界。很多团队已经在用OPA（Open Policy Agent，开放策略代理），不需要新引擎，但需要更好的输入：真实的代理身份、完整的委托链、结构化的工具请求上下文。
一段 minimal Rego（ minimal Rego，即"最小化Rego策略代码"）示例：允许代码代理打开PR，但不允许直接合并到main分支。
关键点是input.agent必须是真实的身份数据，而不是请求体里一个不可信的字符串。策略引擎看到的不是"有个东西说自己是code-agent"，而是"密钥对0x7a3f...签名的请求，委托链来自团队backend，请求动作在授权列表内"。
这不是未来，是现在的债务
热门跟贴