Databricks“组合前无罪”策略在组合点阻断智能体风险

Databricks 发布了一种新的 Omnigent 安全模式：只有当三项单独看来都很普通的能力形成危险链条时，才会阻止智能体。Databricks 的“组合前无罪”方法瞄准的是这样一个时刻：私有数据、不可信内容与外部通信在同一会话中同时可用。

这种组合被称为“致命三要素”。智能体单独执行每项操作时，读取内部文件、查看公开网页或发送消息都可能是安全的。但若将这三种能力置于同一路径中，一条注入指令就可能把合法访问变成数据窃取。

关键变化并非又一次针对提示注入的警告。Databricks 正将执行决策从模型移至 Omnigent——其用于运行和治理智能体的开源元框架。策略层会记住会话中出现过什么，再据此改变对后续操作的处理方式。

静态权限会问智能体是否可以调用某个工具。上下文策略还会问：在这次调用之前发生了什么。这一区别给通过编码智能体、浏览器智能体和 Model Context Protocol 集成提供广泛且持久工具访问权限的团队带来了压力。

Databricks 在 Omnigent 中做了哪些改变

Databricks 正将智能体的历史记录视为其实际权限集的一部分。

该公司的安全案例研究扩展了其关于 Omnigent 上下文策略的一系列文章。此前的示例聚焦于会话状态、缓慢累积的攻击，以及与用户原始意图绑定的授权。

最新示例将这一模型应用于致命三要素。安全研究员 Simon Willison 于 2025 年 6 月定义了这一模式：访问私有数据、接触不可信内容，以及拥有外部通信通道。他的威胁模型警告称，三者结合会为注入指令提供窃取信息的路径。

Omnigent 位于智能体框架之上；后者是管理模型、工具和执行循环的运行时。该项目支持成熟的编码智能体环境和自定义智能体，使通用策略层能够观察其活动。

这一位置很重要，因为策略不需要底层模型识别每一句恶意措辞。它可以根据会话期间记录的事实来治理工具使用。

设想一个智能体被要求审阅一份内部产品文档。读取该文档是预期行为。向公司频道发送经批准的摘要，也可能是预期行为。

现在假设智能体访问了一个包含隐藏指令的公开 issue、网页或仓库。由于会话已跨越另一条信任边界，后续的出站请求便具有不同的安全含义。

传统允许列表在整个工作流中看到的都是同一组获准工具。上下文策略看到的则是一段风险随时间变化的序列。

Omnigent 策略可以返回允许、询问或拒绝的决定。允许会放行操作，询问会将其交由人工处理，拒绝则会阻断操作。因此，随着会话累积敏感访问或高风险事件，响应可以变得更严格。

这一执行模型并不要求每个来源、工具或操作本身都具有危险性。相反，策略会关注那些形成不安全数据路径的组合。

Databricks 还以托管 beta 形式提供与工作区身份和模型服务连接的 Omnigent。其托管部署目前支持内置上下文策略处理程序，但尚不支持任意自定义策略函数。

这一限制区分了开源设计与托管产品。评估该公告的团队必须区分已演示的策略模式，与其所选部署中实际可用的控制措施。

不过，核心变化很清晰：智能体授权正变得依赖会话，而非在登录或工具注册时固定下来。

为什么 Databricks“组合前无罪”改变了安全边界

高风险对象不再是一次工具调用，而是连接多次获准调用的路径。

传统访问控制会评估身份、资源和操作。服务账户可以读取一个数据库、写入一个存储桶，或调用一个 API。这些规则仍然必要，因为智能体仍通过常规凭据运行。

但当不可信语言会影响这些凭据的使用方式时，它们就不够充分。攻击者可能既不需要窃取令牌，也不必利用应用代码漏洞。攻击者只需让恶意内容到达一个既能访问数据、又能对外行动的模型。

第一个要素是私有数据。该类别包括内部文档、源代码、凭据、客户记录、电子邮件、数据库结果，以及任何超出攻击者授权范围的信息。

第二个要素是不可信内容。网页、支持工单、拉取请求、电子邮件、共享文件、工具响应或图像，都可能携带由智能体信任边界之外的人控制的指令。

第三个要素是外部通信。电子邮件和 HTTP 请求是显而易见的例子，但该类别范围更广。发布评论、推送代码、加载远程资源，或写入共享系统，都可能形成出站通道。

这些能力没有一项不寻常。它们的实用性恰恰解释了为何这种组合会出现在如此多的智能体设计中。

研究型智能体需要外部来源和内部上下文。编码智能体可能读取私有仓库、查阅公开文档并推送分支。电子邮件助手会读取不可信消息、搜索私密通信并发送回复。

永久移除任何一种能力，都可能显著降低智能体的实用性。持续要求审批则会带来另一个问题，因为用户可能逐渐习惯于接受例行请求。

Databricks 的“组合前无罪”框架提供了另一种选择：让低风险操作继续进行，但当会话状态凑齐被禁止的组合时升级处置。

这将安全边界从单个连接器转移到了工作流。浏览器不再只是被简单地视为可信或不可信。它是否相关，取决于同一会话是否还持有敏感信息和出站路径。

这一模型类似信息流控制，即系统追踪数据如何在不同信任级别之间流动。一旦机密信息进入某个上下文，后续写入保护程度较低目的地的操作就会受到更严格的处理。

Omnigent 已发布的策略目录中已包含一项相关的 Google Drive 控制措施。一旦会话读取了声明为机密的文件，策略就可以阻止向机密集合之外写入。

该目录还包含风险评分策略。它会根据工具调用和敏感数据标签累积分数，并在达到配置阈值后对受保护工具升级处置。

这些例子说明了为何状态至关重要。智能体读取敏感文档后，写入请求的 API 形态并不会改变。改变的是其含义，因为会话历史发生了变化。

同样的原则也适用于致命三要素。策略寻找的是危险组合，而非一项普遍被禁止的操作。

这一区别比又一个提示过滤器更值得平台团队关注。过滤器试图判断文本看起来是否恶意。即使模型或过滤器未能识别注入内容，上下文执行仍可阻断不安全操作。

静态权限丢失了操作序列

静态允许列表可以描述可用能力，但无法解释智能体如何走到某项操作。

假设开发者授权智能体读取私有仓库、浏览文档并创建拉取请求。每项权限都支持正常的编码工作流。

随后，攻击者在 issue、依赖文档或检索到的网页中植入一条指令。该指令要求智能体收集一个秘密，并将其包含在公开拉取请求的描述中。

读取仓库是允许的。检索网页是允许的。创建拉取请求也是允许的。独立评估每次请求的控制措施，可能会批准整条链路。

内容过滤器或许能检测到该指令，但也可能漏掉间接请求、编码数据、不熟悉的语言，或针对目标模型设计的载荷。

研究支持对仅依赖模型行为保持谨慎。WASP 基准测试使用多个模型和脚手架，测试了针对 Web 智能体系统的现实提示注入攻击。

研究人员发现，在测试配置中，智能体执行对抗性指令的比例介于 16% 至 86% 之间。攻击者端到端成功率较低，范围从 0% 到 17%。

这一差距令人鼓舞，但不足以令人安心。当前智能体往往会在完成复杂攻击前失败，但智能体可靠性的提升也可能使恶意工作流更容易完成。

系统不应指望智能体恰好在正确时刻变得混乱。它需要一种能在模型更擅长多步骤执行时仍然有效的控制措施。

静态权限也难以应对延迟攻击。注入指令未必会立即触发出站操作。它可能影响后续计划、委派任务、生成文件或工具调用。

具备会话感知能力的策略可在这段延迟期间保留与安全相关的事实。它不需要将每个可疑事件都紧挨着模型活跃上下文中的最终操作。

这种持久性解决了长时间运行智能体的一个实际弱点。对话历史可能被压缩、总结或拆分给不同工作进程。即使工具和凭据仍可用，模型也可能忘记先前的约束。

因此，策略状态应存在于文本窗口之外。执行层需要独立且持久地记录敏感读取、不可信输入、目的地、审批和风险变化。

这一架构也降低了对智能体自我报告的依赖。询问模型是否遇到不可信内容，弱于记录是哪个连接器提供了该内容。

最强的信号来自基础设施。文档系统知道文件的分类。网络网关知道目的地。身份层知道用户和工作区。工具代理知道请求了哪项操作。

Omnigent 能够组合这些信号，因为它封装了执行环境。智能体提出操作，但策略决定该操作在已记录的上下文下是否仍然可接受。

这正是竞争性智能体平台面临的压力点。工具级审批更容易解释和实现。但当智能体跨越更多连接器运行更长会话时，它们的可信度会下降。

供应商需要展示其控制措施是否会跨工具追踪数据和信任状态转换。一长串权限已无法回答核心安全问题。

上下文策略在数据离开前切断链条

最有价值的控制点是完成攻击路径的那次转换，通常是一次敏感读取或一次出站操作。

上下文策略始于可观察事件。其中可以包括工具调用、工具结果、数据标签、目标地址、模型请求或用户批准。

策略会将选定事实存入会话状态。它可能记录智能体是否消费了不可信内容、访问了机密对象，或尝试在获批边界外通信。

后续事件会根据该状态进行评估。如果下一项操作构成了被禁止的组合，策略就可以要求批准或拒绝该请求。

事件顺序可以不同。智能体可能先读取私有数据，再访问不可信网页；也可能先遇到注入内容，随后请求访问内部文件。

健全的实现必须识别这两条路径。危险并不来自某种固定的先后顺序，而在于这些能力被连接起来。

执行也可以发生在不止一个节点。某项策略可能会在不可信内容进入会话后阻止敏感读取；另一种设计则可能允许分析，但阻止后续的外部通信。

阻断外传通常能保留更多本地效用。智能体可以继续阅读和起草内容，却无法获得泄露信息的途径。不过，外传控制覆盖的范围不能只限于显而易见的发送函数。

生成的链接可以编码数据。远程图片请求可以传输查询参数。源代码控制推送、问题评论、分析调用或共享文档写入，都可能跨越信任边界。

目标上下文同样重要。将摘要发送到获批的内部频道，与将其发布到公开代码仓库并不相同。对所有写入操作一视同仁会造成不必要的中断。

当上下文和目标明确时，人工批准很有价值。一条有用的提示应说明：该会话读取了机密数据，之后又消费了不可信内容，现在希望联系某个特定的外部端点。

笼统的“允许此工具”提示掩盖了升级审批的原因。它会助长审批疲劳，因为审核者必须手动还原整个工作流。

对于组织绝不接受的组合，直接拒绝更合适。例如，策略可以阻止任何接触过公开内容的会话，将受限数据集中的信息发送到其隔离区之外。

当缺少必要上下文时，策略引擎必须以安全方式失败。缺失的数据标签、不受支持的工具或未观察到的网络路径，都可能形成盲点。

Omnigent 的更广泛方法将策略与沙箱结合。沙箱在操作系统边界限制文件系统和网络访问，即使模型发出请求，也能减少智能体可触及的范围。

这些层各有不同用途。沙箱限制原始能力；上下文策略则根据会话累积的状态调整权限。

两者都不能取代常规的身份控制、连接器授权、日志记录或数据泄露防护。将这项公告理解为该安全技术栈中的一个执行层，才最有价值。

OWASP 发布的智能体安全报告将提示注入列为针对 AI 系统的主要攻击技术之一。其更核心的信息是，智能体安全需要围绕执行、工具、身份和数据流动设置控制措施。

这支持了 Databricks 的架构方向。概率模型可以建议某项操作，但应由确定性边界决定该操作是否被允许。

Databricks 策略尚未解决的问题

上下文执行缩小了攻击路径，但其可靠性取决于完整的可见性和可信的分类。

第一个尚未解决的问题是覆盖范围。策略无法阻止它观察不到的通道。

智能体可能通过连接器、shell 命令、浏览器请求、嵌入式资源或生成的工件进行通信。所有能够将数据移出边界的路径，都必须在策略模型中得到体现，或在其他位置受到约束。

第二个问题是分类。系统需要知道哪些内容不可信，哪些数据敏感。

简单规则可以将公开网页归为不可信，并将指定文档归为机密。企业环境中存在更棘手的情况，包括共享驱动器、承包商账户、复制文本、生成文件，以及由多个低敏感度来源汇集而成的数据。

假阴性会让危险组合未被检测到。假阳性则会打断日常工作，并可能训练用户在不审查的情况下批准警告。

第三个问题是状态范围。会话是一个方便的单位，但信息可以通过文件、记忆存储、缓存、子智能体和复制的摘要在会话之间流动。

如果一个工作进程读取了机密数据，另一个工作进程发送了结果，按会话追踪可能会遗漏这一组合数据流。多智能体系统需要传播规则，在委派过程中保留相关标签。

第四个问题是策略完整性。执行层、配置和事件流都会成为安全关键基础设施。攻击者可能瞄准策略缺口、格式错误的工具元数据、含糊的目标地址或失效开放行为。

团队应测试实际的策略边界，而不只是测试模型。对抗性评估必须涵盖替代性外传路径、延迟操作、跨智能体传输和不完整元数据。

第五个问题是可用性。过于频繁要求批准的控制措施，可能会重现其原本旨在解决的弱点。

基于风险的升级机制需要精心选择阈值和信息明确的提示。安全团队应衡量批准频率、拒绝准确性、覆盖率，以及用户接受例外的原因。

托管 Omnigent beta 版带来了另一项实际限制。Databricks 目前说明，在托管环境中支持内置处理程序，而不支持任意自定义策略代码。

拥有专门分类体系或专有连接器的组织，应验证可用策略是否能提供足够的上下文。开源灵活性不会自动转化为托管服务的功能对等。

目前也没有依据将一次演示视为普遍验证。Databricks 的文章说明了一种安全模式和实现方法，但并未证明每一种 Omnigent 配置都能阻止每一种提示注入技术。

正确的说法应更为有限。即使每个单独工具都保持合法，具备会话感知能力的执行机制仍可以切断致命三要素路径。

这依然具有重要意义。安全架构往往通过移除攻击所需的一个必要条件取得成效，而不是教会应用识别每一条攻击者消息。

最强大的部署会将上下文策略与受限凭据、目标地址允许列表、沙箱、审计日志和独立测试结合起来。它们还会将策略定义视为经过版本管理的安全代码。

三个信号将表明该模式是否成立

下一项考验在于，上下文策略能否成为可衡量的基础设施，而不只是一个有说服力的演示。

第一个信号是覆盖更多工具和智能体运行框架。Databricks 必须证明，安全标签和会话状态能够在涉及浏览器、代码仓库、文档系统、shell 和受委派智能体的常见工作流中持续保留。

功能列表中的支持还不够。团队需要证据证明，在不同运行框架和连接器实现中，等效操作能获得等效执行。

一致的覆盖将强化共享元框架的理由。不同运行时之间存在实质差异，则会削弱跨智能体采用单一治理层的承诺。

第二个信号是对抗性评估。Omnigent 需要可重复的测试，以尝试延迟外泄、间接外传、跨会话传输和元数据操纵。

有价值的结果应区分检测、批准、拒绝和成功的数据移动。还应报告正常任务的完成情况，因为阻止所有工作流的策略虽然安全，却无法使用。

公开测试夹具将使安全团队能够针对自己的配置复现结果。独立评估的分量将高于供应商自行挑选的场景。

第三个信号是在托管 Databricks 环境中的运营采用。关注策略支持的扩展、更清晰的遥测、管理控制，以及与企业数据分类集成的文档化情况。

采用应带来可衡量的结果。团队需要知道策略触发的频率、哪些能力组合导致升级，以及审核者是否推翻或批准该决定。

这些信号之所以重要，是因为底层安全问题会随着智能体效用的提升而扩大。更强大的智能体将在无需持续监督的情况下完成更长的任务、使用更多工具，并跨越更多信任边界。

Databricks 的“单独无害、组合受限”方法提供了一条可信的设计原则：允许有用的组件，同时阻止危险的组合。它将注意力从模型是否理解攻击，转移到周边系统是否允许攻击完成。

开发者应梳理哪些会话能够访问私有数据、摄入攻击者控制的内容并进行外部通信。企业采购方应询问，平台是否会跨越时间、工具和受委派工作进程追踪这些条件。

如果三种能力在缺少上下文执行的情况下仍然同时可用，再精致的批准界面也无法解决问题。实际的下一步，是确定每个工作流中第三种能力在哪个节点进入，然后在该边界部署一项可测试的策略。