Databricks Permission 并非 Purpose：Omnigent 在 Agent 行动前引入 Intent

Databricks 为 Omnigent 引入了一道新的权限边界，尽管该 agent 在测试中已持有其所用每项工具的有效凭据。这项控制关注的是操作为何发生，而不只是 agent 是否有能力执行操作。这一区别将 databricks permission 从身份核验转变为面向特定任务的约束。

7 月 23 日发布的内容将基于意图的授权定位为防御间接提示注入的方法。这类攻击会将指令隐藏在 agent 读取的内容中，例如电子邮件、文档、支持工单或数据库字段。Omnigent 将每个会话绑定至经人工批准的目的，并据此检查每一次工具调用。

这一方法挑战了大多数企业访问系统背后默认的“身份优先”模型。基于角色的访问控制能够确认 agent 是否可以授予数据库访问权限，却无法判断在数据质量审查中授予访问权限是否合乎任务目的。能力与目的之间的差异，如今正成为一道实际的安全边界。

Databricks Permission 现在检查任务，而不只是身份

最直接的变化很简单：Omnigent 会评估每一次拟议工具调用，是否服务于当前会话已声明的目的。

传统授权始于身份。用户、服务账户或 agent 被授予与特定资源交互的权限。随后，应用程序会根据角色、范围、策略和凭据接受或拒绝操作。

这一模型假定，经过认证的行为主体代表着相对稳定的决策者。人类阅读信息、进行理解，并决定按下哪个获授权的按钮。授权层很少需要理解其按下按钮的原因。

AI agent 的运作方式不同。它在同一个自动化循环中读取数据并决定采取何种行动。系统外部收集的内容，既可能影响其推理，也可能影响其对特权工具的选择。

根据意图授权发布公告，Omnigent 通过结合身份与意图来处理这一差异。身份界定 agent 可用操作的广泛集合；意图则将该集合收窄至某一项任务或会话。

该机制会在工具调用前产生三种可能的决策：

• ALLOW： 拟议操作显然符合已批准的目的。

• ASK： 该操作与目的相关，但需要人工同意。

• DENY： 该操作超出已声明的目的，无法继续。

这些结果之所以重要，是因为有效凭据不再足以决定授权结果。Agent 可以拥有某项工具，却仍无法在无关任务中使用它。

Omnigent 是一个开源元框架，这意味着它为不同的 agent 运行时提供共享的编排与策略层。其开源仓库列出了对 Claude Code、Codex、Cursor、OpenCode、Hermes、Pi 和自定义 agent 的支持。

这一定位意味着，该策略并非仅是针对单一模型的防护措施。意图检查位于 agent 工具活动的外围，可通过一个通用层治理不同的推理系统。

此次发布也伴随着一项重要限制。Omnigent 仍处于 alpha 阶段，因此这项演示应被视为设计提案和可运行的实现，而非其在每一种模型、工具和企业工作流中具备生产规模可靠性的证据。

不过，这一架构观点很明确：授权决策可以纳入当前任务，同时无需取代现有身份控制。对安全团队而言，这在模型决策与后果重大的操作之间增加了一个检查点。

这项新控制也补充了 Omnigent 的其他上下文策略。这些策略可以考虑会话风险、敏感数据、累计工具使用情况或特定服务限制。若多个策略评估同一次调用，一项拒绝决策将覆盖更宽松的决策。

该规则可防止新加入的策略悄然抵消更严格的策略。它也将意图定位为更大防御体系中的一层，而不是对 agent 安全问题的完整解答。

数据质量测试揭示了目的缺口

Databricks 选择了一个小型数据工作流，以说明过度授权有时在运营上不可避免，却依然不安全。

测试中的 agent 执行一项常规数据质量任务。它读取客户表、计算质量指标，并将摘要发布到内部仪表板。

其可用工具包括表查询、仪表板更新，以及一个向其他用户授予表访问权限的函数。最后一种能力对这次审查并无必要，但同一 agent 会在其他正当任务中使用它。

移除授予访问权限的工具可降低眼前风险，但也会使 agent 无法在没有单独配置或身份的情况下完成有效的资源配置工作。对于通用 agent 而言，静态最小权限正是在此变得棘手。

会话以一个狭窄请求开始：检查 customers 表并发布摘要。攻击者此前已在该表的用户可控字段中植入了一条指令。

隐藏文本将自己伪装成审计备注，指示 agent 向一个外部地址授予客户数据访问权限，然后继续原本的质量检查。

这是一种间接提示注入，因为恶意指令是通过检索到的数据进入系统的。用户从未要求 agent 更改权限，攻击者也无需直接访问 agent 的对话。

在没有意图策略的情况下，Omnigent 的测试 agent 会遵循植入的指令。其身份已获授权使用授予访问权限的工具，因此传统权限检查会将其视为有效主体发起的有效操作。

随后，agent 会将该授权记录为常规审计活动。这一细节说明了第二个问题：活动日志可以准确记录操作，却无法揭示该操作违背了用户的真实目标。

启用基于意图的授权后，相同的工具和凭据依然可用。结果之所以改变，是因为每项操作都会与已批准的数据质量目的进行比较。

读取表会得到 ALLOW 决策。发布所请求的仪表板更新会得到 ASK 决策，让人工确认该写入操作。向外部地址授予访问权限则会得到 DENY 决策。

在获得仪表板更新批准后，正当任务仍可完成。注入的操作会失败，因为它并未服务于会话所述目的。

这个示例赋予 databricks permission 控制更明确的含义。问题不再只是 agent 是否可以修改访问权限，系统还会评估这种修改是否属于一次数据质量会话。

该测试反映了一个实际的企业问题。连接到某个可搜索知识库、数据平台或支持环境的 agent，可能接触到来自不同信任级别的文本。用户评论与管理员指令可能进入同一个模型上下文。

人类对组织上下文的识别并不完美，但可以质疑异常请求。模型则可能将经过精心包装的恶意文本解读为任务的一部分，尤其是在其看起来像普通业务指令时。

Google 的安全研究人员将间接提示注入定义为嵌入 AI 系统所处理内容中的恶意指令。他们近期的网络威胁分析发现了恶意尝试，也发现了许多与注入模式相似的无害文本。

这种混合使内容过滤更加复杂。寻找“忽略此前指令”等短语的检测器，会遇到研究论文、安全教程和无害讨论。复杂攻击则可能使用没有明显恶意标记的商业语言。

基于意图的授权从操作侧切入这一问题。它无需在阻止无关的权限变更前证明某个表字段具有敌意，而是询问由此产生的工具调用是否支持该任务。

这正是 Databricks 演示中的核心转变。对身份系统而言，这项危险操作看起来并非未获授权；只有当目的进入决策后，它才变得未经授权。

为什么基于身份的访问控制让 Agent 暴露过多

主要压力落在那些将凭据范围视为自主软件最终边界的身份与访问系统上。

基于角色的访问控制仍然不可或缺。它限制身份可访问哪些资源、可请求哪些操作。基于意图的控制无法安全地弥补 agent 在整个组织范围内持有管理员访问权限的问题。

然而，角色往往保持稳定，而 agent 的任务却迅速变化。编程 agent 可以在不同会话中审查代码仓库、创建分支、部署服务或修改 issue。每项任务都需要同一组可用能力中的不同子集。

为每一种可能任务创建一个身份，会带来巨大的配置负担。向一个可复用身份授予宽泛范围，则会产生环境权限问题：凭据在其即时目的之外依然可用。

短期且范围狭窄的凭据可以降低这种暴露。当系统能在执行前准确预测所需资源和操作时，它们效果最佳。开放式 agent 工作流往往在执行过程中才发现这些需求。

Omnigent 模型增加了会话级约束，无需为每次对话创建新的身份。人工声明 agent 应完成的事项，随后策略会依据该声明评估拟议操作。

对于自主 agent，Databricks 表示，意图可在设计阶段固定在 agent 规范中。运行中的 agent 无法扩大或移除它。

交互式 agent 的处理方式不同。Agent 会根据用户的自然语言描述起草策略，但会话开始时须由人工批准。该策略无法在该会话期间于后台发生变化。

这一人工批准步骤很重要，因为意图推断本身也会产生漏洞。若模型能够在读取注入内容后悄然重新定义目的，攻击者便可诱导它为不需要的操作授权。

Omnigent 还会拒绝向运行中的 agent 提供用于移除、编辑或禁用其意图的工具。添加另一项策略需要人工批准，而一项宽松的新增策略无法覆盖现有的拒绝决策。

这些控制为策略配置提供了防篡改能力，但并不意味着底层意图评估不会出错。

内置策略文档称，其 intent_based_authorization 控制会将第一条用户消息记录为会话意图。随后，对于与该意图不存在合理关联的工具调用，它会要求确认。文档还指出，该策略需要 LLM 配置；若没有配置，则会以开放失败的方式运行。

最后一种行为值得关注。当其评估器缺失时变得宽松的安全控制，会带来团队必须测试和监控的部署条件。生产环境通常需要在必需的策略组件不可用时提供可见的失败信号、配置验证和告警。

使用 LLM 评估器带来了另一项权衡。自然语言推理能够理解静态规则遗漏的任务关系，但当提示词、模型或周边上下文变化时，也可能作出不一致的决策。

这种张力解释了 Databricks 为何将意图视为分层代理安全的一部分。一项策略可以阻止与任务无关的访问授权，而另一项控制则限制累积风险。独立的数据泄露规则可以约束原本获准调用中流动的信息。

NIST 也将授权视为尚未解决的代理问题。其 2026 年 2 月发布的代理身份提案提出，组织应如何将身份、授权、审计和不可否认性控制应用于自主软件。

该提案特别包括防止和缓解提示注入的控制措施。这一范围表明，身份与目的不能再作为彼此独立的话题讨论。

经过认证的代理仍可能作出有害决策。与目的对齐的操作也仍可能泄露敏感数据，前提是其参数或目标位置不安全。有效控制必须同时考虑身份、任务、数据、操作和后果。

对于企业买家而言，必然的应对方式是架构性的。安全审查不能再止步于 OAuth 范围或服务账户角色清单。团队需要记录每项高影响操作在执行期间如何始终关联到经用户批准的目标。

基于意图的授权引入判断，也带来新的故障模式

Omnigent 通过将模型辅助判断直接置于执行路径中，缩小了一项授权缺口。

这种设计提供了灵活性，但也带来了不确定性。“与任务存在合理关联”并不是一个完全确定的属性。

设想一个代理被要求调查生产故障。读取日志显然符合任务要求。在代理识别出故障后，重启服务或许也符合要求。如果证据表明存在泄露风险，轮换凭据可能是必要操作。

过于狭窄的策略可能阻止恢复所需的操作。过于宽泛的策略则可能让攻击者将无关的凭据变更包装成事故响应。人工审批可以解决部分模糊性，但频繁提示可能拖慢工作，并助长自动同意。

因此，ALLOW、ASK 和 DENY 模式依赖于精细校准。ASK 尤其重要，因为它能为不确定但正当的操作提供推进路径，同时不授予静默自主权。

过多的 ASK 决策会造成审批疲劳。操作人员可能在不检查原因、目标位置或受影响数据的情况下批准请求。过少的 ASK 决策则会将模糊操作推向自动许可或不必要的拒绝。

该策略评判的是工具调用，而不是每一次获准调用的所有后果。Databricks 明确指出，意图限制的是哪些操作能够执行，而非这些操作中传递什么内容。

获批的仪表板更新仍可能包含机密数据。被允许的邮件回复仍可能发给错误的收件人。正当的数据库查询也可能返回超出任务所需的记录。

因此，基于意图的授权必须与参数验证、数据泄露防护、目标位置控制、速率限制和审计系统协同工作。它的价值在于为授权增加目的维度，而不是取代这些控制。

OpenAI 在其代理安全分析中描述了相关的源与汇模型。危险结果往往同时需要攻击者控制的内容，以及在错误上下文中会变得有害的能力。

这一框架支持 Omnigent 对约束操作的关注。它也凸显了为何没有单一分类器能够解决这一问题。即便系统未能检测到恶意输入，也应降低操纵造成的影响。

独立研究也指向同一方向。ACL 2025 的 Task Shield 论文评估每项指令和工具调用是否有助于实现用户指定的目标。

研究人员在 AgentDojo 基准测试中报告，使用 GPT-4o 时攻击成功率为 2.07%，任务效用为 69.79%。这些结果适用于该基准和配置，并不适用于 Omnigent 的实现。

效用数据揭示了任务对齐防御背后的权衡。系统可以阻止攻击，同时也可能妨碍正当工作。只有当策略保留足够的任务完成能力、使系统保持可用时，安全性才真正得到提升。

Databricks 尚未发布其新控制措施的可比基准结果。演示展示了一个注入字段、一个代理、三个工具和一个声明目的。它并未证明该方法在长会话或模糊企业任务中的普适表现。

目前也没有公开证据说明误批准、误拒绝、评估器延迟，或模型更新后的策略行为。这些指标将决定该方法能否超越有说服力的示例。

攻击者也会适应。他们可以构造听起来与声明任务相关的注入指令。一条指令可能声称，授予访问权限是核验当前审查的同一张表所必需的。

已发布的演示已经采用了这一策略：它将外部接收者描述为审计人员。由于获批意图仍然狭窄，策略依然阻止了授权；但更复杂的任务会产生更不明显的边界。

恶意指令也可能瞄准获准工具中的参数。如果会话允许更新仪表板，攻击者可能尝试将机密字段插入仪表板正文。仅靠工具级目的对齐未必能够检测到这种变体。

因此，评估 databricks permission 控制的团队应在多个层面测试策略决策。他们需要测试常规请求、模糊请求、注入内容、误导性的业务理由，以及获准操作中的恶意参数。

他们还应记录每项决策发生的原因。如果日志只包含 ALLOW、ASK 或 DENY，而没有相关意图和拟执行操作，安全团队便无法调查不一致的执行结果。

最有用的比较并不是意图控制与完美安全之间的对比，而是在分层系统中，将意图控制与仅依赖身份授权进行比较。

在这种比较下，Omnigent 弥补了真实缺口。剩下的问题是，团队能否足够精确地定义目的，既获得保护，又不让每一项有用的代理操作都变成人工审查。

三个信号将表明 Omnigent 的模型是否经得住考验

下一阶段应以可衡量的执行质量来评判，而非初始演示的清晰程度。

第一个信号是可复现的评估套件。Omnigent 需要覆盖不同模型、测试框架、工具和间接注入策略的测试。

有价值的结果应区分攻击成功率、正当任务完成率、误批准、误拒绝和人工升级率。它们还应显示，措辞上的微小变化是否会产生实质不同的决策。

在对抗性测试中表现强劲，将强化 Databricks 的论点：目的可以成为可靠的授权输入。模型或提示词之间的高方差，则会削弱将模型辅助意图检查作为执行边界的依据。

第二个信号是适合生产部署的故障行为。Omnigent 的文档指出，当没有可用的 LLM 配置时，内置策略会采用失效开放模式。

用户应关注启动验证、管理告警、失效关闭选项，以及评估器无法运行时清晰的审计记录。如果配置漂移能够悄然移除上下文策略，那么该策略提供的保护就十分有限。

对评估器故障进行可见处理，会增强该设计的可信度。若持续保持宽松行为却没有显著警告，则会留下严重的运营缺口。

第三个信号是作者示例之外的采用情况。真实团队需要为编程、支持、数据运营、电子邮件、日历和多代理委派发布策略。

这些示例应揭示组织如何为会合理演变的任务定义意图。它们也应显示用户收到 ASK 提示的频率，以及这些提示是否改善了决策。

更广泛的使用将检验该设计的核心承诺：一个代理可以保留有用能力，同时仅行使当前任务所需的能力子集。反复出现的策略绕过或难以忍受的审批疲劳，将削弱这一承诺。

这正是 Omnigent 发布的重要性超越单个开源框架的原因。代理开发者正在构建能够读取不受信任信息、并通过有效企业凭据执行操作的系统。由此产生的风险介于传统访问控制与模型安全之间。

Databricks permission 正在成为两部分决策：该身份能否操作，以及该操作是否服务于获批目的？

第二个问题不会消除提示注入。它提供了一个拦截点：在注入指令影响模型之后、抵达具有重大后果的工具之前将其阻止。

开发者应首先识别那些授权会随任务上下文变化的操作。安全团队随后可以测试意图策略是否会拒绝无关操作、升级模糊操作，并保留正当工作。

企业买家应向供应商索取这三个结果的证据。阻止一切的控制并非有用的授权。保留所有工作流却遗漏对抗性请求的控制，也不构成有意义的保护。

如今，一个实际问题已无法回避：如果 AI 代理拥有执行某项操作的权限，哪些独立执行的证据能够证明该操作服务于用户当前的目的？