2 篇博文 含有标签「non-human-identity」

发现你上线了一个 AI 智能体的最糟糕时机是在事故复盘中。不是在设计文档里，不是在架构评审中，也不是在变更工单里 —— 而是在事故复盘现场，律师正询问为什么在未经授权的情况下给客户退了款，而一名工程师正翻找着一个上次进行实质性评审还是在 11 个月前的服务，然后在名为 enrichTicket 的函数第 40 行处，发现了一个模型调用，它读取客户记录、决定处理方案，并调用了计费 API。没有人画过它的架构图。没有人批准它作为一个智能体运行，因为对于编写它的人来说，它根本不是智能体。它“只是一个辅助工具”。

这就是影子 AI，它已经露出了獠牙。第一波浪潮是员工将公司数据粘贴到消费级聊天机器人中 —— 这是一个数据泄露问题，虽然严重但尚在可控范围内。第二波浪潮是智能体：嵌入内部工具的模型调用，它们读取真实数据并执行真实操作，潜伏在那些原本为完全不同的用途而获批的服务中。大约一半的员工承认使用了雇主从未批准过的 AI 工具，而且很大一部分比例的使用来自高层 —— 总监和高管是主要的“元凶”，而不是实习生。当这种本能延伸到你的代码库时，你得到的不再是一个泄露的电子表格。而是一个拥有生产环境凭据且未经任何人签字批准的自主代理人。

令人不安的是，影子智能体并非由鲁莽的人创建。它们是由优秀的工程师创建的，而他们只是在执行你的要求：快速交付价值、复用现有基础设施、不要为每一个微小的改动都提交工单。治理差距并不是纪律问题。它是一个定义问题 —— 你的评审流程中根本没有他们所构建内容的对应类别。

你在第一天为 Agent 创建的 IAM 角色本应是临时性的。试点项目需要进度，团队需要 Agent 在演示前投入生产，而有人——大概就是你——在 PR 中加了一条评论：“发布后再收紧权限。”九十天后，试点项目已经上线，Agent 已经在为付费客户提供服务的生产环境中运行，而该角色仍然拥有对三个 Agent 从未接触过的存储桶的 write:* 权限。运维人员（On-call）无法告诉你这 18 个 Scope 中哪些是核心负载，哪些是冗余，因为唯一了解情况的人已经转岗，而能够证明区别的运行时遥测数据也从未接入。

这并不是关于一个粗心团队的故事。而是一个关于所有构建 Agent 的团队如何陷入同一困境的故事，因为大多数公司尚未发明防止这种情况发生的生命周期管理规范。人类身份识别在过去 30 年中为此积累了大量机制——入职工作流、季度访问审查、转岗时的自动权限撤销。而 Agent 身份识别只有一条 Slack 消息，写着“我晚点会清理”。第一天的授权变成了第九十天的遗产，而爆炸半径随着每次模型升级、每个添加到 Agent 工具箱的新工具以及每个接入该角色的新客户而不断扩大。