Vishal Sharma 的零信任警告：AI 智能体需要可验证的控制权

Vishal Sharma 正在质疑一项常见的安全承诺：要求 AI 智能体遵守规则，并不能证明这些规则确实得到执行。Vishal Sharma 的零信任警告聚焦于 AI 智能体——这类系统利用模型和软件工具朝着特定目标采取行动。这位 Queen’s University Belfast 的研究人员提出，当智能体声称已删除信息、遵守某项限制或完成获授权任务时，究竟留下了哪些可供验证的证据。

这一观点促使企业采购方和开发者区分“合作”与“可强制执行的控制”。报告成功的智能体给出的是一个答案；独立记录相关操作的系统，则提供了采购方可以调查的依据。这两种输出应获得不同程度的信任。

其历史参照是 NIST 的零信任架构——一种拒绝仅因网络位置或所有权而自动信任的安全方法。Sharma 的挑战在于：当智能体解读信息、委派工作，并在任务之间传递上下文时，这一原则如何继续成立。核心权衡十分具体：有用的自主性需要访问权限，而可问责的自主性需要即使模型犯错也依然有效的边界。

Vishal Sharma 的零信任警告始于证据缺失

Sharma 获大学支持的智能体安全分析发表于 IEEE Spectrum，对组织如何验证智能体行为提出质疑。其赞助背景很重要：读者应将其视为该机构对讨论的贡献，而非对某个商业安全系统的独立验证。

文章描述了由编排器管理的智能体，编排器是一种协调其任务的软件。文章提出一种可能性：后续提示可能检索到此前已要求智能体遗忘的信息。文章还报告了一项 Queen’s University Belfast 内部实验，其中由智能体编排的去认证攻击耗时两到三秒。去认证攻击会中断设备已通过认证的无线连接。

该文章最有力的贡献在于其对证据的要求，但其实验性主张在支撑广泛结论之前仍需要更多细节。

已发布的内容没有提供足够的方法论，无法确立一个通用的攻击速度基准。其关于上下文恢复的讨论，也没有证明已被物理删除的信息得到重建。工作流中某处仍可访问的信息，与恢复已不复存在的数据，是不同的问题。

这一差异应当影响应对方式。关于遗忘的表述需要定义明确的对象：一条消息、一条存储记录、一份可访问文档，或模型习得的行为。没有这一界定，组织便无法就“成功删除”应呈现为何种状态达成一致。

设想一个假设性的客户画像助手。用户撤回了使用早前访谈内容的许可。该助手确认将忽略该访谈，随后却给出了与早先评估相似的建议。仅凭这种相似性，无法确定助手是检索了访谈内容、保留了摘要，还是独立得出了相同结论。

调查需要检视系统实际保留和访问了什么。生成的解释或许能提供线索，但解释本身无法定论。争议中的行为涉及答案周围的机制，包括哪些记录仍然可用。

对采购方而言，这改变了值得索取的证据。精心设计的演示可以显示助手在预设会话中作出正确回应。受控的失败测试则能揭示某项限制是否经受得住意外请求。这两种演示回答的是不同的采购问题。

新闻价值在于这一重心转变。Sharma 将注意力引向口头承诺转变为操作性主张的节点。一旦智能体处理敏感信息或具有重大影响的行动，这一节点就值得被明确审查。

这也为供应商建立了更公平的标准。供应商不应被要求承诺其模型永远不会产生不理想的回应。它应能够说明其部署的限制，并提供与这些限制相称的证据。

零信任依然适用，但身份无法决定意图

NIST 的零信任架构发表于 2020 年 8 月，其保护重点是资源，而非假定内部网络可信。该框架区分了认证——确认身份——与授权——确定允许的访问权限。

这一框架不会因为软件能够理解自然语言而过时。它提供了一个有用起点：智能体位于组织内部，并不自动意味着它有理由访问组织资源。

分析上的问题在于：经认证的智能体对于当前任务究竟应获得多大权限。

设想一名获授权编制供应商比较报告的助手。阅读已批准的提案符合这一任务。即使同一助手具备发送电子邮件的技术能力，将一份机密谈判简报发送给供应商仍会引出另一个问题。

成功认证能够确认是哪个账户尝试发送，但它本身不能证明用户意图进行该次具体披露。因此，安全讨论还需要审查所请求的操作及支持该操作的权限。

这正是智能体部署令熟悉的企业决策变得复杂的地方。人类指令可以描述结果，而不枚举每一步中间操作。“准备比较报告”留有解释空间。组织仍需决定这种解释可以授权哪些操作。

随之而来的合理采购问题是：当助手选择了非必要步骤时会发生什么？答案应明确负责允许或拒绝该操作的组件。承诺助手通常会选择合理步骤，是在说明行为；而采购方询问的是权限。

同样的推理也适用于委派。假设一名协调助手要求另一名智能体研究供应商历史。这一请求是否附带查阅机密合同的权限？是否允许进一步委派？原始限制中的哪些内容仍对接收服务可见？

这些是假设性的设计问题，而不是指称每个智能体平台都错误处理委派的结论。它们的目的是在采购方授予广泛访问权限前揭示其中的假设。一个部署表面上可能井然有序，却仍让其权限模型缺乏清晰定义。

因此，安全团队面临范围问题。将智能体作为单一应用评估，可能忽略读取、编辑、发送和删除之间的重要差异。手动评估每一项无害操作，则会制造另一种负担。有价值的评估位于这两个极端之间。

因此，产品团队应当预期会被问及任务意图与可执行权限之间的关系。提出这一问题的客户，要求的是一种系统属性，而不只是又一条模型指令。

透过这一视角理解时，Vishal Sharma 的零信任警告最具价值。它敦促组织让自身假设可供审查，同时并未声称现有的所有访问控制原则均已失效。

记忆让这一权衡更难忽视

OWASP 的AI 智能体安全指南讨论了记忆隔离、过期机制、敏感数据处理，以及智能体上下文之外的授权。上下文指模型在生成回应时接收到的信息。

该指南还指出了记忆投毒，即恶意信息持续存在并影响后续行为。这一担忧将保留的信息与未来行动联系起来，而不是将每次回应视为孤立事件。

对企业采购方而言，尚未解决的权衡是：助手应保留多少有用历史，以及在谁持续授权的前提下保留。

设想一个将访谈转化为项目简报的研究工作流。历史笔记能帮助助手避免重复提问并保留既有决策。这些益处为保留信息提供了合理理由，也使撤回请求变得更难评估。

假设一位受访者要求删除一项敏感陈述。采购方需要知道产品承诺的究竟是什么。删除原始转录内容、在未来搜索中排除该内容，以及修订由此派生的简报，都是可区分的结果。

一份有意义的合同应明确适用的结果。演示应直接测试这一结果。询问助手是否记得该陈述，只能提供较弱证据，因为该问题依赖的正是行为存在争议的同一界面。

这一差异同样适用于日常知识工作。选择个人知识库的人，需要了解收集、检索与删除之间的关系。便利性无法回答这些问题，产品类别也不能构成安全保证。

调查与最小化之间也存在张力。组织可能希望保留足够的历史，以解释一项影响重大的建议；同时也可能希望避免保留不必要的个人信息。助手承担工作，并不会让任何一个目标消失。

一个假设性调查说明了其中的困难。一位客户在底层访谈已被删除后，对某项建议提出异议。调查人员需要说明哪些经授权的证据影响了该决定。永久保留每一份原始记录会削弱删除承诺；什么都不保留则会妨碍调查。

其编辑层面的含义是，“记忆”值得更精确的产品语言。采购方应期待了解涉及哪些记录，以及每一类记录附带哪些保证。一个标有“遗忘”的单一开关，为互不兼容的预期留下了太多空间。

商业压力落在那些销售跨项目连续性的供应商身上。这种连续性越有用，其边界对于评估敏感工作的客户就越重要。记忆功能的价值及其治理要求会同步增长。

因此，Sharma 的问题超越了一种罕见的攻击场景。它揭示了一个基本采购问题：在对话结束之后，组织能否验证信息是如何被处理的。

浏览器研究说明了为何架构改变风险尺度

University of Washington 的研究人员 Franziska Roesner 和 David Kohlbrenner 在七种智能体浏览器中研究了浏览器源边界。他们的工作涉及同源策略，这是一项用于隔离彼此不受信任网站的浏览器规则。

他们在 2026 年 4 月的说明中描述了于 1 月下旬和 2 月初进行的实验。报告展示了一种涉及 Agent Mode 下 ChatGPT Atlas 的跨源攻击。对于其他几款产品，报告指出的是攻击前提条件，而非同等程度的已完成攻击。

该场景依赖若干特定条件，包括提示注入成功——即试图让智能体将不受信任的内容当作指令处理。所测试的版本和配置也至关重要。这些发现不应被延伸为对所有当前浏览器版本的无依据论断。

更广泛的架构问题在于，助手所拥有的访问权限，是否创造了普通网站代码本不具备的路径。

对买家而言，这个问题比笼统比较模型智能水平更有参考价值。一个能力强大的助手可能在狭窄的访问边界内运行。另一种部署方式则可能暴露更广泛的信息，同时更依赖助手自身的判断。

即使演示效果看起来相似，这些配置也对应不同的采购决策。两者都可能成功总结页面内容。只有进一步审查，才能揭示每个助手在执行该任务时还能访问哪些额外信息。

设想一名员工要求总结某个公开供应商页面。预期输出仅涉及该页面。如果工作流还允许访问私密业务材料，评估者需要理解这种访问为何存在，以及有哪些机制约束其使用。

员工的请求提供了一个有用的参照点。它界定了业务目的，据此可以评估额外访问权限。一份成功的摘要并不能回答系统是否暴露了超出任务所需的信息。

这也是比较时需要谨慎措辞的原因。研究人员识别出一条可能造成危害的路径，已经确立了值得调查的问题。但这并不必然证明针对所有共享某一设计特征的产品都已实现成功攻击。

买家也应以同样的严谨标准看待供应商回应。一个已修补的案例可以封堵已演示的路径，却不能证明所有相关路径都已消失。反过来，一项较早的研究发现也不应自动被表述为当下尚未解决的漏洞。

当前争论的启示在于方法论。安全声明若能明确受测试的边界、涉及的条件和观察到的结果，就会更具信息价值。仅凭产品名称无法承载这些解释。

这支持 Sharma 对证据的要求，同时增加了一项重要限制：证据应始终与产生它的系统及情境相绑定。要将其延伸到更广范围，需要额外测试，而不是更强烈的修辞。

更好的模型行为无法解决隔离问题

Anthropic 在 2025 年 11 月发布的关于提示注入防御的说明，介绍了面向浏览器使用的训练、检测系统与对抗测试。该公司明确承认，浏览器智能体仍然容易受到攻击。

其在 2026 年 5 月对智能体隔离的讨论，区分了模型防御与对智能体运行环境施加的限制。隔离意味着限制系统能够访问或执行的事项。Anthropic 表示，会将环境边界与旨在改善模型行为的措施结合使用。

这些属于供应商对自身方法的说明。它们确立的是该公司所陈述的安全依据，而不是独立证明每项部署都实现了预期保护。

关键比较在于：一方面是降低出错概率，另一方面是在错误发生时限制其后果。

一个假设中的文档助手可以让这一区别变得具体。更好的判断能力可能帮助它拒绝提案中的欺骗性指令。访问限制则可能阻止它获取无关的机密文档，无论它如何解读该指令。

这些结果回答的是不同问题。客户希望它在合法工作中表现合理。客户也希望对于发生失败时的情况，能获得可辩护的解释。全面评估应同时审视两者。

这给采购演示带来了实际挑战。模型演示容易理解，因为它展示了可见行为。环境限制则可能显得不那么吸引人，直到评估者要求系统跨越一条禁止边界。

有说服力的演示应让这种尝试跨越边界的过程可见。评估者随后可以查看是什么阻止了它、留下了什么证据，以及合法任务能否继续。拒绝本身只是结果的一部分。

评估还应考虑限制的成本。受严格限制的助手可能需要更多用户输入，或无法完成原本合理的任务。这并不意味着限制有问题，而是说明其运营影响是采购决策的一部分。

同样，频繁中断并不自动代表更高的安全性。只有当中断能帮助用户理解并授权一项具有实质后果的行为时，才值得重视。模糊的批准请求可能让底层决策依然同样不清楚。

因此，对买家而言有用的问题应当具体：哪项拟议操作正在等待谁的授权，批准后究竟会发生什么变化？答案应当让负责业务结果的人也能理解。

这一框架避免将更智能的模型与更强的边界人为地置于对立面。客户两者都能受益，但应要求供应商说明各自贡献了什么。一方面的改进并不能证明其他所有方面也有改进。

它也加剧了竞争压力。销售更大自主权的供应商，需要提供与产品所请求权限相称的证据。错误行为的后果越严重，举证责任就越重。

Vishal Sharma 的零信任警告契合这一争论，但并未给出定论。问题在于，当协作行为已不足以保障安全时，部署是否能对控制机制给出可信说明。

下一批证据应来自失败测试

未来三个月内，最有价值的信号将涉及可复现性、强制执行，以及在现实失败条件下的表现。这些是编辑观察点，并非已宣布的发布承诺。

最有力的证据应说明：什么失败了、什么仍受到保护，以及合法工作是否仍能完成。

首先，关注能否对 Queen’s University Belfast 实验给出可复现的说明。一份更完整的发布内容最好能明确用于评估所报告攻击速度的设备、配置、计时方法和基准。

如果独立团队在所述条件下获得可比结果，这些证据将强化实验性主张。即便结果范围较窄，仍然具有参考价值。它有助于读者区分特定实验室观察结果与有关智能体辅助攻击的一般性主张。

同样的标准也适用于上下文恢复。有价值的测试应明确哪些信息被移除、它曾存在于何处，以及哪些检索路径仍然可用。缺少这些细节时，表面上的回忆会留下太多可能解释。

其次，关注能让权限边界更易于检查的产品发布。相关信号应是与可测试限制相联系的、有文档记录的变更。单凭一个新的安全标签，并不能提供这种证据。

例如，一项假设中的发布可能展示：助手可以准备外部消息，而由独立组件控制其发送。评估者仍需审查该限制覆盖的收件人、内容及授权条件。

这类证据将加强以下判断：供应商正在把一般性的安全原则转化为可部署的控制措施。若一次发布只是增加另一条指令，则对独立强制执行限制的主张支持较弱。

第三，关注同时测试恢复能力和抗攻击能力的独立评估。阻止不需要的操作很有价值。买家还需要知道，系统能否在不重复尝试、不丢失已授权工作、或不需要过度人工干预的情况下恢复。

一项假设中的评估可以比较同一任务在施加访问限制前后的表现。结果应同时描述被禁止的操作与合法任务的完成情况。否则，一个几乎什么都做不成的系统可能因无益的原因看起来很安全。

如果结果显示危害得到控制且已授权工作能够完成，将有助于强化实用自主性的论证。如果结果显示，要完成有用工作就需要广泛且缺乏清晰解释的访问权限，则会暴露持续存在的权衡。

这些信号之所以重要，是因为当前论证否则可能陷入循环。研究人员要求验证，供应商描述保护措施，买家则收到保证，却没有一套共同标准来说明这些保证覆盖什么。

更精确的证据将允许更狭窄、更有成效的分歧。一种部署可能适合起草和研究，另一种则支持具有实质后果的操作。理由应明确每套系统能够就其行为证明什么。

对开发者而言，直接含义是在扩展智能体职责之前，让安全声明可测试。对企业买家而言，则是将所要求的证据与具体业务后果关联起来。对知识工作者而言，则是在交付敏感工作前理解赋予助手的权限。

在下一次智能体试点前，选择一项存在争议的操作，并界定能够解决争议的证据。可以考虑未经授权的收件人、被撤回的文档，或超出原始任务范围的请求。要求供应商展示会发生什么、限制在哪个环节生效，以及事后留下什么记录。随后评估已授权任务是否仍能完成。将该演示视为针对该部署与配置的证据，并清楚说明其限制。Vishal Sharma 的零信任警告为这场讨论提供了一个有用的起点问题：当助手称自己遵守了规则时，其他人究竟能验证什么？