使用防护规则和限流保护 MCP 工具调用

核心要点

• 保护 MCP 工具调用需要四项独立控制：调用方身份、工具授权、上游凭证，以及运行时限制或内容策略。
• AISIX AI Gateway 将调用方 API key 与向上游 MCP Server 或 REST API 提供的凭证分开。
• 请求和并发限制控制工具调用量；MCP 调用不携带模型 Token，因此 Token 限制不会计量 MCP 调用。
• 按 Server 限制可以防止针对一个 MCP Server 的循环耗尽调用方在所有其他 Server 上的可用额度。
• AISIX 防护规则可以在上游调用前检查工具参数，并在结果返回客户端前检查文本内容块与 structuredContent 中的字符串值。
• 防护规则阻断会返回 HTTP 200 和标记为 isError: true 的失败工具结果；输入阻断时，请求绝不会到达上游 Server。

AI 智能体可以把一项人工请求转换为一连串机器操作。一个规划循环可能先搜索操作手册，再查询库存系统、创建工单、检查部署状态，并在结果含糊时重复其中某项调用。这种自主性很有价值，却也改变了 API 请求的风险特征。

有效凭证不再只代表一次可预测的调用。它可能授权一个由软件执行的循环，而调用量与参数都在运行时决定。上游工具也可能返回不应进入模型上下文或抵达最终用户的敏感文本。因此，只保护连接并不足够。

有效的 MCP 工具安全会把身份、流量和内容视为不同的执行问题。某项控制只回答其中一个问题，就不应被当作已经解决其余问题。

AISIX AI Gateway 会在 MCP tools/call 链路上应用多层控制：验证调用方身份；确认其有权访问带命名空间的工具；检查请求和并发限制；评估适用的 AISIX Cloud 预算；通过防护规则检查参数；附加已配置的上游凭证；检查受支持的结果内容；并记录用量事件。每一层针对不同的故障模式。

建立两条独立的认证边界

MCP Gateway 位于两种信任关系之间：

1. MCP 客户端向网关认证。
2. 网关向上游 MCP Server 或 REST API 认证。

AISIX 使用调用方 API key 处理第一条边界。该 key 标识发起调用的应用或智能体，并携带其模型、MCP 工具和 A2A 访问设置。MCP 客户端通过 Authorization: Bearer <caller-api-key> 将它发送到 AISIX /mcp 端点。

第二条边界配置在已注册的 MCP Server 上。AISIX 支持：

调用方 API key 不会转发给上游。上游密钥由 AISIX 持有，不会暴露给客户端。这种分离让安全团队能够撤销一个调用方而无需轮换后端凭证，也可以轮换一项后端凭证而无需更新所有智能体。

如果客户端和 Server 实现了基于 OAuth 的 MCP 流程，应以 MCP 授权规范为协议参考。AISIX 文档中的上游 OAuth2 模式专门指网关到 Server 认证所采用的客户端凭证授权流程，不应被描述为交互式最终用户授权。

使用 OAuth2 上游认证时，AISIX 会根据配置的 client_id、token_url、secret 和可选作用域获取 Token，并复用到接近过期为止。如果上游以未授权为由拒绝该 Token，AISIX 会清除缓存，并在下一次调用时申请新 Token。

开源版资源配置中的密钥应通过环境变量传入，而不是提交到 YAML 文件。还要注意，在宿主机 Shell 中新增或修改环境变量，并不会改变已经运行的网关进程环境。密钥值发生变化时，应重新创建进程或容器。只有当进程已经拥有所有被引用的变量时，单纯重载配置才适用。

1flowchart LR
2    Client["MCP 客户端"] -->|"调用方 API key"| AISIX["AISIX AI Gateway"]
3    AISIX --> Authz["工具授权"]
4    Authz -->|"网关持有的 Bearer Token"| GitHub["MCP Server"]
5    Authz -->|"网关持有的 API key"| ERP["OpenAPI REST 服务"]
6    Authz -->|"OAuth2 客户端凭证"| Orders["受保护的 MCP Server"]

凭证故障应保持较小的影响范围。如果 ERP Token 被撤销，ERP 工具会失败，但 AISIX 不会泄露凭证，其他已注册 Server 也会继续运行。

通过分层限流阻止失控智能体

认证确定调用方是谁，却不会限制其动作有多激进。智能体循环需要专门面向工具流量设计的请求和并发限制。

AISIX 调用方 API key 可以配置模型与 MCP 流量共享的通用 rate_limit。对 MCP 链路直接有用的字段包括每秒、每分钟、每小时或每天请求数（rps、rpm、rph 和 rpd），以及 concurrency。

Token 限制需要格外谨慎理解。tools/call 请求不携带模型 Token，因此不会增加 tpm 或 tpd 计数器。单独使用 Token 限制无法控制 MCP 调用量。但是，如果同一个调用方 key 上的模型流量已经耗尽 Token 窗口，该 key 的工具调用也会被拒绝，直到窗口重置。这种共享 key 行为也说明，应用是否应对模型和工具流量共用同一个 key，需要经过明确决策。

AISIX 还支持 mcp_rate_limits，即从已注册 MCP Server 名称到请求与并发限制的映射。它可以隔离工具来源。智能体即使耗尽了 payments 配额，仍可继续使用 runbooks，前提是调用方级限制也没有耗尽。

1_format_version: "1"
2
3api_keys:
4  - display_name: operations-agent
5    key_env: OPERATIONS_AGENT_KEY
6    allowed_models: []
7    allowed_tools:
8      - runbooks__*
9      - payments__get_status
10    rate_limit:
11      rpm: 120
12      concurrency: 10
13    mcp_rate_limits:
14      runbooks:
15        rpm: 100
16        concurrency: 5
17      payments:
18        rpm: 10
19        concurrency: 2

每一项匹配的限制都必须通过。一次 payments__get_status 调用既计入调用方通用限制，也计入 payments 限制。未出现在 mcp_rate_limits 中的 Server 仍受调用方通用限制约束。

AISIX 只在 tools/call 上检查这些控制。即使客户端被限流，仍然可以初始化会话，并列出它有权发现的工具。工具调用超限时，AISIX 会在联系上游前返回 HTTP 429，同时把被拒绝的尝试记录为用量事件。

AISIX Cloud 预算提供另一项共享 key 关卡。如果覆盖调用方 API key 的预算已经耗尽，其 MCP 工具调用会在路由到上游前被拒绝。MCP 调用本身不会产生模型 Token 成本，而且预算仍然作用于整个 key，而不是单个 MCP Server。应使用请求或并发限制约束工具调用量，不要把 Cloud 预算描述为按工具计费或 MCP Token 计量器。

使用防护规则检查工具参数和结果

限流回答“调用频率多高？”，防护规则回答“哪些内容正在经过这次工具调用？”。两者相互补充。

AISIX 只对 tools/call 运行 MCP 防护规则。初始化握手和 tools/list 不携带工具参数或结果，因此不会被扫描。对于工具调用，网关会解析一次防护规则链，并评估两个方向：

• 输入： 在上游请求前检查参数对象。如果防护规则将其阻断，AISIX 会拒绝调用，绝不会联系 MCP Server。
• 输出： AISIX 会解码并检查工具结果中的文本内容块，还会遍历 structuredContent 并扫描其中的字符串值，从而覆盖没有在文本块中重复的机器可读输出。它不会扫描字段名称或序列化后的 JSON 包装结构，避免 Schema key 或转义造成误导性匹配。

如果附加了防护规则的结果无法按照预期响应格式解析，AISIX 会将其阻断，而不是返回无法检查的内容。没有结果载荷的协议错误则没有输出可供扫描，会直接通过。

下面的开源配置创建一项简单的双向关键词策略。在开源网关中，resources.yaml 中启用的每项防护规则都会应用于该网关处理的所有请求：

1guardrails:
2  - name: block-sensitive-markers
3    enabled: true
4    hook_point: both
5    enforcement_mode: block
6    kind: keyword
7    patterns:
8      - kind: literal
9        value: supersecret-banned-token
10      - kind: regex
11        value: "(?i)private[-_ ]key"

在 AISIX Cloud 中，应将防护规则附加到可以作用于非模型流量的范围：环境、特定 MCP Server、调用方 API key 或团队。mcp_server 作用域可以将防护规则从整个环境缩小到路由至某个已注册 Server 的调用。模型专属附加不会应用于 MCP，因为工具调用不包含模型。

enforcement_mode: block 会拒绝匹配的输入或输出。monitor 会记录匹配但允许调用继续，适合在强制执行前衡量误报。安全发布通常先在 monitor 模式下使用代表性流量测试，调整字面量或与 Rust 兼容的正则表达式模式，再将规则切换到 block 模式。

防护规则阻断 MCP 调用或结果时，AISIX 会返回 HTTP 200 和正常的 JSON-RPC result，其中 isError 为 true，而不是防护规则阻断模型请求时使用的 HTTP 422：

1{
2  "jsonrpc": "2.0",
3  "id": 1,
4  "result": {
5    "content": [
6      {
7        "type": "text",
8        "text": "tool call blocked by content policy (guardrail 'block-sensitive-markers')"
9      }
10    ],
11    "isError": true
12  }
13}

这是失败的工具结果，而不是 JSON-RPC 协议错误。请求本身格式有效，因此调用智能体会收到可供理解和处理的工具输出。阻断消息会标明触发的防护规则，但不会重复命中的敏感内容。

相关用量事件会把 guardrail_blocked 设为 true。AISIX 只检查链路中的内容，用量事件不会存储工具参数或结果。

可以使用 AISIX MCP 设置指南中的 Everything 测试 Server 验证两条分支。启用上述关键词防护规则后，第一个调用应返回正常 result；第二个调用应返回 HTTP 200，且 result.isError 为 true，而且上游不应收到该请求：

1curl -sS "$AISIX_PROXY/mcp" -H "Authorization: Bearer $AISIX_MCP_KEY" \
2  -H "Content-Type: application/json" \
3  -H "Accept: application/json, text/event-stream" \
4  -d '{"jsonrpc":"2.0","id":11,"method":"tools/call","params":{"name":"everything__echo","arguments":{"message":"health check"}}}'
5
6curl -sS -w '\nHTTP %{http_code}\n' "$AISIX_PROXY/mcp" \
7  -H "Authorization: Bearer $AISIX_MCP_KEY" -H "Content-Type: application/json" \
8  -H "Accept: application/json, text/event-stream" \
9  -d '{"jsonrpc":"2.0","id":12,"method":"tools/call","params":{"name":"everything__echo","arguments":{"message":"supersecret-banned-token"}}}'

对于被阻断的调用，应确认输出状态为 HTTP 200、解析后的 result.isError 值为 true，并且不存在顶层 JSON-RPC error 字段。同时，还应在测试 Server 上确认请求计数没有增加。

防护规则不是完整的智能体安全系统。关键词或外部内容策略无法判断每项业务动作是否合理。工具授权、后端验证、高影响工作流的人工审批、凭证范围控制和审计仍然必不可少。

纵深防御的 MCP 请求流程

稳健的设计会尽早拒绝不合规调用，并在每个边界记录结果。

1sequenceDiagram
2    participant Client as MCP 客户端
3    participant AISIX as AISIX AI Gateway
4    participant Controls as 访问、限制与防护规则
5    participant Upstream as MCP Server
6    participant Telemetry as 用量链路
7
8    Client->>AISIX: tools/call + 调用方 API key
9    AISIX->>Controls: 认证并授权工具
10    Controls->>Controls: 检查调用方和按 Server 限制
11    Controls->>Controls: 检查适用的 Cloud 预算
12    Controls->>Controls: 检查输入参数
13    alt 访问、限制或预算拒绝
14        Controls-->>AISIX: 拒绝
15        AISIX->>Telemetry: 记录被拒绝的尝试
16        AISIX-->>Client: 授权结果或 HTTP 429
17    else 输入防护规则阻断
18        Controls-->>AISIX: 阻断输入
19        AISIX->>Telemetry: 记录防护规则阻断
20        AISIX-->>Client: HTTP 200 + result.isError=true
21    else 允许
22        AISIX->>Upstream: 携带上游凭证转发
23        Upstream-->>AISIX: 工具结果
24        AISIX->>Controls: 检查文本和结构化结果值
25        alt 输出被阻断
26            AISIX->>Telemetry: 记录防护规则阻断
27            AISIX-->>Client: HTTP 200 + result.isError=true
28        else 输出允许
29            AISIX->>Telemetry: 记录成功调用
30            AISIX-->>Client: 工具结果
31        end
32    end

可以用一个简洁的安全测试矩阵验证该流程：

应使用非生产标记和受控上游执行测试。验证输入策略或限制是否在路由前阻断时，不要只看调用方响应，还应确认上游请求计数。

MCP 工具安全常见问题

Token 限制会计量 MCP 工具调用吗？

不会。MCP 工具调用不包含模型 Token，因此应使用请求和并发限制。同一调用方 key 的模型 Token 限制耗尽后，仍可能拒绝后续工具调用，直到窗口重置。

AISIX Cloud 预算是否限定于一个 MCP Server？

不是。预算覆盖调用方 key。应使用 mcp_rate_limits 为每个 Server 设置独立的请求和并发上限。

防护规则会扫描哪些 MCP 内容？

它会在路由前检查 tools/call 参数，并在交付前检查结果中的文本内容块和 structuredContent 中的字符串值。它不会扫描 initialize、tools/list、结构化字段名称或序列化后的 JSON 包装结构。

保护工具调用的完整生命周期

MCP 工具安全并不等于一个插件或一项凭证，而是一系列独立决策：识别调用方、授权工具、约束请求量、检查参数、向上游认证、检查结果，以及记录最终结果。

可以从精确工具授权和分离调用方与上游凭证开始。在向自主智能体授予具备写能力的工具前，先添加请求与并发限制。如果某项依赖成本高或稳定性较弱，应采用按 Server 限制。先在 monitor 模式下部署防护规则，用有代表性的工具参数与结果进行验证，再配合明确的响应流程启用强制策略。

下一步是让这些决策在运维中可见。参阅 MCP 可观测性：监控 AI 智能体的每次工具调用，或直接根据 AISIX 指南配置上游认证、限流与预算和 MCP 防护规则。