Docker

Below the Harness: Governing a Multi-Model, Multi-Harness World

8.5内容质量

TL;DR · AI 摘要

Docker提出多模型、多Harness时代需新信任模型，解决AI代理继承用户权限导致的安全风险。

核心要点

  • 多模型、多Harness的未来需要新的信任模型来解决权限问题
  • AI代理继承用户权限但行为不可预测，导致安全风险
  • 每个Harness的防护措施存在漏洞，需统一治理

结构提纲

按章节快速跳转。

  1. §引言

    提出多模型、多Harness时代需要新的信任模型

  2. ·Confused Deputy问题

    1988年Norm Hardy提出的权限继承问题在AI时代重现

  3. ›行业趋势

    模型成本、能力迭代和定制需求推动多模型架构

  4. ·信任挑战

    AI代理使用用户权限但行为不可控，形成安全风险

  5. ›防护失效

    Harness内置防护措施在现实中无法阻止代理越权行为

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）
  • 多模型多Harness信任治理
    • 核心问题
      • Confused Deputy权限继承风险
    • 行业趋势
      • 模型成本高
      • 能力快速迭代
      • 定制模型需求
    • 解决方案
      • 新信任模型构建

金句 / Highlights

值得收藏与分享的关键句。

#AI代理#多模型#安全#Docker
打开原文

Harness之下：治理多模型、多Harness世界 | Docker

Harness之下：治理多模型、多Harness世界

发布于 2026年9月2日

Srini Sekaran

我们相信未来是多模型、多Harness的世界。我们认为这需要一种新的信任模型。

1988年，Norm Hardy描述了一个持续多年悄然破坏系统的难题：困惑的副官。一个程序使用自身的权限而非你的权限执行操作。

今天，每个AI代理都扮演着这个副官的角色。它继承了你的权限：你的凭证、仓库访问权限、调用API的能力。但其行为具有概率性。它可能根据环境中发现的指令、自己发明的步骤，或一个自信的错误答案采取行动。

行业并未通过让副官本身更加谨慎来解决困惑副官问题，而是通过将权限层级移至更远的地方来解决。四十年后，这仍然是答案。

业界正汇聚于同一未来

三个事实正推动行业走向相同结论。

  • 代理是昂贵的循环。一个代理需要执行许多步骤，而你需要为每个步骤的每个token付费。我们都认同，为简单任务调用最前沿模型在经济上毫无意义。
  • 前沿能力的领导者经常更替。我们都知道，当前最先进的模型（及其供应商）每隔几个月就会发生变化。
  • 你的工作流程可能需要定制模型。许多团队正在认识到，智能正在成为商品，而差异点在于基于定制上下文的定制模型。

因此，我们所有人都迅速面临着跨多个Harness的多模型组合。

上层同样出现了类似的收敛。开发者会根据任务选择特定工具，这与他们一贯的做法一致。例如，可能使用Claude Code进行大型重构，用Codex处理日常任务，用Hermes编写快速脚本。

合理预期未来的工作将是多模型、多Harness的。

这使得信任成为核心问题

许多代理的工作方式相同。

它们读取的材料往往超出我们的控制范围：支持工单、网页、文档以及陌生人编写的代码。但它们使用你授予的权限执行操作：你的凭证、仓库访问权限、生产API以及开放互联网。而且它们通常从开发者的笔记本电脑执行这些操作，这超出了VPC和IAM等常规安全防护范围。

私有数据与自主执行能力的结合，正是代理值得部署的关键。你的副官需要具备执行能力才能发挥作用。这意味着有趣的问题不再是哪个模型最好，而是当这些副官出错或被操控时会发生什么。

每个Harness的防护措施会失效

显而易见的解决方案是每个Harness自带自己的防护措施。许多确实如此。但若将其作为你的安全边界依赖，它们会以三种方式失效。

  • 代理无视它们。Harness 内部的防护措施是在代理运行的同一循环中强制执行的。如果拒绝其 git push 操作，它会转向 API；如果拒绝 API，它会创建 gist；如果拒绝 gist，它会将数据隐藏到你信任且从不检查的通道中。研究人员去年展示了一个案例：在公共 GitHub 仓库中提交一个恶意问题，就能引导编码代理读取公司私有仓库，并以代理自身发起的 Pull Request 发布内容。由于每一步都使用代理自身的合法访问权限，通过所有人信任的通道进行，因此没有发生任何入侵。代理能协商的边界，实际上并不是真正的边界。
  • 防护措施在你毫无察觉时移动。大多数 harness 的隔离模型都是闭源的，按照供应商的进度发布。仅在过去一年中，主要的编码代理就各自多次修改了默认的沙箱和审批行为。沙箱模型的更新应被视为安全事件。如果乘以十种 harness，你的安全态势在任何时刻都取决于你六家供应商措施的拼凑状态。
  • 防护措施无法覆盖整个舰队。平台团队构建的定制代理只包含平台团队编写的防护措施。支持 SaaS 中的代理则取决于其供应商的选择，而大多数供应商根本不会向你暴露任何隔离控制。每个新 harness 都意味着需要重新构建或审计治理规则，从零开始，方式各不相同。最终你会得到十几个相互偏离的实现，彼此之间无法感知流量，没有统一的规则设置点，也没有统一的记录来解释为何出现问题。

安全性不能依赖代理做出正确决策，也不能依赖他人的发布计划。

一层之下

因此，我们坚信：未来将是多模态和多代理的。鉴于这一未来，我们相信每个组织都需要一个更底层的层级：一个运行时层级，在 harness 之下，所有代理都运行在其之上。

推理过程很直接。剥离模型、供应商和框架，代理影响任何事物只有两种方式。它运行代码，这会触及文件并打开网络连接；或者它调用工具，在系统上执行操作。代理所做的一切都通过这两条路径中的一条。而这两条路径都跨越了相同的表面：运行时环境，进程在此执行，凭证在此使用，请求从这里离开机器。无论代理使用的是哪种模型、哪个供应商提供的、还是你自己构建的，所有代理都必须经过这个层级。这使它成为唯一一个可以跨所有代理强制执行你定义规则的地方。这也与 1988 年的解决方案相同，只是应用于今天的副代理：权限位于一个层级之下。

在运行时层级实施强制措施后，我们之前提到的三种失败场景将彻底改变。

你的代理无法互相无视。代理的边界位于其运行循环之外，因此无论模型是否与你一致、是否产生幻觉或是否被入侵，边界始终稳定。运行时层级的硬性中立边界比代理自身创建的提示层级边界更有效。

防护措施不再随机移动。策略由你定义，一次性编写，覆盖执行、工具调用、凭证和支出。现在，无论模型或代理供应商进行何种更新，都不会随机改变你的安全态势。

护栏覆盖整个舰队。您编写的一项策略将适用于所有约束机制。所有代理执行的每个操作都会记录在单一记录中：执行了什么、接触了哪些内容、是哪条规则做出的决策。

这使您能够对代理进行细致的控制。如果没有约束机制作为下限，您将面临三个糟糕的选择：完全阻止代理运行、允许所有代理运行并寄希望于最佳结果，或者在每个步骤中插入人工审批流程，从而放弃原本期望的生产力。

在运行时设置下限，您将拥有第四个选择。当代理出现异常时，即使后果受到限制，您也可以开始授予其真正的自主权，而这正是目标所在。

我们预计模型将持续变化，新的约束机制也将陆续出现在所有工具包中。这部分是健康的。但支撑它们的底层边界应当保持稳定。

在旧金山圣何塞的We Are Developers大会上，Docker首席技术官Tushar Jain将深入探讨这一领域：多个模型、多个约束机制，以及它们共同依赖的单一运行时环境。

作者简介

Docker人工智能业务高级产品市场经理

Srini Sekaran是Docker人工智能业务高级产品市场经理，专注于Docker AI治理、Docker沙箱以及代理基础设施和开发者工作流程的未来发展方向。

人工智能/机器学习

公司

目录

相关文章

  • 2026年8月18日 17,600个操作：代理安全是系统问题 OpenAI/Hugging Face事件暴露了AI代理安全的新挑战。17,600个攻击者操作展示了为何AI代理安全不能依赖人工审查。探索需要哪些控制措施，以在高速度下约束、观察和治理代理。Mark Cavage 阅读文章
  • 2026年9月3日 YOLO模式：无防护栏的代理自主权 YOLO模式允许AI代理在未经许可的情况下运行。了解其定义、风险以及如何安全运行。Eric Jia和Srini Sekaran 阅读文章
  • Docker Captain 2026年9月2日 使用Docker沙箱构建可复现的AI评估流程 学习如何通过Docker沙箱实现更可复现的AI评估流程，包括一致的执行、结构化的制品和运行时证据。Karan Verma 阅读文章
  • 2026年9月2日 护栏之下：治理多模型、多护栏世界 我们认为未来将是多模型、多护栏的世界。我们认为这需要一种新的信任模型。1988年，Norm Hardy描述了一个持续多年悄然破坏系统的难题：困惑副手问题。一个程序使用自己的权限而非您的权限采取行动。今天，每个AI代理都是那个副手。它…… Srini Sekaran 阅读文章