话题 / MCP连接器审批

观点转述

MCP连接器要求供应商提交工具规格,并对每项工具单独开展安全评审

对于MCP连接器(即由供应商运营服务器的情形),Harvey要求供应商提交其完整工具列表、能力范围、托管与认证详情、数据处理所在区域以及测试凭据;随后,安全团队对每项工具逐一评审,决定批准或拒绝,并为其分配风险等级,相关决策将记录于随代码发布的注册表中。

观点背后的信息

译文仅辅助阅读;核查观点请以原始摘录为准。

我们如何构建Harvey的连接器库

MCP 成员的服务器由供应商运营,因此评审需针对他人运行的系统,并额外增设一道准入审查环节。供应商须提交完整工具列表及能力范围、托管与认证详情、数据处理所在地域,以及测试凭据;安全团队将逐项评审每项工具,逐一决定是否批准,并为其分配风险等级。

原始摘录
An MCP member's server is operated by the vendor, so the review has to judge a system someone else runs, and it gets an extra layer of admission. The vendor submits its full tool list and capability scope, hosting and auth details, data-processing regions, and test credentials, and the security team reviews the tools one by one, deciding for each whether it is approved and assigning its risk level.
上下文

原生成员(native member)是我们围绕供应商 API 编写的封装层,同样需经过相同的安全评审:安全团队审批的具体内容包括我们调用哪些供应商 API、请求哪些权限范围。由此,审批构成工程集成启动前的一道硬性关卡。相关审批决策将录入随代码发布的注册表中:该注册表包含结构化的 URL 匹配器、供应商完整公开的工具列表、允许调用的子集,以及为每一项工具人工撰写的关于其风险与能力的注释。

原始上下文

A native member is a wrapper we wrote around the vendor's API, and it goes through the same security review: which of the vendor's APIs we call and which scopes we request are what the security team signs off on. This way, approval is a hard gate before engineering integration begins. Those decisions land in a registry that ships with the code: a structured URL matcher, the vendor's full advertised tool list, the subset that may be invoked, and a hand-written risk and capability annotation for each.