MCP server security checklist

The control gap

A production server needs explicit ownership, authentication, tool classification, least-privilege credentials, authorization, failure behavior, and evidence before broad agent discovery.

DataForSEO reports 60,500 monthly US searches for `mcp server`, $15.69 CPC, and keyword difficulty 40. The head term is broad, so this checklist does not claim every searcher has buying intent. It earns relevance by covering the production security decisions often omitted by basic installation guides and by linking them to a runnable policy boundary.

Before launch, document owner, environment, transport, client authentication, server authentication, credential storage, each tool's side-effect class, canonical resources, validation, tenant isolation, rate limits, timeouts, cancellation, idempotency, default policy, approval owner, logging minimization, failure mode, revocation, backup, and incident response. Test unknown tools, cross-tenant resources, replay, policy outage, and provider failure.

Inventory the server artifact and dependencies as well as its advertised tools. Record source repository, release or image digest, maintainer, update channel, vulnerability handling, and whether tool descriptions or schemas can change independently. Pin production versions and review capability drift before clients discover new actions.

Trace every credential from issuer to downstream provider. Determine whether one credential is shared across users, agents, tools, tenants, or environments; where it is stored; and whether the server can narrow it per call. A policy gateway cannot repair a server that performs every action with one invisible organization administrator token.

Define an incident exercise before onboarding. Revoke a client, disable a tool, rotate the provider secret, stop the policy service, and inspect the evidence that remains. Owners should know which calls fail closed, which read-only continuity exceptions exist, and how to identify actions that began before containment.

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 production MCP server tools and their downstream credentials 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 server security checklist 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-server-production-baseline
match:
  identity_verified: true
  environment: production
  tool: ["mcp.*"]
decision: require_approval
approval:
  reviewers: ["mcp-server-owner"]
  expires_in: 15m

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 production MCP server tools and their downstream credentials 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?