Docker Sandboxes

MCP 访问策略让组织管理员控制开发者可以注册哪些 Model Context Protocol (MCP) 服务器， 以及智能体可以通过 Docker 的 MCP gateway 做什么。用这些策略批准受信任的服务器、撤销对 某个服务器的访问权限、要求对工具调用进行审批，以及限制在宿主机上运行的服务器。要注册 MCP 服务器并把它们连接到沙箱，请参阅 MCP gateway。

MCP 访问策略仅适用于服务器注册，以及由 Docker 的 MCP gateway 处理的请求。它们不治理由 智能体或 MCP 客户端在沙箱内直接配置并连接的 MCP 服务器。直接连接到远程 MCP 服务器属于 沙箱的出站流量，因此由组织网络访问策略决定沙箱能否访问该服务器。要同时 阻止这两条路径，请在 MCP 访问策略中屏蔽该服务器，并在网络访问策略中屏蔽其网络目标地址。

开发者无法用本地策略限制 MCP 活动。在没有强制执行组织策略的情况下，gateway 不会评估 Cedar 策略，并允许所有 MCP 活动。更多细节请参阅 组织策略如何与本地规则和 Kit 规则相互关联。

MCP 策略使用 Cedar 编写。Docker 定义了你的语句所使用的 MCP 命名空间，其中包括可以 匹配的行为、资源类型、属性和审批注解。本页的示例覆盖常见的访问模式。有关全部行为和 属性，请参阅 MCP 策略参考；有关 Cedar 语法，请参阅 Cedar 文档。如果你通过 AI Governance API 管理策略，那么 MCP 策略是一种 cedar_v1 策略，其语句是策略文本的一部分，而不是单独的规则。

本页说明 MCP 策略在哪里生效、如何在允许列表和阻止列表之间选择、常见任务的示例策略， 以及你的更改何时到达开发者。要创建 MCP 访问策略并设置其作用域，请参阅 创建和管理组织策略。

MCP 策略在哪里生效 ​

MCP 策略在服务器生命周期的两个点上生效。针对其中一个点的规则不会自动治理另一个点。

管理决策评估时点匹配依据
服务器能否被注册开发者运行 sbx mcp add 时注册名称和解析后的服务器属性，例如 identityURL
智能体可以通过 MCP gateway 做什么gateway 处理受管控请求时已注册的服务器名称、工具注解、资源 URI 或提示词名称

注册规则在开发者注册服务器时生效。它们只影响后续的注册，因此不会删除已保存的注册项，也 不会阻止通过 sbx mcp load 加载已有的注册项。

使用时规则适用于对已注册或已加载服务器的工具调用、资源读取和提示词获取。它们不会隐藏 任何内容：注册项依然保存在本地，工具和资源列表仍然可能显示策略在智能体尝试使用时予以 拒绝的条目。

开发者在注册服务器时为其选择名称。注册规则可以把该名称与解析后的服务器身份一起匹配。 在使用时，工具、资源和提示词都绑定到注册名称，因此针对已有服务器的规则必须匹配它注册 时使用的每一个名称。

内置的 gateway 工具，例如 mcp-add、code-mode 和 OAuth 授权辅助工具，同样在使用时 受治理。它们是 MCP::Primordial 资源，而不是某个已注册服务器的工具。更多细节请参阅 内置 gateway 工具。

允许列表和阻止列表策略 ​

当对某位开发者强制执行组织策略时，除非有匹配的 permit 允许，否则注册和受管控的 MCP 请求都会被拒绝。匹配的 forbid 会覆盖任何 permit，包括带 @requireApproval 的 permit。

允许列表策略请使用 permit。对于除显式限制之外都授予 MCP 活动的阻止列表策略，请从 一个不带行为的 permit 开始：

plaintext
permit (principal, action, resource);

该语句允许所有进入 Cedar 评估的 MCP 行为。再为策略必须强制执行的限制添加 forbid 语句。

你不需要在 Cedar 中匹配用户、团队、租户或角色。策略的组织或团队作用域决定它适用于 谁，并提供主体。

示例策略 ​

下面的策略展示了批准、确认、撤销和限制 MCP 服务器的常见做法。可以把它们合并到一条策略 中，也可以拆分到多条策略中，并把服务器名称和身份 URL 调整为你的服务器。

批准服务器 ​

对于允许列表，需要同时批准服务器注册和它的使用时能力。下面的策略仅当远程服务器以 example 注册且身份 URL 符合预期时才批准它。它允许对该已注册服务器的只读工具调用、 资源读取和提示词获取：

plaintext
// 允许使用预期的名称和身份 URL 进行注册。
permit (principal, action == MCP::Action::"register", resource)
when {
  resource in MCP::Server::"example" &&
  resource.identityURL == "https://mcp.example.com/mcp"
};

// 允许只读的工具调用。
permit (principal, action == MCP::Action::"invokeTool", resource)
when {
  resource in MCP::Server::"example" &&
  resource.readOnly == true
};

// 允许资源读取。
permit (principal, action == MCP::Action::"readResource", resource)
when { resource in MCP::Server::"example" };

// 允许获取提示词。
permit (principal, action == MCP::Action::"getPrompt", resource)
when { resource in MCP::Server::"example" };

同时匹配名称和身份 URL，可以确立一个规范的注册。它可以防止开发者用已批准的名称注册 另一个端点，或用另一个名称注册已批准的端点。如果开发者不需要某项能力，请删除对应的 资源或提示词 permit。

使用 MCP 征询要求确认 ​

使用 @requireApproval 要求每个请求都通过 MCP 进行确认。当请求匹配带注解的 permit 时，gateway 会向发出该受管控请求的同一个 MCP 客户端会话发送 elicitation/create 请求。 在由人操作的客户端中，操作智能体的人会看到该提示，并决定是否继续。

下面的策略要求对注册为 example 的服务器上的非只读工具进行确认。请把它与注册该服务器 或使用其其他能力所需的 permit 一同使用。注解字符串会作为征询中显示的原因：

plaintext
@requireApproval("non-read-only tool call")
permit (principal, action == MCP::Action::"invokeTool", resource)
when {
  resource in MCP::Server::"example" &&
  resource.readOnly == false
};

工具注解由服务器提供，属于建议性质。readOnly 对未声明该属性的工具默认为 false， 因此这种模式会要求对无注解的工具进行确认。

gateway 对匹配请求的处理方式如下：

mermaid
flowchart TD
  request["智能体发出受管控的 MCP 请求"] --> evaluate["gateway 评估 MCP 策略"]
  evaluate -->|"常规 permit"| forward["转发请求"]
  evaluate -->|"没有 permit 或匹配的 forbid"| deny["拒绝请求"]
  evaluate -->|"带 @requireApproval 的 permit"| elicit["向已连接的客户端发送 MCP 征询"]
  elicit --> confirm{"客户端返回明确确认？"}
  confirm -->|"否、不支持或出错"| deny
  confirm -->|"是"| reevaluate["使用审批摘要重新评估"]
  reevaluate -->|"允许"| forward
  reevaluate -->|"拒绝或已更改"| deny

提示会指明服务器或 gateway 工具，并包含注解原因。它不包含原始的工具参数。每个匹配的 请求都需要一次新的确认。确认之后，gateway 会使用一个把响应与被评估的授权请求绑定在 一起的摘要重新评估该请求。

把该机制作为由人操作客户端的确认护栏。它不构成管理员审批，也不构成职责分离。自主的 MCP 客户端可以用程序方式响应协议内的征询。对于绝不能执行的操作，请使用 forbid。

如果发起请求的客户端会话无法处理 MCP 征询、用户拒绝、征询失败，或重新评估未允许该 请求，则请求会被拒绝。sbx mcp add 无法显示征询，因此带 @requireApproval 的注册 permit 会导致拒绝。从无法传递征询的执行上下文发起的工具调用（包括 code-mode 内部的 调用）也会被拒绝。

撤销服务器访问 ​

要撤销某个被更宽泛规则允许的服务器的访问权限，请在注册环节和使用时环节都屏蔽它。注册 规则控制后续的 sbx mcp add 操作，使用时规则控制来自已注册或已加载服务器的请求。

通过匹配身份 URL 阻止今后注册该服务器：

plaintext
forbid (principal, action == MCP::Action::"register", resource)
when { resource.identityURL == "https://mcp.example.com/mcp" };

对该服务器的每个已注册名称，拒绝使用时的请求：

plaintext
forbid (principal, action == MCP::Action::"invokeTool", resource)
when { resource in MCP::Server::"example" };

forbid (principal, action == MCP::Action::"readResource", resource)
when { resource in MCP::Server::"example" };

forbid (principal, action == MCP::Action::"getPrompt", resource)
when { resource in MCP::Server::"example" };

注册项依然保存在本地，仍可被列出或加载。这些规则阻止为该身份 URL 建立其他注册项，并 拒绝以注册名称进行的受管控使用。如果该服务器还以其他名称注册过，也请为那些名称添加 使用时规则。

OAuth 授权辅助工具是内置的 gateway 工具，而不是已注册服务器的子项。要阻止智能体为该 服务器启动授权，请单独治理该辅助工具：

plaintext
forbid (principal, action == MCP::Action::"invokePrimordial", resource)
when { resource in MCP::Primordial::"example-authorize" };

限制在宿主机上运行的服务器 ​

本地 stdio 服务器在宿主机上运行，位于沙箱 VM 之外。这包括显式的宿主机命令，以及用宿主 Docker 启动的 OCI 打包的 stdio 服务器。有关这条边界的细节，请参阅 Docker Engine 隔离。

在本来允许注册的阻止列表策略中，拒绝在宿主机上运行的服务器类型：

plaintext
forbid (principal, action == MCP::Action::"register", resource)
when { resource.type == "local-stdio" };

local-stdio 涵盖显式命令（包括启动 Docker 容器的命令），以及用 --local 从镜像仓库 或清单元数据解析出的 OCI 打包 stdio 服务器。

更改何时生效 ​

注册规则在用 sbx mcp add 注册服务器时进行评估。修改注册规则本身不会删除已有注册项， 也不会停止已加载的服务器。

当沙箱发起受管控的 MCP 请求（例如工具调用、资源读取、提示词获取或内置 gateway 工具 调用）时，使用时规则由 MCP gateway 进行评估。一旦策略更改 同步到开发者的机器，使用时规则就会适用于 通过 gateway 后续发起的受管控 MCP 请求。

要阻止使用已经注册或加载的 MCP 服务器，请为已注册的服务器名称添加使用时规则。更多细节 请参阅撤销服务器访问。