OpenKruise Agents 怎样限制 Agent Sandbox 的工具权限

如果 Agent Sandbox 能访问 MCP 服务，工具权限就不能只写在系统提示词里。OpenKruise Agents 提供的做法是：先用 SecurityProfile 或 GlobalSecurityProfile 选中发起请求的 Pod，再用 mcpToolPolicy 检查 JSON-RPC tools/call 中的精确工具名，默认拒绝，按白名单放行。

官方地址：https://openkruise.io/kruiseagents/

下面按一次“Agent 想调用未授权工具，但请求仍然到达外部 MCP 服务”的故障复盘来拆解。文章只讨论外连工具调用这一层，不把 Kubernetes RBAC、容器内文件权限和模型提示词混成一个开关。

先看影响面：Sandbox 能运行，不代表工具都能用

这类故障通常有两个相反症状：一是 Agent 调用 delete_record、write_file 等高风险工具时没有被拦截；二是运维人员加了一条“允许 MCP”的规则后，连不在预期范围内的域名也能访问。根因不是 Sandbox 生命周期失控，而是把“能否到达 MCP 服务”和“到达后能否调用哪个工具”当成了同一项权限。

OpenKruise Agents 的组件边界可以这样记：

• sandbox-manager 和控制器负责生命周期、Claim、池化等管理面。
• sandbox-gateway 和流量控制面处理进出 Sandbox 的网关流量。
• TrafficPolicy 更适合做目的地可达性；SecurityProfile 才负责 HTTP L7 条件以及 MCP 工具策略。

触发条件：规则选中了错误的请求对象

SecurityProfile.spec.selector 选择的是发起请求的 Pod，而不是外部服务。匹配条件中的域名、协议、路径等再限制具体请求；如果 selector 为空，它会匹配该命名空间中的所有 Pod。于是，下面三种配置很容易让结果偏离预期：

1. 只写了 MCP 域名，没有用 selector 限定哪一类 Sandbox 可以调用。
2. 把 tools/list 或 initialize 当成工具执行请求，误以为它们也会被工具名规则拦截。
3. 请求走了直通路径，没有经过网关/EPE，却拿“策略对象已经创建”当成了生效证据。

正确的排查顺序是先确认调用方标签和实际网关路径，再看 MCP 请求是否属于 tools/call。OpenKruise Agents 的文档明确说明，mcpToolPolicy 只作用于 JSON-RPC 的 tools/call，匹配的是 params.name 的精确工具名；列工具和初始化请求会继续通过。

根因修复：把允许的工具写成默认拒绝白名单

最小策略可以从下面这个 namespaced SecurityProfile 开始。示例中的域名、路径和工具名是占位值，部署时替换成自己的 MCP 服务边界；YAML 注释说明了每个关键字段的职责。

apiVersion: agents.kruise.io/v1alpha1
kind: SecurityProfile
metadata:
  name: mcp-tool-whitelist
  namespace: agent-workloads
spec:
  selector:
    matchLabels:
      app: research-agent
  rules:
    - name: protect-mcp-tools
      match:
        - domains:
            - mcp.example.com
          schemes:
            - https
          paths:
            - type: Prefix
              value: /mcp
      actions:
        mcpToolPolicy:
          # 默认拒绝，只有下面明确列出的工具可以执行。
          defaultAction: deny
          # 请求体无法按支持的 MCP 版本解析时也拒绝。
          unsupportedVersionAction: deny
          denyResponse:
            statusCode: 403
            body: MCP tool is not permitted
          rules:
            - method: tools/call
              toolNames:
                # 这里只放业务确实需要的低风险工具。
                - read_file
                - search_docs
              action: allow

这段配置的关键不是工具列表有多少，而是默认动作。使用 defaultAction: allow 时，请求体不可读或工具名无法解析的调用可能按设计被放行；白名单场景应使用 deny。文档还规定了工具规则按文档顺序采用首个匹配结果，因此不要用空的 toolNames 规则覆盖前面的精细规则。

如果要做集群级基线，可以把同样的规则放进 GlobalSecurityProfile，并认真设置 priority。全局和命名空间级 profile 会进入同一排序，低优先级数值先执行；匹配并不是“第一个 profile 命中就停止”，只有终止动作才会结束后续链。

防复发：权限策略还要覆盖三处边界

第一，别把 bypass 当成普通 allow。它会转发请求并跳过剩余规则，但会保留前面已经发生的变更；如果目标只是控制目的地可达性，应优先考虑 TrafficPolicy，不要用 bypass 代替网络策略。

第二，给被拒请求加审计。audit 是异步 webhook，只记录最终决策，不改变放行或拒绝结果；它不属于 TrafficPolicy，而属于 SecurityProfile 及其全局版本。审计接收端不可用时，不能把“收到审计”当作请求是否被拦截的唯一依据。

第三，确认流量确实经过网关。文档指出，直通路径不会进入 EPE；如果 Sandbox 以 root 运行，或拥有 NET_ADMIN、SYS_ADMIN 等能力，也可能绕过 ACL。因此生产环境应叠加 Kubernetes NetworkPolicy、节点防火墙或云安全组，形成基础设施层的出口限制。

最后，工具权限与命令、文件权限仍是两条链。commands.run 和文件读写依赖注入 agent-runtime，而 MCP 工具白名单控制的是网关看到的 tools/call。前者是否存在，不会自动给后者授权。

常见疑问

只允许工具名，能不能限制工具参数？

本文对应的 mcpToolPolicy 示例只按方法和精确工具名做允许/拒绝。更细的业务参数校验仍应放在 MCP 服务自身，并配合身份、审计和网络出口控制。

策略创建成功，为什么请求还是能出去？

先查调用 Pod 是否被 selector 选中，再确认请求经过 sandbox-gateway 和 EPE，最后检查规则是否因编译错误保留了上一版。策略对象存在不等于每条流量都会经过这条链。

最小可行的权限边界是：用 selector 限定谁能访问，用域名与路径限定访问哪条网关路由，再用 mcpToolPolicy 配合 defaultAction: deny 精确放行工具；同时用基础设施网络策略防止直通和高权限容器绕过。