凌晨2:13，你的CI机器人提交了一个PR。2:19，一个自主编码代理合并了依赖更新。2:27，客服代理查询了客户数据。第二天早上，系统崩了——日志只显示一行：agent=true。
这不是科幻片开场，是2024年硅谷工程师的真实日常。当AI代理从"贴心小助手"进化成"能动手就别吵我"的自动执行者，大多数团队还在用识别API客户端的方式识别它们：共享API密钥、模糊的服务账户、一个bearer token（持有者令牌）到处传。简单自动化够用了，追责的时候呢？
如果一个代理能写代码、审批工作流、访问内部工具或触碰客户系统，它需要的身份模型必须能回答三个问题，而且要有密码学级别的可信度：
谁在行动？谁授权了？权限边界在哪？
缺失的那层，就是密码学身份。
现在的代理系统，像五个员工共用一张工牌
很多团队的现状是这样的：一个token（令牌）丢给五个代理用，谁干了什么分不清；代理A被入侵了，所有动作看起来都一样，因为身份标识完全相同。
代理经常代表用户、团队或其他服务行动，但这种委托关系埋在应用逻辑或元数据里，想查清楚得像考古——从编排器、应用、模型提供商、目标系统四处拼凑日志。这不是 accountability（可追溯性），是 digital archaeology（数字考古学）。
更隐蔽的问题是权限范围。代理很少需要人类级别的完整访问权，但没有细粒度身份和策略执行，团队只能图省事给 blanket permissions（ blanket permissions：一揽子权限）。就像给实习生配了CEO的门禁卡，因为"懒得单独开权限"。
后果 predictable（可预见）：2023年某头部云厂商的内部报告显示，37%的代理相关安全事件源于"身份混淆"——多个代理共享凭证导致无法定位责任方。
密码学身份：给每个代理发一张"数字指纹身份证"
对于自主代理，身份不该只是数据库里的字符串。它应该是：
唯一可验证的——每个代理有独立的密码学密钥对，像指纹一样唯一；可委托的——能清晰展示"谁授权了它做什么"；可审计的——每个动作附带可验证的身份证明；可撤销的——出问题能精准拔掉单个代理的权限，而不是全员停摆。
实际落地并不复杂。典型架构长这样：代理启动时生成或加载密钥对，向身份提供商注册获取短期凭证，每次动作携带签名过的身份断言，目标系统验证签名、检查委托链、执行策略决策。
热门跟贴