nafyi.

How We Built Harvey’s Connector Library

Harvey Blog ·

A technical overview by the author of Harvey’s Connector Library architecture, its security review process for connectors, MCP connector approval requirements, and the adapter layer’s design for handling vendor-specific implementation differences. Read 4 viewpoints with supporting evidence and source links.

Chenghao Wang
Read key viewpointsOpen Publisher (opens in a new tab)

Understand this piece

4 key points

Synthesis

  1. Connector Library enforces permissions and handles provider differences

    Building the Connector Library involved making external tools available to AI agents while enforcing user permissions and accommodating technical differences across service providers.

    Supporting evidence 1

    Original excerpt

    Building the Connector Library meant making external tools available to agents while enforcing permissions and accounting for differences between providers.

    Chenghao Wang · Paragraph 1

    How We Built Harvey’s Connector Library · Oct 1, 2026

    Read in source context →

    Continue exploring

    connector architecture →

  2. Security review precedes launch and covers core threat scenarios

    Before a connector launches, Harvey's security team reviews it against threat scenarios including prompt injection, misuse of write capabilities, credential compromise, cross-tenant leakage, and supply-chain risk; at runtime, each tool call must still pass permission and policy checks.

    Supporting evidence 1

    Original excerpt

    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.

    Chenghao Wang · Paragraph 12

    How We Built Harvey’s Connector Library · Oct 1, 2026

    Read in source context →

    Continue exploring

    security review process →

  3. MCP connectors require vendor-submitted tool specs and per-tool security review

    For MCP connectors—where the vendor operates the server—Harvey requires the vendor to submit its full tool list, capability scope, hosting and auth details, data-processing regions, and test credentials; the security team then reviews each tool individually, approves or rejects it, assigns a risk level, and records decisions in a code-shipped registry.

    Supporting evidence 1

    Original excerpt

    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.

    Chenghao Wang · Paragraph 14

    How We Built Harvey’s Connector Library · Oct 1, 2026

    Context

    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.

    Read in source context →

    Continue exploring

    MCP connector approval →

  4. Adapter follows server authorization behavior

    For authorization, Harvey’s adapter layer follows the behavior a server exposes: it can discover metadata directly when no challenge is sent, accept valid tokens returned with either 200 or 201, and request the scopes the server advertises.

    Supporting evidence 1

    Original excerpt

    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.

    Chenghao Wang · Paragraph 26

    How We Built Harvey’s Connector Library · Oct 1, 2026

    Read in source context →

    Continue exploring

    adapter layer design →

Key passages4

Attributed passages with the context to verify them. Open the original text to check the source.

Paragraph 14 (opens in a new tab)
MCP connector approval

MCP connectors require vendor-submitted tool specs and per-tool security review

Original excerpt

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.
Chenghao Wang·
Context

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.

Paragraph 1 (opens in a new tab)
connector architecture

Connector Library enforces permissions and handles provider differences

Original excerpt

Building the Connector Library meant making external tools available to agents while enforcing permissions and accounting for differences between providers.
Chenghao Wang·
Paragraph 12 (opens in a new tab)
security review process

Security review precedes launch and covers core threat scenarios

Original excerpt

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.
Chenghao Wang·
Paragraph 26 (opens in a new tab)
adapter layer design

Adapter follows server authorization behavior

Original excerpt

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.
Chenghao Wang·

Source & methodology

These viewpoints are linked to their original sources. Paraphrases are labeled and are not verbatim quotes.

Open transcript or source material (opens in a new tab)Report an issue

Explore these viewpoints by person