Agentic AI 正迫使 Zero Trust 面对身份危机

Agentic AI 登上 Google News 时带来了一个鲜明论断：自主系统正在将 Zero Trust 网络安全“颠倒过来”。Breaking Defense 的标题指出了一个真实矛盾，尽管其背后的具体细节仍难以独立核实。安全团队围绕人员、设备和可预测的应用程序构建访问控制。如今，AI agents 在以委托权限行事时，模糊了这三类边界。

这并不意味着 Zero Trust 已经过时。它改变的是组织必须验证什么、验证频率，以及每项操作究竟由哪个身份执行。一个 agent 可以理解目标、选择工具、读取外部内容、调用 API 并修改数据。其行为并不能完全由分配给其人类所有者的权限所涵盖。

结果形成了一种令人不安的反转。Zero Trust 假定每一项请求都应接受评估，而 agentic 工作流会以机器速度生成长长的请求链。因此，核心较量并非 agentic AI 与 Zero Trust 的对立，而是静态访问控制与对自主行为进行持续控制之间的较量。

Google News 的论断指向一场真实的安全变革

关键变化不在于 AI 能够访问企业系统，而在于它获得访问权限后能够决定下一步做什么。

传统软件遵循开发者预先定义的路径。它可能包含漏洞、接受恶意输入，或暴露存在弱点的接口。然而，防御方通常可以将其预期功能映射到既有账户、进程和网络连接上。

Agentic AI 在用户指令与最终操作之间增加了一层决策能力。一个 agent 可以将宽泛目标拆解为更小的任务、在可用工具中作出选择，并在一条路径失败时进行调整。NIST 将现代 agents 描述为通用模型与软件的结合，后者使其能够操纵文本生成以外的工具。

这些工具可能包括浏览器、数据库、日历、代码解释器、本地文件和管理界面。NIST 的工具使用分类法区分了只读访问、受限写入访问和不受限写入访问，也区分了可信环境与不可信环境。

这种区分很重要，因为单个 agent 往往会在一次任务中跨越多个类别。它可能读取一封邮件、提取客户编号、查询内部数据库，并更新一条支持记录。单独审查时，每一步看起来都可能是被允许的。

但组合后的工作流仍可能产生不安全的结果。攻击者可能在邮件中植入隐藏指令。agent 可能将这些指令理解为任务的一部分，随后利用合法权限泄露数据。

这种攻击被称为间接提示注入，即恶意指令通过 agent 所处理的内容传入。攻击者不需要员工的密码，而是瞄准 agent 对可信与不可信信息的解读。

Google News 的标题通过“颠倒过来”这一表述捕捉了这种转变。过去，安全团队担心人员会滥用软件或交出凭证。现在，他们还必须考虑那些会解读人员权限、并在其权限范围内独立行动的软件。

这并不只是又一个进入网络的端点。端点通常具有相对稳定的功能、安全状态和归属模式。agent 则可以在保持相同身份、凭证和连接的同时改变即时计划。

这带来了可见性问题。日志可能显示一个有效服务账户访问了数据库，却未必能揭示是谁发起了任务、哪个 agent 制定了计划，或哪项外部输入影响了这一决策。

这一标题仍应被视为一种论点，而非某次具体泄露事件的证据。所提供的 Google News 条目并未附带经过验证的事件细节。不过，更广泛的安全问题得到了公开研究和当前标准制定工作的支持。

安全团队不再只保护人与应用之间、应用与应用之间的访问。他们必须保护一条连接人员、agent、模型、多个工具和多种数据源的链条。每一次交接都可能造成信任泄漏。

Zero Trust 是为请求而非开放式目标构建的

Zero Trust 仍然适用，但其传统的控制单元对于自主工作而言过于狭窄。

NIST 于 2020 年发布了其基础性的Zero Trust 架构。该模型拒绝基于网络位置或资产归属的隐式信任。身份验证和授权在会话访问企业资源之前进行。

该架构关注资源，而非传统网络分段。它假定网络可能已经遭到入侵。因此，访问权限应始终限于完成特定任务所需的最小权限集合。

这种方法应对了旧有的边界安全模型。在边界安全模式下，经过认证的用户进入可信网络后往往能获得广泛访问权限。攻击者在攻破一个账户或设备后，便可在系统间横向移动。

Agentic AI 并未使这些原则失效。事实上，当机器能够快速执行大量操作时，最小权限和持续评估会变得更加重要。难点在于，如何将宽泛的用户目标转化为可执行、短时有效的权限。

设想一个 agent 被要求编制季度客户风险报告。该任务听起来只是信息处理，但完成它可能需要多项能力。agent 需要定位记录、关联数据、计算趋势并生成文档。

agent 是否应在整个任务期间获得所有客户记录的访问权限？任务结束后是否应保留这些权限？它能否通过电子邮件发送报告，还是应要求单独批准？

传统访问系统可能会依据用户已有角色回答这些问题。如果员工可以读取数据库并发送邮件，agent 就会继承这两项权限。这种继承很简单，但会造成过度授权。

agent 可以执行员工从未打算进行的操作组合。它也能以人工工作流很少达到的规模重复这些操作。一个小小的解读错误，可能演变为数百次数据库查询或消息发送。

开放式目标让策略设计更为困难。“查找相关证据”并未说明应搜索哪些存储库。“解决问题”也没有界定 agent 能否退款、修改账户或执行代码。

Zero Trust 通常根据身份、设备健康状况、资源敏感度和环境上下文评估访问请求。Agentic 系统增加了另一个问题：这项操作是否仍与当初授予访问权限的任务保持一致？

这一问题需要具备意图感知能力的控制措施。这类控制会将操作与 agent 被分配的目的、当前计划及获批策略进行对照。它们不能仅依赖于某个账户在技术上是否持有权限。

在多 agent 协作中，安全边界也会发生移动。一个 agent 可能将研究任务委托给另一个 agent。第二个 agent 可能调用第三方服务，而该服务返回含有新指令的内容。

每次交接都可能改变上下文，同时保留表面上的授权。静态策略看到的是获批身份在传递数据。行为策略则必须判断整条链路是否仍服务于最初目标。

这正是为什么 agentic AI 安全不能止步于网络分段。控制平面必须理解身份、任务、工具、数据血缘和操作历史，还必须保留这些关联，以供后续调查。

Zero Trust 最初的承诺依然成立：绝不能仅仅因为某个对象已在内部，就授予其信任。Agentic 工作流只是揭示了，“内部”可以描述上下文窗口、委托任务或工具链，而不再仅仅指网络。

AI Agents 需要与其所有者分离的身份

如果每一项操作都显示在某个人类账户或共享服务账户之下，组织就无法有效治理自主 agent。

身份是企业安全团队面临的首个压力点。人员拥有雇佣记录、管理者、岗位角色和离职流程。应用程序则拥有所有者、发布流程和服务账户。

Agents 兼具两类实体的特征。它们可以从人员那里接收目标，但通过软件执行操作。它们可能短暂地运行以完成一项任务，也可能作为持续运行的数字员工存在。

将 agent 视为应用程序内部的隐藏功能，会掩盖问责关系。将其视为普通员工，同样会制造虚假的安全感。agent 需要拥有一等机器身份，并关联其所有者、用途和部署信息。

这一身份不应取代发起操作的用户身份。两者都应在整个工作流中得以保留。调查人员需要知道是谁请求了某项操作，以及由哪个 agent 执行。

一条有用的审计记录还应捕捉所涉及的模型、工具、策略和数据源。缺少这一上下文时，数据库日志只会显示最终访问行为，无法解释 agent 为何认为该访问是恰当的。

安全团队应避免在 agent 部署中使用共享凭证。共享账户会妨碍可靠归因，并使撤销权限变得复杂。它们还会让被废弃的 agent 在原始项目结束后仍保持活跃。

Agent 身份需要生命周期管理。创建时应明确可问责的所有者和获批用途。定期审查应确认该 agent 仍有存在必要，其权限仍与用途相符。

到期机制同样重要。临时 agent 应在任务或项目结束时失去访问权限。持续运行的 agent 应接受定期重新认证，如同特权人类账户一样。

权限也应针对具体任务并保持短时有效。编制报告的 agent 可以获得对选定记录的临时读取权限。向组织外发送该报告则应要求单独权限或人工确认。

这种设计能够减少权限蔓延，即身份逐渐积累不再符合其职责的访问权限。员工的权限蔓延本就难以处理。自主 agents 会放大这一问题，因为团队可以迅速创建它们。

因此，agent 发现成为一项运营要求。安全团队需要在 SaaS 服务、开发平台、内部自动化系统和第三方集成中建立清单。仅凭采购记录无法识别在既有产品内部创建的 agents。

发现工作必须区分 AI 功能与执行操作的身份。一个仅能读取单份文档的摘要功能，与一个能够搜索驱动器并发送消息的 agent 承担着不同风险。两者可能使用同一个模型。

所有者也应在策略和日志中可见。当 agent 的行为偏离预期时，响应人员需要找到能够暂停它的个人或团队。匿名自动化会在事件处理中造成延误。

组织已经为服务、工作负载和机器使用非人类身份。Agent 身份是在延续而非替代这一纪律。区别在于，策略必须考虑同一分配角色内部的可变行为。

主要安全厂商正朝这一方向推进。Cisco 在其代理安全更新中宣布了代理发现、代理式身份控制和 Model Context Protocol 执行机制。Model Context Protocol，即 MCP，用于连接模型、工具与外部数据。

厂商公告并不能独立证明这些控制措施在每一种部署中都有效。但它们确实表明了竞争的方向。身份平台、访问代理和安全网关都希望成为代理流量的控制点。

企业采购方不应将单一网关视为完整解决方案。NIST 长期以来一直指出，没有任何一家供应商能够提供完整的零信任架构。代理式安全增加了更多组件，也带来了更多执行不一致的可能性。

眼下的压力主要落在身份与访问管理团队身上。他们必须支持快速创建的机器行为主体，同时避免重演失管服务账户的问题。静态角色分配将不足以应对。

代理劫持暴露了静态权限检查的局限

即使代理已通过正确认证，仍可能执行错误操作，因为认证并不会验证其推理过程。

重构零信任体系的最有力理由来自代理劫持研究。2026 年 3 月，NIST 公布了一项大型公开红队竞赛的结果，覆盖 13 个前沿模型。超过 400 名参与者进行了逾 25 万次攻击尝试。

每个受测模型至少都发现了一种成功的劫持攻击。不同模型的抵抗能力各不相同，但能力水平并不能持续预测安全性。部分攻击类别还能在不同模型和场景之间迁移。

这些结果并不意味着每个已部署的代理都很容易被攻破。竞赛会吸引攻击者集中投入，也未必能复现所有生产环境控制措施。但它表明，仅凭模型层面的抵抗能力不能成为安全边界。

NIST 将代理劫持定义为：攻击者将恶意指令置入代理所处理的数据中，从而将代理引向有害行为。潜在后果包括数据外泄或恶意代码执行。

关键在于，代理往往使用的是有效工具和凭证。防火墙可能看到的是获批连接，身份系统可能看到的是已认证账户。危险步骤发生在代理对内容的理解过程中。

这使静态允许列表并不完整。允许代理读取电子邮件和更新数据库可能是其工作所必需的，但策略仍必须防止某封邮件重新定义数据库工具应执行的操作。

相关红队研究结果支持纵深防御。模型需要评估，但部署还需要受限工具、数据边界、监控与审批节点。

工具权限应反映后果，而非便利性。读取公开网页与运行下载的代码，风险并不相同。查询客户记录与删除或导出该记录也截然不同。

高影响工具应仅暴露范围狭窄的操作。需要安排会议的代理不应获得不受限制的邮箱控制权。起草付款的财务代理也不应同时拥有审批和发送付款的权限。

这一原则称为职责分离。它防止单一身份控制敏感流程的每一个步骤。即使自动化让权限整合看起来颇具吸引力，代理式系统也需要同样的分工。

在不可逆的边界上，人工审批仍然很有价值。转账、删除、对外发布、生产部署和凭证变更都应接受明确检查。审批界面应显示预期操作及相关上下文。

一个笼统的“允许”按钮几乎无法提供保护。审核者需要知道是哪一个代理请求了操作、它使用了哪些数据，以及批准将产生什么结果。否则，自动化只是把社会工程攻击搬到了审批界面。

监控应聚焦行为变化。一个代理突然访问陌生代码库，可能表明其遭到劫持或规划出现故障。反复失败的工具调用则可能意味着代理正试图探查超出自身角色的范围。

速率限制也能降低错误造成的损害。以机器速度执行，可能让一次错误决策迅速演变为大范围事故。限制操作量可为监控系统和响应人员争取干预时间。

沙箱仍然有价值，但不应因此产生安全假设。代理即使不逃离其运行环境，也可能造成损害。将已获授权的数据发送至错误目的地，未必需要任何软件漏洞利用。

核心的不确定性在于：意图感知系统能否在不阻碍有用工作的前提下做出可靠决策。代理计划会变化，业务任务充满模糊性，策略也无法预判每一种合理例外。

过于严格的控制会造成持续不断的审批请求。团队随后可能为了恢复生产效率而授予更广泛的权限。这种做法重现了零信任原本要消除的隐性信任。

过于宽松的控制则会带来相反的失败。代理运行顺畅，直到恶意输入或规划错误利用了其权限。安全团队必须同时衡量被阻断的工作和不安全操作。

这种权衡使得“代理式零信任”产品已经解决问题的说法站不住脚。产品演示通常展示经过挑选的工作流。真实部署中则存在遗留系统、共享身份和不一致的日志。

近期最可信的方法是分层防护。为每个代理赋予身份，限制每个工具，保留发起用户信息，验证具有重要后果的操作，并监控行为。应假定模型防护措施有时会失效。

竞争正在转向控制平面

安全厂商正竞相介入代理行为，而企业仍缺乏一套通用模型来证明这种介入是否有效。

代理式 AI 为身份提供商、网络安全厂商、云平台和专业 AI 安全公司创造了机会。每一类厂商控制着工作流的不同部分，但没有任何一方天然能看到完整链路。

身份厂商知道谁获得了访问权限。网络平台观察系统之间的连接。云提供商可以监控工作负载和 API 调用。AI 安全工具则检查提示词、模型输出和工具请求。

最有价值的位置是策略决策点。在零信任架构中，该组件负责评估访问请求，并决定是否允许执行。代理式系统让这一决策更加复杂，也更具争议。

网络厂商可能认为，代理通信应通过安全代理。身份厂商可能将策略重点放在机器身份和委托授权上。AI 安全提供商则可能优先考虑提示词检查和行为评估。

这三种观点都包含部分答案。网络上下文无法揭示每一条恶意指令。仅靠提示词检查无法阻止一条被拦截的数据库查询。身份验证也无法保证已认证代理遵循其既定目的。

MCP 已成为一个关注重点，因为它标准化了模型与工具之间的连接。网关可以盘点服务器、限制操作并记录调用。不过，并非每个代理都使用 MCP，而网关也无法治理绕过它的工具。

代理间通信带来了另一项挑战。委托可能跨越模型、厂商或组织边界。接收代理需要获得有关发送方身份、权限和请求范围的证据。

签名消息可以认证发送方，但不能证明发送方的计划是安全的。策略必须区分溯源与授权：前者识别请求来自哪里，后者决定请求是否应继续执行。

标准化工作正开始弥补这些缺口。NIST 于 2026 年 2 月启动了其代理标准倡议。其议程涵盖互操作性、开放协议、安全、身份和可信采用。

这一倡议至关重要，因为组织需要可比较的代理身份与权限表示方式。缺乏通用格式时，每个平台都会创建专有身份和策略信号。安全团队随后将难以跨环境执行控制。

标准本身无法决定风险容忍度。医院、银行、国防承包商和营销机构会对同一工具操作赋予不同后果。互操作性提供的是共同基础设施，而不是通用策略。

Breaking Defense 的表述对高保障环境尤其相关。国防系统通常同时涉及机密数据、任务约束、遗留设备和严格问责。一次自主操作可能带来超出普通办公自动化的后果。

这些环境也带来了自动化压力。分析人员要面对海量告警、文档和传感器数据。代理可以帮助关联信息并执行重复步骤，但更广泛的自主性也提高了对可追溯控制的需求。

因此，竞争应依据证据而非产品术语来评判。采购方需要测试控制措施是否能可靠识别代理、将操作与责任主体绑定、限制工具，并产出可用的审计记录。

他们也应测试故障情形。当身份提供商不可用时会发生什么？代理能否回退至缓存权限？代理是否会在失效时默认拒绝，还是流量会绕过检查？

跨平台覆盖与单项功能同样重要。一个组织可能同时使用某一家云模型、另一家厂商的编程代理以及数个 SaaS 助手。只能看到单一环境的控制措施会留下显著盲区。

市场很可能会向集成平台集中，但集成也会带来自身的集中化风险。一个遭到攻破的策略平面可能影响许多代理。独立日志与执行机制仍是重要保障。

Google News 可能会放大关于代理式 AI 取代熟悉安全模型的标题。更准确的结论要狭窄得多：现有厂商必须将零信任从连接决策扩展至身份、意图和行动治理。

安全团队接下来应关注什么

下一阶段将由可衡量的部署证据决定，而非有关自主安全的更宽泛主张。

第一个信号是，标准组织是否会为代理身份和委托授权制定可用规范。NIST 表示，其倡议将开发研究、指南和其他交付成果。企业应关注能够跨厂商生存的格式。

一项有用的身份规范必须将代理与其所有者、用途、模型和获批准工具关联起来。它还应在委托过程中保留发起用户信息。如果平台采用不兼容的表示方式，治理仍将支离破碎。

第二个信号是独立安全测试。NIST 的竞赛发现，每个受测前沿模型都存在成功攻击，但组织需要部署层面的评估。测试应涵盖模型、工具、权限、记忆和外部数据。

比较测试应衡量的不只是提示词注入是否成功。还应考察代理是否超出任务范围、滥用合法工具，或在冗长工作流中隐藏具有重要后果的操作。它还应测试恢复能力和审计质量。

如果攻击成功率下降，而代理仍保留有用能力，人们对意图感知型控制措施的信心将增强。若改进后的模型在工具丰富的部署环境中依然容易受攻击，基础设施层面的控制将变得更加重要。

第三个信号是企业在试点后的行为。安全团队应追踪有多少代理获得了唯一身份、受限凭证和明确的责任人。他们还应衡量被弃用的代理以及未经审查的权限。

仅看采用数量并不能说明太多。一家公司可以部署数千个代理，同时让它们保持只读和隔离状态。一个拥有广泛生产环境访问权限的代理，风险可能高于这整个人群。

事故报告将提供另一项现实检验。公开案例应说明，故障究竟源于提示注入、权限过度、身份混淆，还是缺失审批边界。没有这些细节，行业就无法比较不同防御措施。

安全负责人应在扩大试点前提出直接的问题：

• 每个代理是否都有唯一身份和可追责的负责人？

• 任务结束后，权限能否自动到期？

• 日志是否同时保留发起请求的人员和执行操作的代理？

• 哪些工具能够造成不可逆的变更？

• 外部内容能否影响这些工具调用？

• 多大的操作量会触发审查或暂停？

• 响应人员能否在不停止整个平台的情况下禁用单个代理？

• 被委派的代理是否受到原始任务的约束？

• 当策略服务不可用时，系统是否默认拒绝执行？

• 审计人员能否还原敏感操作发生的原因？

这些问题将“彻底颠覆”的说法转化为一项实施测试。如果一个平台无法回答这些问题，其 Zero Trust 表述仍不完整。如果能够回答，该架构或许已经在适应变化。

最重要的结论是，组织不应放弃 Zero Trust。它们应将其应用于更小、更动态的权限单元。每个代理、工具调用、委派行为和具有重要后果的操作，都应拥有各自的策略上下文。

这种方法会带来摩擦。一些自动化任务将需要更受限的工具或人工确认。一些试点会放缓，因为团队需要建立资产清单和生命周期控制机制。

另一种选择是隐藏的权限。代理将继承广泛的人类权限、处理不受信任的内容，并留下不完整的记录。届时，安全团队往往只能在事故发生后才发现这些自主工作流。

Agentic AI 并未击败 Zero Trust。它暴露出许多 Zero Trust 项目只停留在身份验证、网络访问或设备态势层面。下一版本必须治理已经通过身份验证的机器决定采取何种行动。

因此，通过 Google News 提出的这个问题值得保留，即使标题夸大了这种逆转：在代理执行下一项操作之前，你的组织能否追踪其身份、目的、证据和权限？

从一个生产工作流开始，从头到尾重建这条链路。如果任何一次交接变得不可见，就应将其视为控制缺口。这项演练比采用另一个安全标签更有价值，因为它检验了 Zero Trust 是否会在实际工作中始终跟随代理。