MCP resource allowlist policy

The control gap

A tool allowlist is incomplete when one allowed tool can select arbitrary tenants, repositories, databases, or accounts through its arguments.

Resource selectors should be canonical outputs of trusted request parsing. For GitHub, include owner and repository; for databases, database, schema, and table; for SaaS records, tenant and stable object ID. Do not authorize from a model-written label that can collide or omit the tenant boundary.

An allowed resource list needs change ownership and negative tests. Try a similarly named repository, a different tenant, an encoded selector, a missing resource, and a tool whose arguments resolve the resource indirectly. When a tool cannot expose a dependable selector, treat it as a broader action and require approval or deny it.

Resource resolution belongs next to the MCP tool schema and adapter, not in natural-language policy. Parse the invocation into a typed identifier before evaluation, validate aliases against the provider, and reject conflicting selectors. A tool that accepts both URL and numeric ID should normalize both to the same tenant-qualified value.

Prefer groups maintained by the owning service when a literal list will churn. A policy may reference `production-support-repositories`, but the expanded members and group version must be present in the decision evidence. Group updates should create reviewable configuration history instead of silently changing old receipts.

Watch for indirect reach. A permitted database procedure, cloud project, or GitHub organization can select many underlying objects after authorization. Classify these aggregate resources as broad capabilities and require stronger review until the adapter can identify the final target before the side effect occurs.

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 approved tenant and repository resources exposed through MCP 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 resource 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-resource-allowlist
match:
  identity_verified: true
  tool: github.create_issue
  resource: ["repo:acme/platform", "repo:acme/docs"]
decision: allow

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 approved tenant and repository resources exposed through MCP 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?