AI Agent 生命周期风险暴露传统企业安全缺口

Google News 推送了一篇发表于 7 月 22 日的 Hacker News 分析文章，其中发出明确警告：企业部署 AI Agent 的速度，已超过身份控制措施跟进的速度。

报告指出，Agent 会继承权限、跨越应用边界，并在并非每一步都获得人工批准的情况下作出决策。这种组合造成的冲突，并非传统身份与访问管理体系所能应对。

核心问题不在于 AI 模型是否给出错误答案，而在于一个软件身份能否将该答案转化为获授权的操作。Agent 可能查询数据库、修改客户记录、发送消息，或将工作委派给另一名 Agent。

这改变了安全问题的定义。组织过去会问，某个用户是否应当访问某个应用；如今则必须决定，某个 Agent 能否追求某一目标、使用特定工具、继续传递权限，以及在其用途发生变化后是否仍应保留访问权。

Hacker News 分析文章将这一问题描述为身份生命周期失效。该观点颇具时效性，但它也部分属于由供应商支持的专家评论，而非独立的安全事件调查。

其背后的担忧获得了更广泛的支持。NIST、OWASP 和 Cloud Security Alliance 均已发布相关研究，涉及 Agent 身份、授权、委派、过度自主性及生命周期治理。

正在形成的共识令企业采购方感到不安：更好的模型并不会自动带来更安全的 Agent。安全性取决于围绕这些模型构建的身份、凭据、策略、工具、记忆与审计系统。

Google News 聚焦的核心问题

该报告将 AI Agent 安全重新定义为持续性的身份问题，而非一次性的应用审批。

传统应用通常通过可预测的代码路径运行。管理员分配权限，开发人员定义预期操作，安全团队监控可识别的事件。

AI Agent 增加了一个概率性规划层。它会理解目标、选择中间步骤、挑选工具，并在条件变化时调整计划。在这一语境中，Agentic AI 指的是能够在有限人工指导下，为实现目标自主决策并采取行动的软件。

这种区别至关重要，因为授权往往发生在完整的操作序列尚未明确之前。用户可能要求 Agent 对某个账户进行核对。Agent 可能检查记录、调用外部服务、生成文件，并发送结果。

每一次单独的工具调用都可能获得许可，但完整的操作序列仍可能造成不安全的结果。

Hacker News 文章指出了多种实际失效模式，包括权限范围过大的长期令牌、拥有比编排器更广泛访问权限的受委派 Agent，以及在生命周期变化后仍然有效的凭据。

这些并非孤立的模型缺陷，而是组织在创建、识别、授权、监控、修改和退役软件行为主体方式上的薄弱环节。

NIST 在征集有关 Agent 安全的公众意见后得出了相近结论。其 2026 年 5 月发布的安全响应分析发现，各方普遍认同现有网络安全原则依然适用；但受访者也表示，这些原则需要针对 Agent 进行调整。

这一发现避免了轻率的过度反应。企业无需抛弃身份管理、安全开发、日志记录或事件响应；它们需要将这些控制措施应用于那些会在执行过程中改变计划和工具选择的系统。

Google News 此次并未披露某一项新发现的漏洞，而是放大了一项更具结构性的警告：企业正在将 Agent 接入运营系统，而它们尚无法可靠追踪每一个身份、权限、委派关系及由此产生的操作。

这一缺口才是真正的事件。Agent 部署已足够深入业务工作流，以至于生命周期安全正从研究议题变成运营要求。

这一时点也反映出更广泛的标准转变。NIST 于 2026 年 2 月启动 AI Agent Standards Initiative，而 OWASP 于 2025 年 12 月发布了专门针对 Agentic 应用的风险框架。

这些工作表明，Agent 安全已超出通用聊天机器人的指导范畴。聊天机器人会生成内容供人审阅；Agent 则可以将生成的内容转化为跨互联系统的变更。

这种差异提高了错误的代价。幻觉式回答通常是信息质量问题；而利用有效凭据执行的幻觉式计划，则会成为安全和业务流程问题。

因此，重要的问题不只是 Agent 知道什么，还包括它能接触什么、能改变什么，以及这些操作是否能够撤销。

身份系统面临 Agent 速度下的治理缺口

以人为中心的访问审查，无法跟上那些能在自动化工作流中出现、改变角色并委派权限的 Agent。

传统身份治理遵循一套熟悉的生命周期：人员加入组织、获得访问权、变更角色、接受定期审查，最终离开组织。

服务账户使这一模式变得更加复杂，但它们仍然相对静态。团队可以将账户关联到某个应用、分配凭据，并记录稳定的用途。

AI Agent 更难被限制在这种结构之中。持久型 Agent 可以在不同会话之间维持记忆和集成；临时 Agent 则可能仅存续到完成一项任务为止。

编排器还可以创建子 Agent。这些子 Agent 可能使用不同的模型、工具或凭据，从而形成会在工作流运行期间变化的委派链。

每个参与者都会成为非人类身份，也就是无需作为人类即可进行认证和行动的软件主体。其身份所涵盖的内容必须超过名称或 API 密钥。

安全团队需要了解是谁创建了 Agent、哪位人员发起任务、获批用途是什么，以及可使用哪些工具。他们还需要掌握 Agent 当前使用的模型、版本、记忆边界和受委派权限。

Cloud Security Alliance 的Agent 身份框架将 Agent 身份描述为一个动态档案，涵盖来源、用途、能力、行为、关系和证明。

这种方法暴露了静态凭据的弱点。令牌可以确认调用方持有某个秘密，但无法独立说明 Agent 当前目标是否与获得访问权时的用途相符。

这在身份与意图之间形成了授权缺口。

假设一名员工授权 Agent 汇总客户反馈。Agent 可能需要读取问卷回复和支持工单，但不应自动获得修改客户账户或发送外部消息的权限。

权限宽泛的服务账户可能抹去这些边界。如果 Agent 在工单中遇到恶意指令，提示注入可能会改变其行为，而同一组凭据仍然有效。

提示注入是指模型处理的内容中进入了敌对指令。该输入可以影响 Agent 的计划，即使它并未利用传统软件代码中的漏洞。

最小权限可以减少损害，但前提是将其落实到操作层面。一个仅需为单项任务读取某个数据集的 Agent，不应获得对所有已连接存储库的永久访问权。

委派让问题变得更难。编排器可能将任务交给专用 Agent。如果第二个 Agent 拥有更广泛的权限，第一个 Agent 就能间接访问其从未获得授权的系统。

这类似于权限提升，但路径发生在正常的编排流程中。每一次认证事件看似都合法，而整体权限链却可能违反策略。

组织还需要保留用户上下文。如果员工无法访问某项财务记录，代表该员工行动的 Agent 也不应通过自身的服务身份获得访问权。

原始人员的访问限制必须在每一次交接中随任务传递。否则，Agent 就会成为绕过用户级授权的机制。

这给首席信息安全官、身份团队、平台工程师和应用所有者带来压力。没有任何一方能独自解决这一问题。

身份团队负责凭据和策略；平台团队决定工具连接；开发人员塑造 Agent 行为，而业务所有者定义可接受的结果。

由此形成的应对方式是共享控制模型。每个生产环境 Agent 都需要明确的负责人、声明用途、限定范围的权限、可追溯的委派关系，以及到期或审查事件。

仅靠文档无法跟上节奏。生命周期控制必须与部署流水线集成，确保 Agent 没有所有权与授权元数据就无法进入生产环境。

这类似于基础设施即代码已经采用的规范。团队应将 Agent 身份和权限视为版本化配置，与模型、提示词、工具和应用代码一同接受审查。

真正的权衡是自主性与约束

Agent 获得更多工具和决策权后会变得更有用，但这些能力同样会扩大操纵或错误造成的损害。

组织采用 Agent，是因为它们能够完成多步骤工作。只能起草文本的助手带来的运营风险有限；能够获取数据、更新记录并进行外部沟通的 Agent 则能提供更高价值。

但它也带来了更大的影响范围。

这种权衡不只是安全与便利之间的取舍，而是自主性与约束之间的取舍。每增加一种工具，可达成结果的范围就会扩大，其中也包括设计者未曾预料的结果。

OWASP 的Agentic 风险框架由超过 100 名专家、研究人员和从业者共同参与制定。它涵盖目标劫持、工具滥用、身份滥用、记忆投毒、不安全的 Agent 间通信和级联故障等风险。

这些类别说明，仅保护基础模型并不足够。模型处于一个更大的执行系统之中。

记忆可能保留不可信内容。工具可能暴露具有破坏性的功能。Agent 间消息可能传递错误上下文。有效凭据可能授权不安全的步骤。

完整系统决定了模型错误最终只是糟糕建议，还是演变为运营事件。

设想一个帮助工程师调查生产故障的 Agent。它需要日志、监控数据、代码上下文，也可能需要访问部署工具。

只读访问能以有限影响支持诊断。部署权限允许 Agent 尝试修复，但错误的计划如今可能改变线上系统。

在生产变更前加入人工审批可以降低这一风险，同时也会限制 Agent 原本吸引人的速度与自主性。

这并不意味着每项操作都需要人工参与。低风险、可逆的任务可以获得更广泛的自主权；高影响或不可逆的操作则应设置更严格的关卡。

一项有用的策略应按后果区分行动。读取公开文件不同于导出客户数据。创建草稿不同于将其发送出去。建议修改配置不同于实际应用修改。

同样的区分也应体现在凭证上。短期、任务范围限定的授权，可限制已遭入侵的智能体可用的时间与资源。

静态密钥则会造成相反的局面。它们可能在任务结束后仍然存续、出现在日志中，或继续绑定在已废弃的实验上。

工具设计与凭证设计同样重要。智能体应获得编码了业务限制的狭窄功能，而非直接访问通用管理界面。

例如，受约束的退款功能可设置金额上限，并要求提供交易标识符。宽泛的数据库写入权限，则要求模型仅靠推理来遵守这些规则。

智能体还需要事务性保障。试运行可在执行前展示计划中的变更。可逆操作可保留恢复路径，而确认关卡能够阻止不可逆的变更。

审计记录必须捕获的信息不能仅限于最终的 API 调用。调查人员需要知道发起用户、智能体身份、策略决策、工具请求、被委托的参与方，以及最终产生的状态变更。

自然语言推理轨迹需要谨慎处理，因为其中可能包含敏感数据，也未必能可靠解释模型行为。结构化事件记录能提供更可靠的安全追踪线索。

系统应记录请求了什么、策略允许了什么、执行了哪个工具，以及发生了哪些变更。这些事实比一段解释智能体为何行动的生成式叙述更重要。

这种方法同样能保护知识工作流。使用可检索知识库的团队，应将信息检索与修改源系统的权限分开。

智能体可以协助定位内部上下文，而无需获得编辑每个已连接代码库的权限。这一边界既保留了大部分收益，也限制了行动风险。

隔离无法消除不确定性。模型仍具有概率性，而攻击者可以寻找会产生意料之外计划的输入。

实际目标是让不安全路径变得困难、可见、受限且可恢复。只有在这些保障措施经过真实工作流测试后，才应提高自主程度。

生命周期控制必须经受住智能体的每一次变更

创建只是第一个安全检查点，因为智能体的用途、工具、模型、记忆和权限都可能在之后发生变化。

许多组织将审查重点放在上线阶段。团队批准一个智能体，配置凭证，检查其初始工具，并将其投入生产环境。

这一流程假定获批系统会保持稳定。但智能体很少如此。

模型更新可能改变工具选择。新的集成可能扩大可访问的数据范围。修改后的提示词可能改变智能体对自身角色的理解。

持久记忆会随着时间引入新的上下文。业务团队也可能在不重复原始安全审查的情况下，将智能体改作他用。

每一次变更都可能使此前的授权决定失效。因此，生命周期管理必须将访问权限与智能体的当前配置相连接，而不仅仅是其最初注册信息。

NIST 于 2026 年 2 月发布的身份概念论文，重点探讨如何将身份标准与最佳实践应用于软件和 AI 智能体。

该论文就身份识别、授权、审计、不可否认性以及针对提示注入的防御措施征求意见。这一范围反映出多个控制层必须协同运作。

注册应创建一条唯一的智能体记录，其中包含人工负责人、业务用途、获批环境和明确的到期时间。在这些字段齐备之前，访问应保持阻断状态。

配置过程应签发适合任务的凭证，而不是复制开发者的权限。密钥应避免硬编码存储，并支持自动轮换或到期。

部署应将获批身份绑定至某个特定版本的智能体配置。重大变更应触发新的评估和访问认证。

运行需要持续监控。安全团队应发现异常工具调用序列、意外的数据去向、异常委托，以及超出获批用途的活动。

事件响应必须支持在所有已连接系统中立即撤销权限。如果令牌、服务账户或被委托身份仍处于活跃状态，仅禁用可见的智能体界面是不够的。

退役是最后一道考验。未使用的智能体可能遗留凭证、触发器、记忆存储、集成以及下游权限。

如果这些组件仍然存在，智能体就并未真正消失。它已成为一个所有权不明且可能仍具有效访问权限的孤立身份。

这种风险很容易被忽视，因为不会有员工抱怨账户失效。休眠的软件访问权限可能静默存在，直到攻击者发现它。

完整的停用应撤销凭证、停止定时触发器、禁用入站请求、移除工具连接，并对存储的上下文应用组织的数据保留规则。

随后，团队应确认下游系统不再接受已退役身份。关闭工单并不能证明权限已被撤销。

困难之处在于规模。人工电子表格无法可靠追踪那些通过自动化开发系统不断出现和变化的智能体。

组织需要一个与部署和身份基础设施相连接的清单。每个智能体都应可按负责人、用途、环境、工具集、凭证集和当前生命周期状态被发现。

该清单也支持事件分析。安全团队可以查询哪些智能体使用了已遭入侵的连接器、继承了存在漏洞的工具，或仍在运行过时的模型配置。

然而，清单并不等于控制。仪表板可以揭示一个权限过大的智能体，却无法阻止它的下一次行动。

最强的生命周期系统会使访问权限取决于当前策略。缺少负责人、用途已过期或配置变更未经批准，都应自动限制执行。

将供应商声明视为既定证据同样存在风险。Hacker News 的文章提出了连贯的身份安全论证，但其建议仍应在每个组织自身的架构中加以验证。

企业在构建、认证和连接智能体的方式上各不相同。临时编码智能体与具有持久记忆的客户服务智能体面临的风险不同。

控制措施应遵循实际能力和后果。对每个智能体套用同一套治理模板，可能只会增加文书工作，而不会降低最高风险。

安全团队需要基于场景的测试。他们应评估：当智能体收到恶意内容、发生意外委托、失去负责人，或在退役后仍保留凭证时，会发生什么。

红队演练应测试完整工作流，而不是孤立的提示词。若另一条工具路径仍能触及同一敏感操作，拦截一次注入的意义就很有限。

目标是可衡量的隔离能力。团队应了解策略是否能阻止未授权行动、警报是否及时到达，以及是否能在所有集成中撤销凭证。

三项信号将表明智能体安全是否正在迎头赶上

下一阶段将取决于可执行的标准、部署证据，以及对智能体身份可衡量的控制。

第一个信号是 NIST AI Agent Standards Initiative 提供的具体指导。NIST 表示，该计划将涵盖互操作性、身份基础设施、认证和安全评估。

详细的参考架构将强化这样一种观点：智能体身份需要独立的控制措施。缺乏实施指导的模糊原则，会让企业依赖彼此竞争的供应商模型。

最有价值的交付成果应定义人类意图如何通过委托传递。它们还应说明智能体请求访问时提供何种证据，以及系统如何验证这些证据。

这一信号很重要，因为碎片化标准会制造薄弱环节。一个平台可以签发详尽的智能体身份，而另一个平台可能将其简化为可重复使用的持有者令牌。

第二个信号是组织如何落实 OWASP 的智能体风险。发布 Top 10 能够建立共同语言，但落地仍需要工程变更。

买方应关注智能体平台是否在工具调用层面提供策略控制。他们还应考察其是否支持短期凭证、受约束的委托和不可变的行动日志。

安全评估应超越仅测试提示词的阶段。一项有意义的测试必须观察被操纵的输入是否能在完整工作流中导致未授权的状态变更。

可复现测试的证据将强化“自主性能够安全扩展”的论点。若仍持续依赖宽泛的服务账户，则表明部署依然走在治理之前。

第三个信号是来自企业环境的生命周期数据。安全负责人需要先获得基础衡量指标，才能宣称自己具备控制能力。

这些指标包括：拥有明确负责人的智能体、具有获批用途、到期日期和范围限定凭证的智能体所占比例。团队还应追踪自己能多快撤销与某个智能体关联的全部凭证。

覆盖范围比警报数量更重要。如果组织中一半的智能体仍未被发现，再完美的监控策略也难以提供多少保护。

同样的原则适用于退役。组织应测试已停用的智能体是否失去所有已连接应用中的访问权限，而不只是主要平台的权限。

随着智能体部署扩散，Google News 将持续推送警示，但买方应跳出新闻周期看问题。决定性证据将来自真实系统内部的授权行为。

企业能否将每一项智能体行动追溯到某个人和已获批用途？能否在执行前阻止不安全的委托？

当智能体角色变化时，企业能否修改权限？能否完整退役该身份，而不遗留令牌、记忆或集成？

这些问题为开发者、安全团队和企业买方提供了实用标准。它们将对 AI 风险的广泛担忧转化为可观察的控制措施。

若将 Hacker News 的论点理解为生命周期警告，而不是现有每个身份系统都已失败的证据，它的说服力最强。传统控制仍然不可或缺，但它们需要更快的触发机制和更丰富的上下文。

组织应从后果最严重的智能体开始。识别这些智能体可以改变什么、使用哪些凭证，以及权限如何在每一次交接中流转。

然后测试一个令人不安的场景：如果智能体今天遭到操纵，组织能否控制其行动并彻底移除其访问权限？

如果答案不明确，部署就已经走在治理之前。