MCP tool allowlist policy

The control gap

Tool discovery should not automatically become execution authority for every capability a server publishes.

Build the allowlist from stable server identity and tool names, not from whichever descriptions a server advertises at runtime. Discovery metadata can change, and two servers may publish tools with the same friendly name but very different authority. Include server owner, environment, schema version, and credential boundary in the inventory.

An unknown tool should fail closed until an owner classifies its side effects and resource selectors. Reads are not automatically harmless: search and export tools can expose broad data. Review changes to tool schemas as policy changes, and keep discovery events so teams can see when a server's exposed capability surface expands.

Store a digest of the reviewed input schema with each allowlist entry. Adding an optional destination, raw-query field, or administrative flag can expand authority without changing the tool name. A schema mismatch should return a clear review state, not silently continue under the previous classification.

Scope the list to server, tenant, environment, and client class. `create_issue` on an internal engineering server is not equivalent to a same-named tool exposed by an unknown public server. When traffic crosses a gateway, preserve the authenticated server identity so a client cannot redirect an allowed name elsewhere.

Test omitted namespace, duplicate names, case changes, Unicode confusables, newly advertised versions, removed required fields, and an unclassified server. Evidence should state which inventory version and schema digest matched, making capability drift visible before it becomes an unexplained production allow.

What good looks like

A narrow policy that can be tested in shadow mode, reviewed with owners, and promoted to enforcement with measurable impact.

• Match the concrete action "invoke_tool" rather than every operation exposed by the tool.
• Scope the target to an approved set of MCP server tools and the production environment.
• Require a request-bound approval that expires and cannot be reused.
• Record denied attempts as well as approved executions.

A production workflow

1. Copy the template and replace example identities and resource selectors.
2. Run it in shadow mode against representative requests.
3. Review false positives, missing resource attributes, and approver routing.
4. Enable enforcement for one agent and expand only after reviewing the decision log.

A policy you can test

MCP tool allowlist policy is a concrete starting point, not a claim that one generic rule fits every environment. Replace example identities and selectors, validate the request shape, and begin in shadow mode.

name: mcp-tool-allowlist
match:
  protocol: mcp
  tool: { not_in: ["search_docs", "read_ticket", "draft_reply"] }
decision: deny
reason: tool_not_approved_for_agent

Endram keeps the policy version with every decision. A later change creates new evidence instead of rewriting why an earlier request was permitted.

Evidence to require

• Every attempted invoke_tool, including denied requests.
• The exact an approved set of MCP server tools selector evaluated by policy.
• The requesting agent, delegated user, reviewer, and timestamps.
• Policy version, matched rule, decision reason, and execution result.

Buyer checklist

• Does the selector cover only the intended production resources?
• Who owns the approval queue outside business hours?
• What is the acceptable approval expiry?
• Which emergency identity may bypass the rule, and how is that use audited?