AI 代理身份设计指南

# 代理身份规则手册：赋予 AI 代理信任所需的一切

大多数关于代理安全的焦虑都忽略了一个好消息——我们其实已经知道如何为代理赋予身份。身份认证问题在几十年前就已得到解决。代理要求我们做的，只是在此基础上再构建一层，而这一层目前正由身份领域最重要的机构以开放的方式建设。

因此，这不是一份警告，而是一份设计简报。一旦你看清一个代理身份究竟需要承载什么，在生产环境中运行代理的路径就会清晰得多。

**从变化的地方说起**

人类进行身份验证、获得权限，然后采取行动。应用程序在服务身份下运行。代理则介于两者之间：它运行在一个凭证之上，但其行动背后的授权属于发出请求的人。

这一转变——从稳定的主体变为委托的主体——就是问题的全部。所有有价值的东西都源于有意识地围绕这一点进行设计。

因此，当代理执行操作时，系统应该看到两件事：执行操作的代理，以及它所代表的人类授权。做到这一点，大多数"风险"方面的讨论就会转变为架构层面的讨论。

**核心洞察：授权才是资产，而非凭证本身**

授权（Authorization）回答的是某个行为者是否被允许执行某项操作。归因（Attribution）回答的是谁批准了此操作、哪个代理执行了它。传统身份体系擅长解决前者。代理使后者同样重要，这是一个机遇，而非威胁。

可以把授权想象成代理从人类那里借来并随身携带的东西。当你在设计中确保这份授权在每一次跳转中都得以保留，你将获得企业一直渴望却鲜少清晰拥有的三样东西：清晰的来源追溯、精确的权限范围，以及真正的责任归属。赋予代理一个身份是容易的部分，保留其背后的授权才是价值所在，而这完全可以实现。

**强代理身份能给你带来什么**

一个良好的代理身份所传达的信息远不止"agent-123"。它告诉你：谁拥有该代理、谁部署了它、它在为谁行动、委托了哪些授权、它可以访问哪些资源，以及它做了什么。

设想一位员工要求代理更新生产配置。一个设计良好的身份层可以用一行信息回答：哪个代理执行了操作、谁拥有它、哪个用户发起了任务、委托了什么授权，以及发生了什么变更。五个问题，清晰归因。这不是合规负担，而是团队多年来渴望拥有的审计追踪，现在终于可以自动生成。

之所以奏效，在于上下文。代理的授权会随用户、任务和资源的不同而变化，现代身份层会结合上下文对身份进行评估。同一个代理在一项任务中可以被允许读取客户数据，而在另一项任务中则被正确地拒绝修改权限。这种精确性是静态服务账户永远无法提供的功能。

**传递上下文，让委托成为优势**

来看一个真实的工作流：人类 → 代理 → 工具 → API → 数据库。

每一次跳转都是向前传递授权上下文的机会，从而让最终的服务知道：此操作由该代理执行，依据的是该委托授权，针对的是该资源。

代理之间的交接展示了为何这一机制令人期待而非令人恐惧。代理 A 向代理 B 发出指令，代理 B 再调用外部服务。当权限上下文随请求一同传递时，代理 B 就能证明其权限的来源，最终的操作也能清晰地追溯到最初的人类意图。自主性与问责性由此得以同时实现。

这一设计原则十分简单：不要将一个权限过高的凭据贯穿每一个环节，而应携带范围受限、具备上下文的权限。这样做既能缩小安全漏洞的波及范围，又能同时强化审计追踪，而这恰恰是企业对代理系统说"是"所需要的那种组合。

**这已经在落地了，这才是真正的重磅消息**

你不必等待一个不知何时才会出现的标准。最大的身份平台正在现在就将其推向市场，而且它们正在向同一个方向汇聚。

微软推出了 Entra Agent ID，赋予代理一级身份，每个代理都需要一名负责任的人类赞助人，并使用与员工相同的生命周期管理和条件访问控制进行治理。该功能今天已正式上线。

AWS 推出了 Bedrock AgentCore Identity，它颁发一种工作负载身份，将用户与代理绑定在同一个访问令牌中，使代理在访问下游资源时携带的是发起请求的用户权限，而非共享凭据。

谷歌云将 Agent Identity 设为 IAM 中的一级主体，与人类身份和通用服务账户均有所区分，每个代理都拥有自己受治理的身份，同时仍携带其所代表的用户的上下文。

三大身份领域的巨头，共同朝着一个方向迈进：从识别一个参与者，转向在上下文中评估一个参与者。当这些行业主导者如此步调一致时，这强烈表明该模式已经可以作为构建基础加以使用。

**人类 IAM 与代理身份协同运作**

这一切都不会取代你现有的身份基础设施，代理是通过它进行认证的。你的策略、角色和权限依然重要。代理身份只是补上了缺失的另一半。

人类身份告诉你谁授权了某项操作；代理身份告诉你是哪个自主参与者执行了它。两者结合，便能呈现完整的全貌：谁有意图、什么解读了那个意图、以及最终实际发生了什么。那些将两者视为协作伙伴、而非试图将人类 IAM 硬拉伸以覆盖两者的团队，正是推进最快的团队。

**一份实践蓝图：代理身份控制循环**

如果你今天正在设计这一机制，以下六个步骤构成了一个清晰的循环，你可以据此进行构建，请按顺序执行。

**识别（Identify）**：为每个代理创建并验证其专属身份，永远不使用共享登录或继承的服务账户。

**归属（Own）**：为每个代理指定一名负有责任的人类所有者。

**授权（Authorize）**：授予针对当前任务范围受限的权限，而非持久访问权限。

**执行（Action）**：仅允许代理通过经批准的工具和数据采取行动。

**审计（Audit）**：将每一项操作、每一次决策和每一次工具调用记录，并归属到唯一的那个身份。

**撤销（Revoke）**：在任务完成或风险出现的那一刻立即移除访问权限——由于每个代理都是唯一的，你可以精确撤销其中一个，而不影响其余所有代理。

识别、归属、授权、执行、审计、撤销。每一步都可以用当下已有的技术实现。这是一件可以动手去做的事，而不是等待。

**前方的机遇**

智能体AI正在人类意图与自主执行之间划定一条全新的身份边界。这条边界并非令人恐惧的问题，而是未来几年中最重要的基础设施建设课题。将其构建好，才能让智能体从试点走向真正的生产部署。

那些将智能体身份视为核心基础设施并有意识地加以设计的组织，将能够自信地部署智能体，而其他人仍在争论这是否安全。问题从来都不是智能体能否行动，而是你能否证明谁在这一行动背后负责。这是一个可以解决的问题，而解决方案正在我们眼前逐步成形。

我专门为真正在构建智能体的人解析AI智能体。如果你正是其中之一，欢迎建立联系 👉 https://www.linkedin.com/in/rakeshgohel01/

📌 预约探索通话：https://juteq.ca/

订阅Newsletter，获取AI智能体深度洞察：https://rakeshgohel.substack.com/subscribe

如果这篇内容对你有帮助，💾 收藏它，♻️ 转发它，并 👇 在评论区告诉我你遇到的最大瓶颈。