MCP 不是连接器——它是您在代理时代的治理平台

框架问题：“连接器”低估了你实际做出的决定

2024 年 11 月，Anthropic 推出了模型上下文协议 (MCP)，作为连接 AI 系统与数据源和业务工具的开放标准。业界对新的集成规范一贯的做法是：将 MCP 归类为“管道”。适配器、传输协议，以及一种无需为每个模型和工具编写一次性粘合代码的简洁方法。所有这些都属于 true，但如果您是 CIO、CTO 或 CISO，这些都无关紧要。

以下是企业需要重新构建的框架。当客服人员能够调用读取客户数据或写入记录系统的工具时，无论你是否为其命名，你都创建了一个新的控制点。MCP 正是明确定义该控制点的地方。它不仅关乎客服人员如何访问你的工具，更关乎你如何决定谁在呼叫、使用谁的身份、哪些工具可见、如何记录每次呼叫以及每次呼叫的允许费用。这些都是管理问题，而非连接问题。

如果将MCP视为连接功能，您将优化错误的目标——覆盖范围、集成数量、首次呼叫时间。如果将其视为治理界面，您将优化真正决定代理是否可以安全大规模部署的因素：一个单一的、标准化的、可审计的接口，策略只需执行一次，即可在所有地方生效。

为什么“众多自定义集成”会悄然重塑治理 N 次？

大多数企业在进入代理时代时并非一无所有。他们往往带着一套集成方案：这里一个定制连接器，那里一个服务账户，还有一个团队两个季度前开发的 API 封装器，现在几乎没人记得了。这些方案在当时都是合理的。但加在一起，它们就构成了一个治理问题，因为每个方案都以自己的方式重新实现了身份、授权、日志记录和费率/成本控制——或者完全跳过了其中的一些环节。

可以预见的是，三种故障模式随之而来。首先，身份漂移：一个集成作为共享服务帐户运行，另一个集成模拟最终用户，第三个集成使用由更换团队的人创建的长期密钥 - 那么“这是谁干的？”有N个不同的答案，没有一个是完整的。其次，授权片段，因为工具可以执行的操作规则存在于具有 N 个审查节奏的 N 个代码库中；你在一个地方收紧的控制在另一个地方却默默地保持松散。第三，财务和审计首先感受到的就是数字的变化，因为通过两个集成路径回答的同一问题会返回两个答案。一旦利益相关者不再信任这些数字，代理计划就不再重要。

标准化方案并非万能或免费，但它改变了工作方式。无需管理 N 个集成 N 次，只需管理一个接口，并通过该接口公开工具即可。身份信息在单一位置建立。授权是接口的属性，而非每个连接器的习惯。日志记录统一，因此审计跟踪真正有效。而且，由于计算方法单一，数据不再波动。

身份和租户上下文：在入口处决定，而不是在工具中决定

治理界面首先要回答的问题是：调用代表谁的权限？在多租户 SaaS 环境中，这个问题比较微妙，因为其中涉及两个不同的因素：调用者的身份（哪个代理，代表哪个用户或服务）以及调用所在的租户环境（适用哪个客户的数据和权限）。如果将两者混淆，就会出现经典的“代理权限混乱”错误，即一个合法认证的代理被引导去执行它本不应该拥有的权限。

值得遵循的原则是从服务器端租户绑定中获取租户上下文，而不是从调用者会话中偶然断言的任何内容中获取。在我们自己的实现中，用于控制功能访问权限的客户层级是根据租户上下文确定的，绝不会从调用者的会话中读取——正是为了防止调用者通过提供更丰富的会话信息来扩大其影响范围。身份信息告诉您是谁在提问；租户上下文信息告诉您答案必须在哪些数据和权限范围内计算。这两项信息都在任何工具运行之前确定。

这也是您可以说代理不是用户的地方。控制台中的人有眼睛、犹豫和经理。代理有一个循环。您授予它的身份和上下文应该反映出它可以比您配置的任何人更快、更真实地行动。

工具授权：曝光是一种选择，而非默认设置

早期代理部署中最常见和最危险的默认设置是“全有或全无”暴露：将代理连接到平台并让它到达底层凭证可以到达的所有内容。在演示中很方便，在生产中却站不住脚。治理界面将每个工具的可见性和权限视为经过深思熟虑的、可审查的决策。

具体来说，授权应该是多轴的，而不是单一的开关。我们使用三轴模型——范围和层，其中层源自如上所述的租户上下文——这样，只有当调用者的范围允许并且租户的层包含它时，才会公开给定的工具。第二个轴的要点是，能力不仅取决于谁提出请求，还取决于哪些客户的权利有效。这使暴露表面保持诚实：将新工具添加到目录中并不意味着每个租户中的每个代理都可以访问该工具。

要向架构师提供的思维模型是一个产品目录，而不是一个总机。目录中的每个工具都通过决定谁可以调用它以及在什么租户条件下调用它而获得其位置。目前代理商不需要的工具根本不在目录中。“要么全有，要么全无”是一种 false 经济模式；“根据每个工具进行精心选择”是唯一能够经受住真正审核的策略。

失败关闭策略：读取与行动之间的不对称性

读取和写入在本质上并不等同，您的管理机制不应假装它们等同。读取操作出错会返回过时或空的数据——可恢复，通常不可见。写入操作出错则会改变记录系统、向真实客户发送消息或转移资金。犯错的代价是不对称的，因此默认姿态也必须是不对称的。

我们坚持的规则是写入工具失败时关闭。如果授权不明确，如果无法清楚地解析租户上下文，如果无法评估防护，则写入不会发生。这与许多集成继承的便利驱动的默认值相反，在默认值中，未评估的检查解析为“允许”，因此快乐的路径保持平稳。故障开放是指几周后您发现代理在从未批准过的条件下进行写作的方式。对于任何改变状态或触及客户的行为，安全的默认设置是拒绝，并且有举证责任来证明它是被允许的。

这里存在文化层面的问题。工程师优化的是系统正常运行；安全人员优化的是系统不以最糟糕的方式崩溃。治理层的作用在于明确规定，最糟糕的方式——未经授权的静默写入——是不可接受的，即使这意味着偶尔会拒绝一些原本可以接受的写入操作。

预算账簿和终止开关：将成本控制作为一项重要控制措施

代理引入了传统集成大多不会带来的一类风险：自主支出。调用工具的循环可以通过错误或对抗性提示来调用它们，其调用次数远远超出任何人的预期——消耗 API 预算、触发下游费用或淹没客户。因此，成本控制属于治理层面，而不是事后附加为一旦造成损害就会触发的计费警报。

我们采用的机制是在任何支出之前评估预算账簿，并设置了每次运行、每天和滚动 30 天的限额，此外还有一个在执行前检查的终止开关。请注意顺序：预算和终止开关是在支出之前评估的，而不是在支出之后进行核对。超支警报是事后分析；拒绝超支通知的账簿则是一种控制措施。三个时间范围至关重要，因为故障模式的形式各不相同——失控循环会超出单次运行上限，配置错误的计划会超出每日上限，而缓慢蔓延只有在 30 天的时间窗口内才会显现出来。

终止开关在设计中应该单独列出。它是您在不了解情况且需要立即停止活动时可以使用的控制选项。它在执行前进行评估，是一种断路器，而不是清理工具。每个代理程序都应该能够立即回答一个问题：我们如何停止它？如果答案需要通知三个团队并手动撤销密钥，那么您没有终止开关——您只有希望。

审核与编辑：范围明确、时间限定且可观察

无法被观察的治理并非真正的治理，而是意图。最终的治理层使得其上层的一切事后都可验证。代理密钥应限定在实际需要的工具范围内，并设定时间限制，以便凭证的失效范围按计划逐步缩小至零，而不是无限期地存在。一个可以永久执行任何操作的密钥，是事件审查中最常见的遗留问题。

同样，审计跟踪本身也必须尊重其记录的数据。我们采用逐次调用脱敏技术，确保日志能够准确记录事件经过——使用何种工具、在何种身份和租户环境下、以及最终结果——而不会成为控制措施旨在保护的敏感数据的副本。悄悄积累明文客户记录的审计日志并非控制措施，而是一种披着善意外衣的新风险。

这些特性——作用域密钥、时间限制、每次调用时的脱敏处理、统一审计——共同帮助首席信息安全官 (CISO) 回答事件发生后实际会遇到的问题：此凭证可以做什么？可以持续多久？它实际做了什么？以及我们能否在不泄露更多信息的情况下证明其有效性？

将其与持续风险挂钩——并坦诚面对剩余的风险

这一切都不是一次性的设置。NIST 人工智能风险管理框架 (AI RMF 1.0) 明确指出，人工智能风险管理是一个持续的过程，而不是一份填写完毕后就束之高阁的清单。治理界面之所以有价值，正是因为它为持续治理流程提供了一个统一的操作平台：当出现新的风险时，您只需在一个界面中调整授权、预算、风险敞口或审计，而无需在多个集成中疲于奔命。正是这种标准化使得持续治理切实可行，而非仅仅停留在理想阶段。也正因如此，深思熟虑的风险敞口决策才能带来双重收益——一次是在做出决策之时，另一次则是在每次需要重新审视该决策时。

坦诚面对剩余风险，因为董事会也会如此。治理机制可以缩小攻击面，使活动可审计；但它并不能使代理人万无一失。即使是临时注入，也可能试图引导合法授权的代理人进行看似合法的滥用行为。即使故意暴露的工具，在其权限范围内仍可能被滥用。预算限制了成本，但无法限制判断。德勤的《企业人工智能现状》研究反复表明，人工智能的雄心壮志与治理人工智能的运营成熟度之间存在差距——而这些剩余风险恰恰存在于这一差距之中。正确的应对措施不是声称差距已经消除，而是要缩小差距，使其可观察并持续管理。

我们正是基于此理念构建了我们的平台。 SocialHub.AI 通过 HTTP 流式传输协议在 MCP 之上公开语义层工具，可从 Claude、GitHub Copilot 和 Microsoft 365 Copilot 等代理访问。此处描述的控制措施应用于接口，而非分散在各个连接器中：基于租户上下文的三轴授权、故障关闭写入、带有执行前终止开关的按运行/按天/按 30 天计费的预算账本，以及带有每次调用编辑和审计功能的有范围、有时限的代理密钥。这种治理原则与我们之前在忠诚度工作中所使用的原则相同，我们曾帮助 McDonald's China 会员的 GMV 贡献率从大约 5% 提升至 85%——如此规模的成果只有在数据接口本身就值得信赖的情况下才能实现。

如果您正在决定代理如何访问您的记录系统，那么您应该向团队提出的问题不是“使用哪个连接器”，而是“身份、授权、日志记录和成本在哪里确定，以及是在一个地方还是多个地方”。如果您想了解以治理为先的 MCP 界面在实践中是如何运作的，请预约演示，或访问 /platform/ai-frontier 了解更多关于我们方法的信息。