你的 Agent 权限比员工还大:在网关层治理 MCP 工具

大多数公司的 MCP 落地都遵循同一条曲线。第一周:有人把 coding agent 接到了文件系统服务上,效果神奇。第四周:已经有十五个 MCP 服务器 —— 数据库、内部 API、工单系统、部署工具 —— 散落在每个开发者的配置文件里。第八周:平台工程问出两个没人能回答的问题。

谁能调用哪个工具? 以及 出事的时候,审计轨迹在哪里?

按 agent 逐个配置的做法,把凭证散落到各台笔记本上,并且随着某人的 dotfiles 被 git pull,策略也在漂移。MCP 的能力恰是它的风险面:一个能发起退款的工具,不是你想靠「约定」来治理的工具。

解法是像对待模型访问一样对待工具访问 —— 一个权限平面,放在网关。四个模式可以达成这一点。

模式一:一个端点,多个服务器

把所有外部 MCP 服务器聚合到网关的一个端点上。每个服务器只配置一次 —— 端点、认证头、标签、优先级 —— 每个 MCP 客户端只连一个地方,带一把网关 key。

立竿见影的收益是运维层面的。接入新服务器变成一次网关配置变更,而不是对组织内每一份 agent 配置发一个 PR。下线一个被污染或已废弃的服务器变成一次变更,而不是在一堆笔记本上做排查。而「这个组织里到底哪些 MCP 服务器可达」这个问题,终于有了权威答案 —— 因为网关在结构上就是一个收口点。

模式二:工具级 ACL,与模型权限并列

只有聚合还谈不上治理。第二个模式才是策略真正落脚的地方:按工具做访问控制,并且表达在与「谁可以调哪个模型」同一套系统里。

把它们放到同一平面的理由是:它们回答的是同一个问题 —— 这个调用方,在这个上下文里,能不能执行这个动作? 把模型策略与工具策略拆到两个系统,必然导致两者漂移,而且这种漂移在事故把它暴露出来之前是不可见的。

实践中要紧的有两点:

• 新工具默认拒绝。 某个服务器新增一个工具时,它不应该自动对「所有能连到这个服务器的人」可用。新能力是一次策略变更,而策略变更应该经过评审。
• 用标签,而不只有白名单。 按敏感度或环境给工具分组,可以让策略表达「预发环境只允许只读工具,没有例外」,而不必逐个枚举工具名。

模式三:凭证留在网关

第三个模式是安全团队最关心的:服务器凭证应当由网关持有,永远不下发给 agent。

在常见的「按 agent 配置」形态下,每个开发者的机器上都放着数据库密码、工单系统 API token 和部署密钥 —— 因为 agent 需要它们去调工具。这是一个巨大且需要持续轮换的密钥面,而它存在的主要理由,只是为了让一台笔记本能够以自身身份,去直接访问它本不该直接对话的东西。

把凭证收在网关会把这个关系倒过来:agent 用自己的身份向网关认证,网关再去挂上游凭证。撤销某个人对某个工具的访问,从此是一次身份变更,而不是在每台机器上协同做一次密钥轮换。

模式四:审计每一次工具调用

最后,记录调用 —— 不只是模型流量,还有工具流量。一次创建、修改或删除东西的工具调用,恰恰是审计员一定会问起的那类事件,而事后从散落的客户端日志里重建它,过程相当不愉快。

要记录的内容是枯燥的那部分:谁调的、调了哪个工具、打到哪个服务器、什么时候、结果如何。不枯燥的部分是:把它记在跟模型调用同一个地方,于是一个查询就能回答「这个 agent 上周二做了什么」,而不是三个。

先做哪一步

如果你还处在落地早期,返工最少的顺序是:先做聚合(它是其余一切的前提),再把凭证移到网关,然后打开工具级策略,最后接审计。每一步都独立有用,而且都不需要 agent 侧做任何改动。

值得保留的那个不太舒服的判断是:你的 agent 工具面,是一个没经过访问评审就出现的授权边界。像对待模型平面那样对待它 —— 一个网关、一套策略系统、一条审计轨迹 —— 是唯一能撑过前几个服务器的版本。