Chenghao Wang

connector architectureOct 1, 2026

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

Chenghao Wang·Oct 1, 2026

Open original · Paragraph 1 Original text source

Original excerpt

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

security review process

security review processOct 1, 2026

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

Chenghao Wang·Oct 1, 2026

Open original · Paragraph 12 Original text source

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.

MCP connector approval

MCP connector approvalOct 1, 2026

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

Chenghao Wang·Oct 1, 2026

Open original · Paragraph 14 Original text source

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.

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.

adapter layer design

adapter layer designOct 1, 2026

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

Chenghao Wang·Oct 1, 2026

Open original · Paragraph 26 Original text source

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.