AI Agent 安全始于身份，但企业需要的不只是凭据

Google News 在 9 月 2 日推送了一则关于 AI Agent 的警告，但这场冲突远不止又一份安全检查清单。文章认为，企业在 Agent 进一步普及前必须回答三个问题：它们在哪里、能够连接什么，以及能够执行什么操作？

这一框架出现在 GuidePoint Security 刊登的一篇客座文章中，作者是 Okta 安全产品营销人员 Ariel Zommer。其核心观点很简单：一旦 Agent 能够进行身份验证、访问企业系统，或无需持续的人类指引便可行动，它就成为一个身份问题。

时机至关重要。NIST 于 8 月 27 日发布了另一则身份警告，距 GuidePoint 文章发布不到一周。Microsoft、Okta 及其他身份提供商也正将 Agent 身份打造为正式的产品对象。

这种趋同改变了企业层面的讨论。核心问题不再是模型能否给出准确答案，而是每一项由此产生的操作是否具备可见的执行主体、受限的权限、明确的责任人和可撤销的连接。

这一论点之所以听起来并不陌生，是因为身份管理早已用于治理员工、应用程序和传统工作负载。Agent 让这一模式变得复杂，因为它们的行为具有概率性、连接关系会变化，而且一次请求可能触发大量下游操作。

因此，身份是必要条件，但并不充分。凭据可以识别一个 Agent，却无法证明其当前操作是安全的。真正的较量在于可追责的自主能力与组织无法完全追踪的便捷访问之间。

Google News 实际推送了什么

这并非一次新的漏洞披露，而是一次协调一致的警告：Agent 的采用速度正在超过企业身份控制能力。

这篇原始身份论述由 GuidePoint Security 于 2026 年 9 月 2 日发布。文章由一名 Okta 员工撰写，并以合作伙伴观点的形式呈现。

这一区别很重要。读者应将该文视为有厂商支持的分析，而非证明某个商业平台能够解决所有 Agent 安全问题的独立证据。其提出的三个问题依然有用，因为它们描述了可衡量的控制缺口。

第一个问题是，组织的 Agent 分布在哪里。盘点必须涵盖内部开发的 Agent、嵌入 SaaS 产品的功能、云托管 Agent、员工授权的工具以及实验性系统。

传统资产清单往往会遗漏这些类别。开发者可以在获批的云账户中创建 Agent，却不将其登记为独立的业务应用。员工也可以通过 OAuth 授权外部工具。

OAuth 是一种授权标准，可让一个应用获得对另一项服务的有限访问权限。它带来的便利，可能让从未批准底层 Agent 的团队看不到持续存在的信任关系。

因此，发现工作不能只扫描代码仓库。安全团队还需要云资产清单、应用注册记录、OAuth 授权、服务账户、浏览器信号、API 网关记录，以及 Model Context Protocol 连接。

Model Context Protocol，简称 MCP，可让 AI 应用通过通用接口连接工具和数据。它能够简化集成，同时扩大可访问系统的范围。

第二个问题是，每个已发现的 Agent 可以连接什么。这张映射图应覆盖业务应用、内部 API、数据库、协作系统、密钥、服务账户和其他 Agent。

连接关系并不能完整揭示风险。安全团队还需要了解其授权方式、权限范围、凭据有效期、业务负责人、审批历史和撤销路径。

第三个问题是，Agent 在建立连接后能够执行什么。读取权限、修改记录、执行代码、资金转移和冒充用户，带来的后果截然不同。

这些权限还可能相互组合。一个能够读取电子邮件并创建支持工单的 Agent，在单独审查每项连接时看似权限有限；但当它能提取指令并触发外部操作时，其影响就会显著增大。

Google News 帮助将这一警告呈现给更广泛的受众。不过，真正重要的事件发生在聚合层之下：身份厂商和公共标准机构正逐渐将 Agent 视为一等企业行为主体。

这一转变为安全负责人提供了更清晰的起点，也带来压力，要求他们将 Agent 的身份与启动它的用户、应用或服务账户区分开来。

借用的员工令牌无法清晰地实现这种区分。多个 Agent 共用的一把 API 密钥同样做不到。两种安排都会削弱审计和事件调查中的归因能力。

眼下的变化在概念层面，但会影响运营。企业现在需要为 Agent 建立独立的生命周期记录，包括创建、归属、授权、审查、暂停和退役。

身份已成为 AI 的控制平面

Agent 需要独立身份，因为没有归因的权限会让常规自动化变成无边界的调查难题。

身份与访问管理，即 IAM，决定谁可以在何种条件下访问资源。现有 IAM 系统已提供目录、策略引擎、访问审查、令牌服务和审计记录。

这些组件为企业提供了实用基础。它们可以注册 Agent、为其关联负责人、授予特定权限，并在 Agent 变更或退役时撤销这些权限。

NIST 在近期的身份基础分析中强化了这一立场。该机构警告称，早期部署正将功能和即时价值置于既有身份实践之上。

NIST 还强调，凭据共享是一个核心问题。共享凭据会破坏问责能力，因为调查人员无法可靠地确定究竟是哪个人员、服务或 Agent 执行了某项交易。

当 Agent 委派任务时，问题会更加突出。用户可能要求一个 Agent 准备销售简报，该 Agent 又可能调用另一个系统获取客户数据，并调用第三项服务开展竞争研究。

每一次交接都会产生一项授权决策。企业必须保留发起请求的用户、执行操作的 Agent、被请求的资源，以及请求背后的目的。

没有这条链路，日志只能显示某个服务账户访问了数据库。它们无法解释是哪个 Agent 发起操作、哪个用户提出请求，或该操作是否符合已批准的工作流。

一等身份能够恢复部分这类上下文。每个 Agent 获得唯一标识符，而不是借用通用账户。策略随后可以针对特定 Agent 施加约束。

这一模式支持最小权限原则，即将身份限制在完成指定任务所必需的最低访问范围内。它也支持撤销权限，而不会干扰无关的应用或员工。

短期令牌可进一步强化这一设计。令牌是一种经过签名的凭据，代表在有限范围和期限内授予的权限。较短的有效期会降低凭据被盗后的价值。

联邦凭据提供了另一项改进。它们使受信任的工作负载能够请求令牌，而无需在代码、配置文件或 Agent 的记忆中存储可重复使用的密钥。

归属关系补全了基础记录。每个生产环境 Agent 都需要一名指定的人员或承担责任的团队，负责其用途、权限、审查和退役。

负责人不能仅仅是创建首个原型的开发者。业务归属同样重要，因为必须有人决定该 Agent 的访问权限是否仍有必要。

生命周期状态也很重要。实验性 Agent 不应在测试结束后继续保留生产权限。被替换的 Agent 也不应仅因其 API 密钥仍可使用而保持活跃。

这一结构类似于对员工和应用的治理。然而，Agent 需要更频繁地评估，因为它们的工具、指令、模型和委派任务都可能独立变化。

因此，企业应将身份目录视为控制平面，而非静态通讯录。注册是治理的起点，持续的策略执行才赋予其实际意义。

这一区别也能保护合理的实验活动。开发者可以获得一条明确的 Agent 注册路径，而不是在部署后等待漫长的安全审查。

可用的注册流程应记录用途、负责人、环境、工具、数据类别、权限和预期运行边界，同时还应指定到期日或审查日期。

如果获批路径比创建未注册 Agent 更慢，团队就会绕过它。因此，身份计划必须让安全接入比隐蔽部署更容易。

这正是知识管理实践能够支持治理的地方。团队需要可搜索的记录，将决策、负责人、要求、审批和后续变更关联起来。

盘点只能回答一个 Agent 在哪里注册。相连的运营知识则能解释它为何存在，以及其当前行为是否仍符合最初目的。

三个问题揭示三类不同的失效

发现、连接控制和操作治理是彼此独立的学科，通过其中一项并不能弥补另一项的失败。

“我的 Agent 在哪里？”检验的是可见性。安全团队无法治理只存在于开发者账户、员工浏览器或 SaaS 管理员配置中的 Agent。

有效的盘点必须涵盖受批准和未获批准的部署，也必须区分活跃 Agent、模板、废弃实验、已禁用实例，以及使用 AI 功能的普通应用。

清单应识别每个 Agent 所处的环境和运行状态。开发、测试和生产 Agent 不应共享相同的审批假设。

安全团队还必须界定什么算是 Agent。仅返回文本的聊天机器人，与调用工具或更改记录的系统，其权限特征不同。

定义应聚焦于行为。如果软件能选择操作、调用已连接的工具，或在有限人工审查下委派工作，它就应纳入治理范围。

“它们可以连接什么？”检验的是组织的信任图谱。信任图谱记录身份、凭据、应用、资源和被委派服务之间的关系。

该图谱应展示直接和间接可达性。一个 Agent 可能没有数据库访问权限，却有权调用能够查询同一数据库的服务。

Agent 之间的连接让映射工作更加困难。一个 Agent 可以向另一个 Agent 传递上下文或权限，从而形成跨越平台和管理边界的链条。

企业必须记录每项连接是使用常驻访问权限还是任务特定授权。常驻访问会在任务之间持续可用，如果 Agent 遭到入侵，暴露风险也会增加。

任务特定授权会针对明确的操作授予更窄范围的访问权限。它可能在任务完成后失效，并在代理的上下文发生变化时需要重新评估。

“它们能做什么？”测试的是运行时控制。答案不能只是从应用注册中复制出来的一串 API 权限范围。

某项权限范围或许允许修改文件，但策略仍应区分日常编辑与删除整个代码仓库。相同的技术权限，可能覆盖业务后果截然不同的操作。

运行时授权会在拟议操作发生时对其进行评估。它可以考虑执行代理、发起用户、资源敏感度、请求的操作、位置以及当前风险信号。

有些决策应保持自动化。若每次低风险查询都要求人工批准，代理所承诺的生产力价值便会被削弱。

高影响操作应面临更强的阻力。对生产系统的变更、资金转移、受监管信息的披露，以及不可逆删除，都需要明确的防护措施。

人在回路中的审批是一种选择。它会在代理完成敏感操作前，于预先定义的决策节点引入人工判断。

审批必须提供有意义的上下文。一条只写着“允许操作”、却未说明资源、数据、目的和预期影响的提示，本质上只是形式化的勾选框。

组织还需要可靠的停用机制。终止开关应撤销代理在各个已连接系统中的活跃访问权限，而不只是禁用其可见界面。

这一能力取决于凭证架构。当代理使用分散的 API 密钥、缓存令牌，或被复制到外部服务中的凭证时，集中式撤销的效果会很差。

因此，这三个问题构成一个顺序。发现机制确立主体，连接映射界定潜在触达范围，操作治理则控制已实际行使的权限。

跳过这一顺序会带来虚假的安全感。组织可能维护着完整的代理目录，却让目录中的每个代理都拥有过度权限。

它也可能发放范围狭窄的令牌，却遗漏员工自行创建的代理。或者，它可以记录代理操作，却没有保留足够的身份上下文来完成归因。

这一框架的价值在于界定这些失效边界。每个问题都为审计人员和安全负责人提供了可验证的具体主张，而非关于“负责任 AI”的笼统保证。

身份控制无法判断一项操作是否明智

有效身份能够回答“谁在执行操作”，但无法保证代理理解了请求，或选择了安全的操作。

这一限制定义了本文的核心权衡。企业需要基于身份的控制，但代理即使使用与传统应用相同的凭证，其行为仍然更难预测。

传统服务执行的是为已知工作流编写的代码。代理则可以解释指令、选择工具、生成参数，并根据返回的信息调整执行路径。

这种灵活性创造了价值。但它也意味着，认证成功不能作为下一项决策符合用户意图的证据。

提示注入说明了这一缺口。代理可能在文档、电子邮件、网页或检索记录中遇到恶意指令，并将其视为自身任务的一部分。

攻击者无需窃取代理的身份。攻击者可以尝试操纵一个已正确认证的代理，滥用其合法权限。

OWASP 在其代理式安全风险中列出了身份和权限滥用。该类别涵盖对委派链、继承角色、缓存凭证和代理上下文的操纵。

工具误用带来了另一类问题。代理可能使用不安全的参数调用已获批准的工具，或在工作流的错误阶段调用该工具。

身份控制可以拒绝访问未经批准的工具。但它们无法独立判断每一次被允许的调用，是否真正服务于用户的实际目标。

因此，安全架构必须将模型视为不受信任的决策组件。凡是涉及后果的场景，确定性控制都应保留在模型之外。

确定性控制遵循明确规则，而非生成概率性响应。例如权限检查、模式验证、交易限额和强制审批关卡。

策略引擎应评估代理提出的操作，而非依赖代理自我约束。代理不应能够重写控制其权限的规则。

输入和输出验证仍然重要。工具参数应符合预期模式、资源限制、数据分类和获批准的目标位置。

网络控制可以进一步缩小触达范围。一个从不需要访问公共互联网的代理，不应默认获得此类访问权限。

数据控制同样重要，因为身份无法阻止向获准接收者进行不当披露。策略还必须考虑数据敏感度、用途和保留期限。

监控必须既关注行为，也关注登录。成功认证后出现异常枚举、大规模下载或反复被拒操作，都值得调查。

这正是“身份优先”这一主张需要谨慎表述的地方。身份为问责、撤销和策略提供锚点，但它并不是完整的代理安全系统。

商业身份平台可以集中管理注册和令牌，却无法保证每个已连接模型都能抵御操纵，或正确理解模糊的目标。

供应商中立性也仍不确定。代理将跨越 Microsoft、Google Cloud、Amazon Web Services、Salesforce、ServiceNow、内部框架和专业 SaaS 产品。

每个平台对代理的表示方式可能不同。跨平台身份需要可互操作的令牌、一致的声明、受信任的签发方，以及能够跨越交接环节的策略。

MCP 增加了另一道边界。企业可能治理代理本身，却依赖外部服务器来准确暴露工具并保护其自身凭证。

身份层本身也需要免受入侵。集中式目录和令牌服务会成为高价值目标，因为它们可以同时影响许多代理。

企业应分离管理职责，保护高权限变更，并监控异常的策略修改。代理治理不能依赖一个拥有广泛权限的控制台账户。

审计日志同样值得保持怀疑。大量事件并不会自动形成有用证据。

调查人员需要能关联用户请求、代理身份、被委派代理、所选工具、授权决策、受影响资源和最终结果的记录。

保留策略必须足够长久地保存这条链条，以支持调查和监管审查。敏感提示和输出可能需要最小化处理或限制访问。

正确的结论比供应商信息更为克制。身份是代理安全的起点，因为控制需要一个已知主体。

安全仍需要围绕该主体构建分层防御。这些层包括受约束的工具、外部策略、受保护的凭证、数据控制、监控和人工审查。

Microsoft 和 Okta 正在将这一理念产品化

身份优先的理念正从会议话术走入目录、令牌流、发现系统和撤销控制。

Microsoft Entra Agent ID 展示了大型平台如今如何直接表示代理。Microsoft 将代理身份描述为具有唯一标识符的专用服务主体。

服务主体代表身份租户中的应用程序或工作负载。代理版本让策略和日志能够将代理与其底层蓝图区分开来。

Microsoft 的自主认证流程将代理身份与可复用的生产密钥分离。文档建议使用托管身份或证书，而非客户端密钥。

自主代理可以为自身身份请求应用令牌。交互式代理则可在代表已认证用户操作时使用委派流程。

这种差异至关重要。自主执行夜间报告的代理，不应与为已登录员工执行单次操作的助手被视为完全相同。

代表身份授权会在委派过程中保留用户关系。生成的令牌可以将用户标识为主体、将代理标识为执行者。

这种设计为资源服务器提供了更多授权上下文。系统可以询问：该用户通过该代理执行操作时，是否可以执行所请求的操作。

Microsoft 还记录了适用于需要类用户对象资源的特殊代理用户账户。这类账户可以支持邮箱或协作功能，而不使用普通的人类凭证。

这些账户带有限制。Microsoft 表示，它们无法获得高权限管理员角色，从而为某些形式的权限升级划出边界。

Okta 则从平台中立的身份立场切入同一市场。其 4 月发布的代理身份公告提到了发现、注册、托管连接、治理和停用。

该公司表示，其目录可以从外部平台导入代理并注册自定义代理。它还描述了通过 OAuth 同意信号检测影子代理的能力。

Okta 围绕 GuidePoint 客座文章中反复提出的同样三个问题来构建产品叙事。这种重合印证了该文章的商业背景。

产品信息值得审视，但其实施类别是具体的。企业需要代理目录、用于连接的范围受限令牌，以及针对操作的策略执行机制。

如果平台提供可互操作的控制，竞争将使买方受益。Microsoft 的模式可能适合以 Entra 和 Microsoft Graph 为中心的组织。

Okta 强调跨多个云、应用程序和代理框架的治理。云服务提供商自然会将其代理服务与既有的工作负载身份系统集成。

危险在于碎片化。企业最终可能在每个云中拥有一份代理清单、在身份提供商中拥有另一份，并在多个 SaaS 管理门户中拥有更多清单。

除非组织定义规范的所有权和生命周期流程，否则这些清单将彼此不一致。发现工具应为该流程提供输入，而不是制造并行的事实来源。

令牌兼容性是另一个问题。OAuth 可以标准化授权机制，但供应商在身份声明、委派证据和运行时策略控制方面可能存在差异。

代理间通信提高了风险。第一个代理可能携带用户的委派权限，而下游代理则以应用权限自主运行。

授权链必须显示权限在何处发生了变化。否则，已获批准的用户请求可能在未被察觉的权限升级中变成广泛的机器操作。

采购团队应根据真实工作流测试产品。精美的目录界面远不如平台能否撤销每个受影响连接器中的访问权限重要。

他们还应测试可导出性。审计数据必须能够用于事件响应、合规和迁移，而不能依赖某一种专有调查视图。

安全团队应避免仅为了提升可见性，就向新的代理平台授予不受限制的访问权限。发现架构本身也需要接受最小权限审查。

因此，市场正朝着将身份作为共享基础设施的方向发展。最终的赢家不会只是登记代理。

它们将跨平台保留归属信息，减少长期有效的凭据，支持细粒度撤销，并在外部工具可评估的记录中呈现策略决策。

企业在扩大 Agent 部署规模前应验证什么

下一阶段的衡量标准将是部署证据，而不是有多少供应商反复宣称“第一等身份”。

第一个信号是，企业是否建立了涵盖影子 Agent 的完整清单。仅通过正式接入流程填充的目录，会遗漏风险最高的部署。

组织应将身份记录与 OAuth 授权、云资源、浏览器遥测、API 使用情况及 SaaS 配置进行比对。存在较大缺口将削弱“身份优先”的承诺。

第二个信号是，短期、限定范围的授权是否正在取代静态密钥。迁移数量比平台为新 Agent 签发现代令牌的能力更重要。

团队应识别使用内嵌 API 密钥、共享服务账户和长期有效刷新令牌的现有 Agent，随后衡量这些凭据消失的速度。

Microsoft 的文档为企业提供了一个技术参考点。其生产环境指南更倾向于使用联合凭据和托管身份，而非存储的客户端密钥。

第三个信号是，运行时控制能否在跨平台委派中持续有效。这将决定 Agent 身份会成为真正的基础设施，还是又一个孤立的产品类别。

一个实用测试可从一项触发多个 Agent 和工具的人工请求开始。调查人员应能在不手动关联无关日志的情况下，还原完整链路。

记录应标明发起人员、每个参与的 Agent、每一次令牌交换、所应用的策略，以及每项受影响的资源。

撤销也应能沿同一链路生效。禁用发起 Agent 后，不应仍有被委派的凭据或下游会话处于活动状态。

企业还应开展对抗性测试。红队可以在获授权 Agent 预期要检索的内容中植入恶意指令。

测试应揭示：在模型接受这些指令后，外部策略是否能阻止危险操作。仅有身份本身无法带来这一结果。

业务领导者需要一套判断可接受自主程度的决策框架。并非每个 Agent 都需要相同级别的审查，因为其后果可能存在巨大差异。

读取公开文档的研究助手，与编辑生产代码的 Agent 面临的风险不同。应付账款 Agent 则引入了另一类风险。

访问审查应反映这些差异。高影响力 Agent 需要更短的认证周期、更严格的限制、更强的监控，以及明确的人类审批节点。

事件响应计划必须将 Agent 纳入行为主体。团队应了解如何暂停身份、使令牌失效、隔离连接器、保留日志，以及识别受影响的数据。

该计划也应覆盖遭到入侵的第三方 Agent。即使企业内部代码从未被攻破，预先授予的 OAuth 信任仍可能带来风险。

安全团队应询问供应商：他们披露连接器遭入侵的速度如何，以及撤销已签发访问权限的速度如何。合同条款应涵盖日志、通知和调查支持。

开发者在设计阶段需要更清晰的标准。每个新 Agent 都应声明其所有者、工具、数据类别、授权模式，以及允许造成的最大后果。

这些信息可以成为内部 AI workflow 记录的一部分。产品、安全和工程团队随后便可根据最初目的审查变更。

这则 Google News 内容提供了一个有用的检查点，但不应将反复提及误认为问题已解决。身份提供商对问题的界定，比企业对答案的实施更清晰。

这三个问题构成了一次实用的初步审查。你的组织能说清每一个 Agent 吗？能绘制每一个可访问系统的映射吗？能限制并还原每一项重大操作吗？

回答“可以”需要目录、令牌、策略和日志提供证据。为审计而维护的电子表格，并不能证明运行时控制能力。

从一个生产工作流开始，追踪从人工意图到最终影响的全过程。移除共享凭据，收紧每一项连接，并明确自动操作必须停止的位置。

随后在压力下测试撤销和还原能力。若任一项失败，说明该 Agent 拥有超出组织可安全解释范围的自主权。

Google News 很快会转向另一条头条。身份缺口仍将存在，直到企业能够将每一项 Agent 操作都关联到受限权限、明确所有权和可执行策略。