Harvey Builds MCP Policy Engine to Control How AI Agents Use Partner Tools

Why runtime controls are needed

Legal teams work across research platforms, document management systems and communication tools. According to Harvey, connecting its agents to those systems gives them more context, but it also creates a security challenge: tools can change after initial review, return malicious instructions, or be exploited in ways that expose sensitive information.

Harvey built the engine while rebuilding its Connector Library. The company says prompt injection remains an open problem in AI security, so it uses several architectural controls to reduce the likelihood and impact of misuse. It names Sondera, Progent, ETDI and CaMeL as research that inspired the design, which explores enforcing policies outside the model, limiting tool privileges and controlling information flow.

Harvey lists four considerations behind its approach:

• Server power: MCP servers can, where supported, ask clients to invoke models or collect information from users, so limits on what servers can request are needed.
• Compounding risk: Harvey points to the "lethal trifecta" of access to private data, exposure to untrusted content and external communication, which can lead to data exfiltration through prompt injection.
• Implementation dependence: Harvey cites the NSA, which describes MCP's security posture as "uneven and highly dependent on implementation discipline rather than protocol guarantees."
• Evolving protocol: new specifications can close gaps while adding capabilities with novel risks.

The engine targets two persistent threats. In tool poisoning, malicious instructions embedded in a tool's definition redirect the agent. In a rug-pull attack, a server introduces malicious changes after it has been approved.

Review before connection and analysis of tool arguments

Harvey says it starts with an in-depth review of each partner server and its tools, examining authentication, capabilities, permissions and data handling. It enforces MCP security best practices and constrains OAuth scopes and tool access according to least privilege where possible. New tools and protocol features are not enabled by default just because a server offers them; additions are reviewed too.

The company argues that a read or write label does not describe everything a tool can do. A read-only search tool could still disclose confidential information if that information is placed in a query sent to an external service. Harvey therefore assesses two properties of a tool's arguments:

• Capacity: how much information the argument can carry. An unrestricted text field carries more than a field limited to a small set of values, and repeated calls can increase capacity.
• Authority: what the argument controls, such as content, a selected document or a recipient.

These properties let Harvey treat prompt injection as an information flow control problem. The company also built an internal MCP security analysis tool that runs at integration time. It examines authentication configuration, exposed capabilities and JSON schemas, and identifies gaps between the guarantees Harvey wants, what a server promises in its schema and documentation, and what it actually enforces.

Enforcement outside the model

Harvey says mitigations such as safety training, content marking and classifiers can reduce risk but are bypassable and do not meet its security bar in isolation. It therefore relies primarily on architectural mitigations. Enforcement sits in the orchestration layer, outside the model, so policies can constrain proposed actions even when the model follows a malicious instruction.

Three principles guide the approach, drawing on "Systems Security Foundations for Agentic Computing":

• Least Privilege: restrict the capabilities available to an agent and the conditions under which it can use them.
• Complete Mediation: check each partner MCP tool call before execution. Approval to connect a server does not authorize every later action.
• Secure Information Flow: use workflow context to restrict combinations of capabilities that could expose private information or let untrusted content drive consequential actions.

Tool Pinner and what comes next

Because MCP does not require versioning of individual tool definitions, a tool can change after approval. Harvey's "Tool Pinner" records approved tools, including model-facing descriptions and input schemas. During discovery it compares each connector's advertised catalog with that baseline and flags additions, removals and changes for Security review.

Harvey acknowledges a trade-off. Pinning on first use and rejecting all updates would guard against rug-pull attacks, but connector catalogs change often, and the pinner currently generates a substantial volume of alerts. The company is developing fine-grained pinning and semantic edit classification, which breaks changes into components and assesses their policy-relevant risk. Together with contextual information and strategic human-in-the-loop review, this would inform which version of a tool is delivered and how the engine handles it. Harvey is also working on examining cumulative changes to catch salami-slicing attacks, where a series of small edits adds up to a consequential change.

The post also says a tool call can carry different risks depending on what happened earlier in the workflow, such as after an agent has accessed private data. The source text provided ends while introducing this context-based evaluation.

What it means for customers

For firms using Harvey Agents with connected systems, the post indicates that approval of a partner server is only the first step: each tool call is checked before it runs, and changes to approved tools are flagged for review. Harvey is open that parts of the system, including alert prioritization, are still being improved.