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

Harvey Blog ·

本文为Harvey连接器库作者撰写的技术概述,涵盖该库的架构设计、连接器的安全评审流程、MCP连接器的审批要求,以及用于处理各服务提供商技术实现差异的适配器层设计。 阅读 4 条观点,查看支持证据与原始来源。

理解这篇

4 个要点

综合解读

  1. 连接器库强制执行权限并处理服务商差异

    构建连接器库涉及将外部工具提供给AI智能体使用,同时强制执行用户权限,并适应不同服务提供商之间的技术差异。

    支持这项说法 1

    构建连接器库意味着让外部工具可供智能体使用,同时实施权限控制,并适配不同供应商的差异。

    Chenghao Wang · 段落 1

    原始摘录
    Building the Connector Library meant making external tools available to agents while enforcing permissions and accounting for differences between providers.
    回到原文语境 →
  2. 安全评审在发布前进行,覆盖核心威胁场景

    在连接器发布前,Harvey的安全团队会针对一系列威胁场景开展评审,包括提示注入、写入能力滥用、凭据泄露、跨租户数据泄露及供应链风险;运行时,每次工具调用仍须通过权限与策略检查。

    支持这项说法 1

    连接器安全始于工具面向用户发布之前,并持续到智能体调用该工具时。发布前,我们的安全团队评估提示注入、写入能力被误用、凭据泄露、跨租户数据泄露及供应链风险等威胁;运行时,每次调用仍需通过相应的权限与策略检查。

    Chenghao Wang · 段落 12

    原始摘录
    Connector security starts before a tool reaches users and continues when the agent calls it. Before launch, our security team reviews threats such as prompt injection, misuse of write capabilities, credential compromise, cross-tenant leakage, and supply-chain risk. At runtime, each call must still pass the applicable permission and policy checks.
    回到原文语境 →
  3. MCP连接器要求供应商提交工具规格,并对每项工具单独开展安全评审

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

    支持这项说法 1

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

    Chenghao Wang · 段落 14

    原始摘录
    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.

    回到原文语境 →
  4. 适配器遵循服务器的授权行为

    在授权方面,Harvey的适配器层遵循服务器所暴露的行为:当服务器未发送挑战时,适配器可直接发现元数据;当返回状态码为200或201且附带有效令牌时,适配器予以接受;同时,适配器会请求服务器所声明的权限范围(scopes)。

    支持这项说法 1

    我们在适配器层处理这些差异。在授权方面,我们遵循服务器实际暴露的行为:若服务器未发送质询,我们可直接发现元数据;若响应为 200 或 201,则接受其中返回的有效令牌;并按服务器声明的作用域发起请求。

    Chenghao Wang · 段落 26

    原始摘录
    We handle these differences in an adapter layer. For authorization, we follow the behavior a server actually exposes: we can discover metadata directly when it does not send a challenge, accept valid tokens returned with either 200 or 201, and request the scopes it advertises.
    回到原文语境 →

关键段落4

带明确归属与语境的原文片段。打开原始文本核查出处。

MCP连接器审批

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

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.

连接器架构

连接器库强制执行权限并处理服务商差异

构建连接器库意味着让外部工具可供智能体使用,同时实施权限控制,并适配不同供应商的差异。

原始摘录
Building the Connector Library meant making external tools available to agents while enforcing permissions and accounting for differences between providers.
安全评审流程

安全评审在发布前进行,覆盖核心威胁场景

连接器安全始于工具面向用户发布之前,并持续到智能体调用该工具时。发布前,我们的安全团队评估提示注入、写入能力被误用、凭据泄露、跨租户数据泄露及供应链风险等威胁;运行时,每次调用仍需通过相应的权限与策略检查。

原始摘录
Connector security starts before a tool reaches users and continues when the agent calls it. Before launch, our security team reviews threats such as prompt injection, misuse of write capabilities, credential compromise, cross-tenant leakage, and supply-chain risk. At runtime, each call must still pass the applicable permission and policy checks.
适配器层设计

适配器遵循服务器的授权行为

我们在适配器层处理这些差异。在授权方面,我们遵循服务器实际暴露的行为:若服务器未发送质询,我们可直接发现元数据;若响应为 200 或 201,则接受其中返回的有效令牌;并按服务器声明的作用域发起请求。

原始摘录
We handle these differences in an adapter layer. For authorization, we follow the behavior a server actually exposes: we can discover metadata directly when it does not send a challenge, accept valid tokens returned with either 200 or 201, and request the scopes it advertises.

来源与研究方法

这些观点均关联原始来源。转述已明确标注,不作为逐字原话展示。

打开转录或来源材料 (在新标签页中打开)报告问题

继续了解这些人物的观点