Harvey's MCP policy engine is the first serious template for governing agent tools

Harvey published an engineering post on October 7 about its MCP Policy Engine, and it is the most detailed public description yet of how a serious company governs agent tool use at runtime. Harvey sells AI for legal workflows to more than 3,000 customers in 70-plus countries, per the company, which makes the security posture of its agent connectors a customer question, not just an engineering one.

The post's framing is worth stating up front because it is honest in a way vendor security writing usually is not. Prompt injection remains an open problem in AI security. The approach, therefore, is architectural: multiple controls that reduce the likelihood and impact of misuse rather than a claim of solving it. The design draws on published research: Sondera, Progent, ETDI, and CaMeL, work on enforcing policies outside the model, limiting tool privileges, and controlling information flow. Everything below is Harvey's own description of its own system. Nothing was independently tested.

The threat model starts from a real observation. MCP expands what agents can do through a common standard for discovering tools, accessing data, and acting across services, and it expands the attack surface with it: externally supplied tool definitions, content, and interaction requests enter the agent's workflow, and supply chain risk rises. Harvey names the NSA's assessment of MCP's security posture as "uneven and highly dependent on implementation discipline rather than protocol guarantees," then builds from two compounding facts. First, MCP is bidirectional: servers can, where supported, ask clients to invoke models or collect information from users, which needs explicit limits. Second, risk compounds across tools. Harvey uses the "lethal trifecta" framing: private data access plus untrusted content exposure plus external communication equals an exfiltration path. Even a trusted tool can return attacker-controlled content that redirects later calls to fetch and disclose sensitive information.

From that, the engine targets two threats that are hard to mitigate with existing tools. Tool poisoning: malicious instructions embedded in a tool's definition that redirect the agent. Rug-pull: a server that introduces malicious changes after it has been approved, exploiting trust in a reviewed tool. Both can weaponize the lethal trifecta.

The controls fall into four layers.

Review before connection. Harvey reviews each partner MCP server and its tools with the partner: authentication, capabilities, permissions, data handling, constrained OAuth scopes, least-privilege tool access. New tools and protocol features are not enabled by default just because a server offers them. Harvey also runs an internal MCP security analysis tool at integration time that examines authentication config, exposed capabilities, and JSON schemas to find gaps between the guarantees Harvey wants, what the server promises, and what it actually enforces. One sharp detail: Harvey assesses tool arguments on two properties, capacity (how much information an argument can carry) and authority (what the argument controls, a document, a recipient, the whole flow), treating prompt injection as an information flow problem. A read-only search tool can still disclose confidential information if that information is placed in a query sent to an external service.

Pinning against rug-pulls. MCP does not require versioning of individual tool definitions, so a tool can change after approval. The Tool Pinner records approved tools, including their model-facing descriptions and input schemas, and compares each connector's advertised catalog against the baseline at discovery, flagging additions, removals, and changes for security review. The post is candid about the trade-off: pinning on first use and rejecting all updates would be safer, but connector catalogs change constantly, and the pinner generates a substantial volume of alerts. The planned answer is fine-grained pinning with semantic edit classification, breaking changes into components and assessing their policy-relevant risk, plus strategic human-in-the-loop and defenses against salami-slicing attacks, where small edits accumulate into a consequential change.

Trajectory-based enforcement outside the model. Policies are written in Rego and run on Regorus, with enforcement in the orchestration layer rather than the model: policies constrain proposed actions even when the model follows a malicious instruction. The interpreter sees tool identifiers, Harvey's own annotations, and call history. It does not inspect prompt content or customer data. A tool call is evaluated in context, because a call that can transmit information externally means something different after the agent has touched private data or untrusted content. Each proposed call is permitted, denied, or paused for explicit user approval. If the engine cannot complete its checks, it denies. Workspace settings can add restrictions but cannot override a denial. The policies also watch agent-to-agent interactions, where one agent's response triggers another delegation in a cycle, and aim to interrupt those cycles for human review.

Sanitizing the input. The Sanitizer removes selected hidden characters and control sequences from tool results before they enter the model's context, and flags lookalike characters from different writing systems, scoped to preserve legitimate multilingual content. The post says the honest thing: text can still contain malicious instructions, which is why the architectural controls constrain the consequential actions the agent can take in response to untrusted content.

What remains unknown: performance data, false-positive rates, deployment scale, and any third-party assessment. Harvey is candid about open work: automated policy creation, program analysis tied to capability-based constraints, and controls that are easier to reason about, verify, and test. The efficacy claims are the company's.

The operator move: you do not need Harvey to use this. The post is a template. If your agents touch MCP servers, the checklist is: review each server before connection, pin tool definitions and review changes, mediate every call outside the model, evaluate calls in trajectory context, deny by default on indecision, and sanitize tool results. Demand the same from vendors. It pairs with Cisco Talos's warning this week that the first wave of agentic attacks is loud and the quiet ones are next: the tool surface you provision is the surface the swarm walks, and the ledger of what your tools can do is now a security control.