Harvey Details How Its Connector Library Keeps Agent Tool Calls Within Permissions

From a catalog tile to tools in the agent's hands

In Harvey's design, an admin enables a connector, a user connects once, and the services the firm already relies on become usable inside Harvey. A connector is a vendor-level object: a tile in the catalog, with one permission and one admin toggle. It is backed by one or more members, each providing part of the integration. A member is either a native integration or an MCP connector, meaning a server the vendor operates that Harvey calls over the Model Context Protocol.

Everything that defines a connector sits in one registry in code, including its capabilities, its permission and a routing note written for the agent. Harvey says this makes onboarding cheap, and that new connectors have entered the catalog one after another since Early Access opened.

When a user works with the agent, the client sends the selected connector and tools with the request. The backend resolves that selection once per turn into native or MCP members and their tool configurations, and rejects unknown connector types and tool keys. Allowed calls go out with the connection's own credential. For sources holding personal data, that is always the asking user's own grant, so the source system returns only what that user may see under its own access controls. Documents retrieved by native members appear with inline citations, while MCP output enters the model context as plain text.

Security review and runtime policy for MCP tools

Harvey's security team reviews each connector before launch against threats including prompt injection, abuse of write capabilities, credential compromise, cross-tenant leakage and supply-chain risk. Native members are wrappers Harvey wrote around a vendor's API, so the review covers which APIs are called and which scopes are requested.

MCP members get an extra admission layer because the vendor runs the server. The vendor submits its full tool list and capability scope, hosting and auth details, data-processing regions and test credentials. The security team then reviews the tools one by one, approving each and assigning a risk level. According to Harvey, this approval is a hard gate before engineering integration begins. The decisions are stored in a registry shipped with the code.

At runtime, a purpose-built MCP policy engine checks each call. It confirms the tool is still on the approved list, that the risk and capability annotation from review is present (a missing one means outright refusal), and that workspace and user settings allow the call. Rules are written in Rego, Open Policy Agent's policy language, with the interpreter embedded in-process. The input is deliberately data-blind: only the tool's identity, risk level, capability flags and the names of prior MCP calls in the run reach the rules, never user arguments or free text. A rule-evaluation error fails closed.

• Harvey pins a fingerprint of each approved tool's description and input schema at review time and compares it on every discovery. A change or disappearance alerts the team.
• Tool results pass through sanitization, including detection of mixed-script confusable characters.
• Tool arguments, result contents, server URLs and user identifiers never appear in health events and metrics.

Customers get controls too. A workspace admin can disable or enable a connector, a member or a single MCP tool, and users can tighten settings further. The tools the model sees are those advertised by the vendor, reviewed by Harvey, allowed by workspace and user settings, and explicitly selected for the request when a selection is present.

Absorbing vendor differences in an adapter layer

Harvey says vendors behave differently in ways that cause concrete failures: a valid token discarded as invalid, a user asked to re-authorize for no visible reason, or a tool schema the vendor declares legal being rejected by the model.

The MCP authorization spec is still evolving, and servers support different versions. The expected flow involves protected resource metadata discovery (RFC 9728), authorization server metadata (RFC 8414), dynamic client registration (RFC 7591), OAuth 2.1 with PKCE and resource binding (RFC 8707). In production, Harvey reports, some servers never send the 401 challenge that should start discovery, one token endpoint returns a valid token with 201 Created, and servers read the same scope declaration differently.

Client registration has three paths. The 2026-07-28 spec revision makes CIMD (Client ID Metadata Documents) the recommended path and deprecates Dynamic Client Registration while keeping it for backwards compatibility. Some servers Harvey integrates support only dynamic registration, and others work only with a client Harvey pre-registers.

Token handling is another pressure point. Several providers issue single-use refresh tokens, while frontend prechecks, scheduled syncs, export jobs and background renewal can all want the same user's token at once. The layer serves roughly 13 million credential reads a day.

Harvey's adapter follows the behavior a server actually exposes. It can discover metadata directly when no challenge is sent, accept valid tokens returned with either 200 or 201, and request the scopes a server advertises. Conditional write-backs handle competing token updates without locks. At discovery, tool schemas are normalized before registration with the agent, and unrecognized behavior triggers an alert so the team can update the integration.

What it means for firms using Harvey

For firms, the design means agents can work across the tools they already use without widening who can see what. Calls run under the asking user's own grant, source-system permissions still apply, and admins can switch off connectors, members or individual MCP tools. Vendor-specific authorization and schema quirks are handled inside the adapter layer, so the agent is not exposed to that complexity, according to Harvey.