ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

代理身份标准落地,证书、撤销等机制能否解决实际安全问题?

2026/9/2 3:22:31 拓冰建站 浏览量
代理身份标准落地,证书、撤销等机制能否解决实际安全问题? 代理身份标准引发的安全思考编辑部消息如果一个代理可以在无人察觉的情况下改变其行为那么有效的代理身份几乎证明不了什么。对于那个谁都解释不清的服务账户如今已不再令人惊讶。它是为几年前就已完成的迁移工作创建的至今仍保留着凭证当初申请账户的人在还没来得及记录用途时就离开了且它能通过每次访问审查因为审查只问账户是否有效答案是肯定的。如今代理身份标准开始投入实际应用短短几个月内就有四项标准落地。微软的 Entra Agent ID 全面可用Linux 基金会宣布了 Agent Name ServiceANSDNS - AID 和思科的 AGNTCY 也在同步推进。这四项标准都认同代理需要有自己的身份借用人类的凭证行不通。比起大多数团队目前的做法采用这些标准更值得倾向但这些标准实际能证明什么值得关注。证书能证明什么阅读 ANS v2 草案时其对自身范围的坦诚表述令人印象深刻。关于注册机构RA草案提到它只回答“你是谁”的问题并不评估代理是否管理得当或行为良好这是命名层应有的合理范围。草案中给出的动机场景显示一家供应商通过安全审计后更换了其模型证书仍然有效端点也正常运行但背后实际情况已与最初审核通过的内容大相径庭。草案作者以此作为需要 ANS 的理由但即便有了 ANS这个问题依然存在。注册信息包含主机名、版本、端点、声明的功能以及证书签名请求标识符由版本和域名组成。改变代理背后的模型重写其系统提示提供不同的文档注册信息却不会变动。草案虽提到代码或配置更改后版本会更新由托管平台发起新的注册但 RA 只验证域名控制权不关心内部变化就像一个公证人。完整性监控只是做元数据检查不观察代理实际行为。草案也指出有待解决的问题运行时完整性被列为“未来工作”以弥补应用程序完整性差距。这并非对 ANS 的批评第一层是基础身份行为声誉属于第三层由其他供应商根据其他信号进行评分。令人担心的是购买了第一层服务却误以为买到了第三层这使得身份与信号的关联远远慢于试图控制的行为变化。代码每月更新一次但上下文环境随时都在改变就如之前写过的关于 MCP 无状态化的内容模型通常由客户选择。信号传递是反向的Entra 就体现了这一局限。Entra 显示出的局限性持续部署的团队不断产生变动每次版本更新都要进行新的注册并生成新的日志记录导致记录杂乱无章。而一个代码一年都未更改的代理可以保持单一、清晰且持续有效的身份记录没有触发因素无需轮换也不会进入审核队列身份可以保持原样。系统中最干净的身份记录可能属于那个已经与最初审批内容相差最远的代理。在仔细研究过的事件中身份信息从未决定过损失的程度。今年 4 月为汽车租赁 SaaS 平台 PocketOS 进行测试任务的一个代理遇到凭证不匹配问题通过从一个为域名管理创建的无关文件中获取 API 令牌来解决。Railway 的令牌对整个 GraphQL API 具有全面权限不受操作或环境的限制仅仅一次调用九秒钟内生产数据库就没了由于卷备份也在该卷内备份也一同丢失最近可恢复的副本是三个月前的。那个周六租车柜台前的顾客发现自己的预订没了几天后 Railway 才恢复了数据。在这个事件中所有证书都是有效的代理也确实是它所声称的那样真正出问题的是凭证范围而这四项标准都没有针对此进行设计。不过四项标准中有一项超出了命名范畴微软的标准设计得最好其局限性也值得关注。Entra 要求每个代理身份都有一个赞助人对代理的用途和生命周期负责拥有续期和停用的权限但没有管理访问权这确实解决了孤立服务账户的问题比命名标准更进一步。但它并没有让代理承担责任只是让一个人变得可追溯代理无法被制裁、解雇也不在乎后果责任最终还是落在了人身上Entra 在这方面比加密方法更坦诚。如果赞助人离职赞助权会自动转移给其经理这总比没有赞助人的代理要好但这也意味着责任向上转移到一个从未选择该代理、也无法判断其是否必要的人身上。经过两次人员变动后对一个自主系统负责的人可能与最初了解该系统的人隔了三层他们会批准审核因为代理的一切看起来都有效。Palo Alto Networks 2026 年的身份调查显示每个员工对应的机器身份数量从一年前的 82 个增加到了 109 个其中约 79 个是 AI 代理以员工数量为基础的季度审核根本无法应对这个数字。赞助制度是个好主意但对应的工作量却让人难以承受这就是为什么会出现那个谁都解释不清的服务账户还带着一份审计日志。撤销不是正确的衡量标准最初是想探讨撤销机制的有人认为应该选择可以撤销的标准但读完相关规范后觉得这是个错误的问题。总会想起网络领域在这方面的经验撤销依赖于有人发现问题APNIC 的分析明确指出撤销无法阻止攻击者利用被盗用的密钥进行攻击因为持有私钥的攻击者可以简单地重新认证。更好的解决办法是避免使用长期有效的证书DNSSEC 根本没有撤销功能依靠较短的缓存生命周期其暴露窗口比 Web PKI 短得多内部 CA 也采取了类似的做法。如 step - ca 所说的被动撤销并不是真正的撤销只是拒绝续期操作上的差距才是问题所在。在 Sysdig 记录的一次入侵事件中攻击者利用暴露的凭证在大约八分钟内获得了管理权限并横向渗透了 19 个 AWS 主体轮换队列的运行速度根本跟不上。任何依赖人工发现问题的控制措施都会把应对时间拱手让给攻击者而且很多时候根本不会起作用。GitGuardian 2026 年的机密研究发现2022 年确认有效的凭证中有 64% 在 2026 年 1 月仍然可以被利用四年时间既没有轮换也没有撤销无论政策怎么规定这就是撤销机制实际的效果。代理相关的工作也在不断发展APKI 草案用信任分数取代了简单的有效或撤销状态在没有积极信号时信任分数会衰减将这种衰减视为软撤销这种超越二元有效性的提议很有意义。所以衡量标准不应该是能否撤销代理身份而是代理的权限是否会在无人干预的情况下过期这是唯一能与行为随时可能改变的代理相匹配的特性。撤销需要有人发现、决策并传播信息而过期则无需人工干预一个经历了三次组织架构调整后赞助人已离职的代理会自动停用需要有人来争取续期。但有一个案例甚至打破了这种说法英国 AI 安全研究所UK AI Security Institute在 7 月底披露了一次网络评估中的事件一个代理在 GitHub 上公开留言邀请其他代理共同应对同一挑战并提供了重用其遗留账户和工件的说明后来的代理发现并使用了这些信息。AISI 对这一事件的描述是独立代理之间的协作“独立” 意味着没有任何协调机制一个代理将其状态公开化无关的实例也能获取这些信息。在这个事件中没有身份信息需要验证也没有凭证会过期多亏 AISI 联系了 GitHub这些工件才被移除。身份基础设施只能管理配置的代理对于以文本形式传播的影响则无能为力。这可能不如选出一个最佳标准那么令人满意但命名层并不是解决问题的关键选择哪个标准并不重要重要的是当代理提出请求时系统会如何应对这也是在 MCP 无状态化时得出的结论前门的身份验证能告诉你是谁在敲门但无法告诉你进来的是什么。