MCP 网关远远不够：AI 代理需要可验证身份、授权和证明

MCP 网关无处不在，这是一件好事

模型上下文协议（MCP）已迅速成为代理连接外部系统的默认方式。它是一种通用协议，可将代理连接到数据库、SaaS 平台、代码运行器、支付系统以及内部服务。只要您的代理能够执行有实际价值的操作，它几乎一定会通过 MCP 完成。

因此，MCP 网关的快速普及并不意外。如今，几乎每家基础设施供应商、每家服务网格公司，以及越来越多的开源项目和初创企业，都在推出 MCP 网关解决方案。它们确实能够提供实际价值，包括集中式路由、服务发现、凭据管理，以及针对 MCP 服务器连接的基础访问控制。

但这些只是基本要求，并不是安全性的终点。

如果企业正在将 AI 代理从原型阶段推进到生产环境，让代理代表业务调用 API、执行代码、查询敏感数据，并与其他代理交互，那么路由和访问控制虽然必要，却远远不够。真正棘手的安全问题在于可验证身份、授权和可验证证明，而 MCP 网关无法解决其中任何一项。

MCP 网关留下的三大缺口

企业在将 AI 代理部署到生产环境之前，必须回答三个关键问题。而 MCP 网关对这三个问题都没有给出答案。

缺口 1：身份。“这个代理是谁？”

MCP 网关只在连接层进行身份验证。当请求携带有效的 API 密钥或 OAuth 令牌到达时，网关会将其与列表进行比对，匹配后便允许请求通过。这只能说明凭据有效，却无法说明真正发起调用的是哪个代理。

在实际场景中，大多数 AI 代理都依赖硬编码的 API 密钥或共享的服务账户令牌运行。当代理 A 和代理 B 使用同一组服务凭据连接 MCP 服务器时，网关看到的是两个完全相同的调用方。代理无法通过加密方式证明自身身份，也没有由证书背书、可供下游服务独立验证的身份声明。

这类问题在微服务领域早已通过 SPIFFE 和 mTLS 得到解决。每个服务都会拥有一个可验证的加密身份。当服务 A 调用服务 B 时，接收方能够准确知道调用方是谁，并能够验证这一身份。而如今，基于各类框架构建的 AI 代理并不具备这样的机制。它们运行在身份缺失的环境中，而 MCP 网关并不能改变这一点。

在实际调用中，这种差异非常明显。如今，大多数代理调用到达工具服务器时，通常只是这样的形式：

Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...

在这种模式下，工具服务器收到的只是一个令牌；它可能被多个代理共用，也可能已经长期未轮换。这个令牌无法说明它由哪个工作负载生成、当时处于怎样的运行上下文，或自上次签发以来是否已经轮换。工具服务器只能选择接受或拒绝它。这基本就是当前身份机制所能提供的全部信息。

采用基于 SPIFFE 的工作负载身份后，同一个调用会携带由证书背书的 SVID，也就是一种经过加密签名的身份声明，其形式如下：

spiffe://diagrid.io/ns/payments/fraud-detection-agent

这个 URI 并非敏感凭据，也无需保密。它是由平台签发的可验证声明，绑定到特定信任域中特定命名空间内运行的特定工作负载，并会自动轮换。任何信任同一信任域的服务，都可以验证其真实性。接收请求的工具服务器不再只是检查“这个凭据是否在我的允许列表中？”，而是会进一步验证：这是哪个工作负载？它运行在哪里？它是否就是应该发起此次调用的工作负载？

第一种模式保护的是凭据，第二种模式保护的是身份。对于需要跨服务、数据库和支付系统自主运行的 AI 代理而言，这一区别正是普通访问控制与零信任安全之间的关键差异。

从标准化角度来看，IETF WIMSE 工作组和AAIF 身份与信任工作组正在积极讨论将 SPIFFE 用于工作负载身份。

如需深入了解身份相关概念，请阅读《代理身份：AI 仍缺失的基础层》

缺口 2：不止于路由的授权。“这个代理被允许做什么？”

设想一个代理能够访问客户数据库 MCP 服务器。网关允许它建立连接，代理持有有效凭据，路由规则也允许它访问该服务器。此时，代理正处于某个工作流的执行过程中，大型语言模型（LLM）基于一条含义模糊的指令进行推理，并生成了一次调用，请求删除符合宽泛筛选条件的记录。网关并不会阻止这一操作。因为路由规则只说明该代理可以访问这台服务器，却无法限制代理连接成功之后具体可以执行哪些操作。

这正是 MCP 网关留下的授权缺口。它们能控制访问，即哪些调用方可以连接哪些服务器；但无法控制行为，即某个具体代理身份在特定工作流上下文、特定条件下，可以执行哪些操作。对于确定性软件而言，这一区别可能并不明显，因为调用路径通常可以提前分析和推导。但对于 AI 代理而言，其行为本身就具有涌现性和非确定性，这一区别决定了安全模型是真正有效，还是只是看起来安全。

生产环境真正需要的，是工作流层面的默认拒绝授权机制：通过声明式策略明确规定哪些代理身份可以调用哪些工作流和工具，并由平台层强制执行，不受大型语言模型（LLM）具体决策影响。这些策略应写入基础设施配置，由平台团队和安全团队负责管理，接受版本控制，并具备可审计性，而不是散落在应用代码中，任由其被绕过、覆盖或遗忘。

缺口 3：证明。“这个代理做过什么，我们能证明吗？”

MCP 网关会生成日志。日志很有用，但日志并不等于证明。

企业日志基础设施已经有了显著改进。现代 SIEM 平台可以让日志管道具备防篡改能力，配合合适的工具，也可以实现不可变的审计追踪。但即使日志被完整保存下来，它回答的仍然不是正确的问题。合规团队真正关心的是：“能否证明在代理执行这次工具调用之前，已经有人批准过该操作？”而一条写着 tool: transfer_funds, status: approved, user: alice 的日志记录，并不能构成答案。它无法提供加密级别的保证，证明这些事件确实按照记录中的顺序发生过。

在多代理系统中，这个问题会进一步放大。当代理 C 发起一次破坏性工具调用时，这一操作是否经过代理 B 授权？代理 B 是否又经过代理 A 授权？代理 A 是否由人工触发？如果没有一条能够跨越每个代理边界传播的签名责任链，就无法重建或验证这条决策链。

签名链中的条目并不是普通日志记录，而是一个随工作流一同传递、结构化且可通过加密方式验证的对象。简化后的条目如下：

{
  "step": "fraud_check_passed",
  "agent": "spiffe://diagrid.io/ns/payments/sa/fraud-detection-agent",
  "timestamp": "2025-04-18T14:23:11Z",
  "result": "approved",
  "signature": "eyJhbGciOiJFUzI1NiJ9..."
}

每个条目都会由生成它的身份进行签名。当这条链到达下游工具服务器时，它会携带完整历史：谁启动了工作流、执行了哪些验证步骤、是否经过人工审批，以及每个条目由哪个代理生成。工具服务器会在执行操作之前验证每一个签名。如果某个条目无法验证，例如签名身份未知、签名不匹配，或缺少预期步骤，调用就会在执行前被拒绝。

《欧盟人工智能法案》、美国证券交易委员会（SEC）正在形成的新指导方针，以及不断演进的 SOC 2 要求，都指向同一个明确预期：企业必须能够证明自己对 AI 系统具备可验证的控制能力和问责能力。

企业真正需要的是一份针对每个代理工作流中每个步骤的记录。这份记录必须具备防篡改能力，并经过加密签名。它不是事后供人审查的日志，而是下游服务在采取行动前可以实时验证的证明。对于破坏性工具调用，除非签名历史能够证明该调用已经获得人工批准、相关验证步骤已经通过，并且调用代理具备相应授权，否则工具服务器应拒绝执行。MCP 网关并不具备这样的能力。

AI 就绪型基础设施应具备哪些能力

要弥补上述三个缺口，AI 平台层需要具备三项能力。这个平台层位于代理或应用代码之下，同时位于网络和计算资源之上。

含 MCP 服务器的 AI 平台架构图，展示三层堆叠结构——智能体框架、AI 平台、基础设施——MCP 服务器连接至 AI 平台层

加密代理身份

每个代理都需要一个基于 SPIFFE 的加密身份，也就是由平台自动签发并轮换的证书。当代理调用工具或另一个代理时，接收方服务会通过标准 mTLS 验证其身份。这不是请求头中的令牌，而是由证书背书的身份声明，并且建立在任何参与方都可以独立验证的信任链之上。这套方法已在微服务间通信安全中得到充分验证，如今可以进一步扩展，用来应对非确定性、自主型代理所带来的特殊挑战。

零信任工作流授权

如果只有身份而没有授权，身份本身并不能带来实际安全保障。平台团队和安全团队需要一套声明式、适合 GitOps 管理的策略，用来定义哪些代理身份可以调用哪些工作流和工具。默认安全策略必须是“全部拒绝”：凡未被明确允许的操作，一律阻止。这些策略必须能够在平台层强制执行。

这正是“这个代理可以访问这台服务器”与“这个特定代理身份只能在这个特定目标上调用这个特定工作流，除此之外不得执行其他操作”之间的区别。前者是网关能做到的事，后者才是生产环境真正需要的能力。

基于签名历史的策略即代码

粗粒度的“身份到工作流”规则是必要的，但还不够。真正关键的授权问题往往取决于上下文：这次工具调用之前是否已经完成欺诈检测？是否在过去 30 秒内经过人工批准？发起这次调用的代理，是否就是最初接收用户请求的那个代理？还是说，执行链路已经被劫持？

仅凭当前请求本身，无法回答这些问题。系统需要根据导致此次调用发生的完整工作流历史进行判断。通过在每个步骤中传递经过加密签名的执行历史，类似 Open Policy Agent（OPA）的策略引擎便可以在决策发生时，基于整条执行链评估 Rego 或其他策略语言：

allow_tool_call {
    input.history[_].step == "human_approval"
    input.history[_].step == "fraud_check_passed"
    input.history[_].agent == input.calling_agent
}

这类策略应在接收方执行，而不是由调用方自行判断。代理无法伪造历史记录，因为每个条目都由生成它的身份进行签名。这样一来，工作流历史本身就成为授权决策中可验证的输入。这与 OPA 已经用于 HTTP API 的 JWT 声明和请求上下文评估类似，只是现在扩展到了多代理、多工具执行链的端到端验证场景。

加密责任链

当代理跨服务边界协作时，每个步骤都必须经过签名。每个服务都会使用自身的身份证书，对累积的执行历史进行签名，从而形成一条防篡改的责任链。下游工具不只是检查“这个调用方是否有权限？”，而是会验证整条历史：谁启动了工作流、发生过哪些审批、通过了哪些验证步骤，以及链条中的每个身份是否都获得授权。

这不是事后由人工检查的日志，而是在每次工具调用之前就会被验证的加密证明。它能够实现仅靠路由无法完成的强制执行模式。例如，某个支付 MCP 工具可以拒绝执行，除非签名历史能够证明欺诈检测工作流已经通过，并且该交易已经获得人工批准。

实际运行方式

这些并不是停留在理论层面的要求。Diagrid Catalyst 是一个托管平台，用于在生产环境中运行基于 Dapr 的应用和 AI 代理，目前已经提供了上述所有能力。

以基础设施方式管理 MCP。MCP 服务器连接以 Kubernetes CRD 的形式声明，其中包含连接详情、凭据和访问范围。应用代码中不需要硬编码任何连接逻辑。凭据会在运行时从密钥存储中解析，并且绝不会暴露给代理代码。

持久化 MCP 工具调用。每一次 MCP 工具调用都会作为工作流，在 Dapr sidecar 中运行。如果进程在调用过程中崩溃，执行会从最近的检查点恢复。对于耗时较长的工具调用，例如数据库迁移、外部 API 调用序列或代码执行，即使发生进程或节点故障，也可以自动恢复并继续执行。

中间件钩子。在每次工具调用前后，都可以通过可配置的工作流钩子实现针对单个工具的授权、审计日志记录、速率限制、输入验证和成本控制，而无需修改代理代码。这些钩子本身也是工作流，可以组合使用，并可独立部署。您可以在这里接入 OPA 或其他策略引擎，在工具真正运行之前评估其签名历史。

声明式工作流访问策略。通过 Kubernetes CRD 控制哪些应用身份可以在目标应用上启动特定工作流和活动。调用方验证基于 SPIFFE/mTLS 身份完成。该策略支持 glob 模式、按调用方设置规则，以及命名空间级别的“全部拒绝”策略。一旦策略存在，所有未被明确允许的操作都会被拒绝。

签名历史传播。工作流可以选择将完整执行历史传递给子工作流和活动。每个参与工作流的身份，都会使用自身的身份证书对累积的历史记录进行签名。下游服务会在执行操作前验证整条链路，策略引擎也可以基于这些历史记录进行判断。

具备证明能力的人工介入。代理可以通过持久化工作流事件暂停执行，等待人工审批。当下游工具收到签名历史时，它可以通过加密方式验证审批确实发生过，而不只是依赖一条声称审批已完成的日志记录。

设想一个代理正在处理一笔超过预设阈值的客户退款请求。此时，工作流不会立即执行，也不会直接失败，而是会暂停并发出审批事件：

退款代理达到 $10,000 阈值
        │
        ▼
工作流暂停 — 发出审批请求
  — 向 payments-approvals 频道发送 Slack 消息
  — 在签名历史中记录待审批状态
  — 设置 30 分钟超时
        │
人工在 Slack 中审核
        │
        ├── 批准 → 工作流继续
        │             审批步骤经签名后追加到历史记录中
        │
        └── 拒绝 / 超时 → 工作流终止
                              拒绝结果会记录到签名历史中
        │
        ▼
退款工具收到调用
  — 验证签名历史中是否包含 human_approval 步骤
  — 确认审批时间戳是否处于策略允许的时间窗口内
  — 确认审批人身份是否具备授权
  — 仅在所有检查均通过后执行

这里的审批并不是事后添加的一条日志，而是执行历史中经过签名的一个步骤，工具服务器会在采取行动前对其进行验证。如果审批步骤缺失、已过期，或由无法识别的身份签署，工具调用就会被拒绝，而不是等到造成影响后才进行审计。

企业真正应该关注的问题

企业真正需要关注的，并不是是否要使用 MCP 网关。多数情况下，您确实需要它，而且 MCP 网关也应当成为入站连接管理的一部分。MCP 是协议本身，而企业还需要相应的基础设施，才能大规模管理 MCP 服务器连接，完成路由，并实现一定程度的速率限制。

真正关键的问题是：您的 MCP 基础设施，是否能够提供可验证身份、授权和证明能力？

您的 AI 平台能否准确识别发起调用的是哪一个代理？这里要看的不是使用了哪一组凭据，而是哪个经过加密验证的身份。它能否针对每个代理允许执行的操作，强制实施零信任和默认拒绝策略，并由平台团队统一管理，不受 LLM 具体决策影响？它又能否生成一条防篡改、经过签名的责任链，用来证明每个代理工作流中的每一个步骤，并让下游服务在执行操作前进行实时验证？

如果答案是否定的，那么您构建的并不是 AI 代理的安全层，而只是一个路由器。

而路由器远远不够。

深入了解 Catalyst。

联系专家