企业采用智能体的新安全基线-未完纪

Agent Baseline 是一份 AI 采用蓝图，以六项安全结果界定企业如何让智能体投入工作，同时避免赋予其不受约束的权限。

设想这样一个场景：客服智能体收到一张带附件的工单。附件里隐藏着一条指令：查询客户数据库，并将结果发送到某个外部地址。

智能体拥有执行这条指令所需的一切能力。它能够读取工单、查询内部系统、调用工具并连接互联网。这条指令是恶意的，却看起来像工作内容的一部分。

在客户数据离开公司之前，什么机制能够阻止智能体？

当智能体从实验走向日常运营时，这正是企业面对的实际安全问题。问题不只是模型能否识别恶意指令，还在于模型判断失误时，围绕模型构建的系统是否限制了智能体能够访问的资源、使用的权限以及采取的行动。

智能体让熟悉的控制措施成为新的系统性问题

企业已经知道如何管理身份、隔离工作负载、限制网络、测试软件、收集日志以及响应事件。这些控制措施依然必不可少。

智能体改变了这些控制措施必须协同工作的方式。人们可以在运行时通过自然语言指令重新编程智能体。它能够选择实现目标的方法、调用工具、使用委派的凭据，并创建其他智能体。随着模型、提示词、工具、MCP 服务器和权限的变化，它实际具备的能力也可能变化。

编程智能体可以说明这一问题。让它修复一个缺陷，它可能读取源代码和内部文档、安装软件包、调用外部 API、将任务委派给子智能体，然后提交修改。每个步骤单独看都可能合理。风险来自这些步骤的组合：同一个可以在运行时重新编程的执行主体，凭借委派权限跨越多个系统，而速度超过了人逐项审查决策的能力。

因此，安全团队需要针对每一个智能体回答三个问题：

正在运行的是什么，它能做什么？
它是否始终处于批准的边界之内？
如果出了问题，我们能否证明发生了什么，并将其停止？

大多数组织能够回答其中一部分问题。但要针对同一个智能体、同一个任务和同一次运行，覆盖所有模型、工具、凭据、策略决策及下游行动来回答这些问题，能做到的组织就少得多。

Agent Baseline：构建、运行与治理企业智能体的开放蓝图

Agent Baseline 由 Docker、Snyk 和 Keycard 共同创建，用于定义企业部署智能体时应满足的最低安全结果。

原文发布时的 v1.0 草案在六项结果下规定了 35 项控制措施：

发现（Discover）：准确记录每一个智能体，以及其负责人、用途、组件、依赖和实际访问能力。
约束（Constrain）：将智能体的运行时、数据、工具、网络可达范围、计算资源及运行时长，限制在已批准用途所必需的范围内。
授权（Authorize）：将具有实质影响的操作绑定到明确的身份、任务、目标、范围和有效期。
观测（Observe）：通过稳定的运行 ID 或跟踪 ID，关联意图、身份、策略、工具使用、行动和结果。
验证（Validate）：在智能体实际运行的配置和环境中测试它，然后核验其输出与结果。
响应（Respond）：停止智能体、撤销其权限、隔离受影响的组件、保存证据并确定影响范围。

我们在 Black Hat 2026 的“保护你的 AI 智能体：通往软件工厂之路”活动中正式发布了 Agent Baseline，现场座无虚席。如果想了解活动情况，可以观看下方视频。

观看原文演讲视频：Eli Aleyner 谈智能体安全

Eli Aleyner，Docker 战略副总裁

Agent Baseline 的实际应用

下面说明这套基线如何遏制前面的客服工单事件。

“发现”确定哪些资源面临风险。智能体注册表标明负责人和用途、实际运行的模型与工具、可查询的数据库、可使用的凭据，以及能够调用的下游智能体。这是当前运行时的证据，而不是六个月前批准的配置。

“约束”切断外传路径。智能体在隔离环境中运行，其能力配置专为客服任务设计。文件系统访问受到限制，网络策略默认拒绝未经批准的目的地址。当它尝试访问外部地址时，请求会失败并产生证据，而不是悄无声息地成功。

“授权”限制访问能力被攻陷后的价值。智能体不携带拥有广泛数据库权限的长期凭据。它获得的是短期权限，绑定客服任务、允许访问的记录和允许执行的操作。如果它委派工作，下游智能体获得的权限不能超过原始智能体所持有的权限。

“约束”和“授权”共同让影响范围可以衡量；在事件发生前做到这一点，远比发生时才衡量更好。被攻陷的一次运行可能向三个方向扩展：在主机上可以执行什么、接触什么；可以证明并使用什么身份；可以对外连接到哪里。每个方向都有相应的控制措施缩小其范围。

被阻止的请求和异常查询归入同一个运行 ID。这就是“观测”：提供能够关联起来的证据，避免一周后还要从五份日志拼凑经过。这也并非意外，因为“验证”已经在智能体实际运行的配置下测试过提示注入攻击。

“响应”遏制事件。停止这次运行，撤销它当前有效的授权，保存证据，并界定受影响的客户记录，使团队明确知道该次运行究竟接触了哪些数据。调查期间，关键工单继续通过已批准的人工备用流程处理。

这些机制都不依赖模型始终行为正确。大多数团队已经实施其中三到四种控制措施；常见缺口在于它们没有相互连接，因此控制在某处触发，证据却落在另一处。

在智能体的十年中保护组织

智能体可以完成范围广泛的任务。像人类工程师一样，一个智能体能够顺畅地跨越开发的内循环与外循环，阅读 PRD、编写代码、提交修改，最终将变更推向生产环境。它还可以非常迅速地完成这些工作，使用不同工具，并创建并行工作的子智能体；这些子智能体会使用原始智能体的工具和认证能力。

在与客户合作的过程中，智能体治理已经成为反复出现的要求。他们希望获得编程智能体的生产力，同时避免让智能体不受约束地访问开发者机器、凭据、源代码和外部服务。

这推动了Docker Sandboxes 和 Docker AI Governance 的开发。前者是让 AI 智能体安全运行的 microVM 沙箱，后者是集中式控制层，用于管理组织内 AI 智能体能够访问哪些资源、执行哪些操作。这些新产品与现有的 Docker MCP Gateway 和 Docker Hardened Images 一起，为各种规模的组织提供管理智能体风险的基础设施。