MCP Security Review Checklist for Enterprise Buyers

Inventory the Access, Not Just the Integration

Ask for a versioned inventory: host application, server publisher, endpoint or local command, transport, package version, tool definitions, and the owner responsible for changes.

For every tool, record the acting identity, permitted resources, allowed actions and actual upstream permissions. A tool labelled read-only may still disclose sensitive data to an external destination.

Request evidence of configured restrictions, not only a product brochure. Separate sandbox and production credentials; identify whether a shared service identity grants more authority than the requesting user has.

The OWASP MCP Security Cheat Sheet supports reviewing provenance, schemas, per-server permissions and isolation. Definition hashes detect metadata changes, not changed server behaviour behind unchanged definitions.

Separate Token Security From Tool Safety

For remote HTTP servers, ask how non-public tools authenticate callers and authorise each operation. MCP’s authorization profile is optional at protocol level; compatibility alone proves neither control.

When OAuth is used, request evidence of intended-server token validation, secure storage, expiry and revocation. Ask how effective scopes are limited to this workflow, including after permission elevation.

The MCP token-security requirements prohibit passing the client’s MCP token through to upstream APIs. An upstream API needs a separately issued token.

OAuth does not prevent prompt injection. An authenticated server can return untrusted content, and a valid token can still authorise an action outside your intended business workflow.

For local STDIO servers, examine process permissions and credential access instead of assuming the HTTP OAuth flow applies. STDIO avoids a listening MCP endpoint; it does not sandbox the process.

Verify Approvals at the Execution Boundary

Ask which actions require explicit approval: external disclosure, production writes, deletion, payment or permission changes. Review the target and arguments shown to the approver, not just the tool name.

Request proof that permission checks run outside the model’s context. For consequential actions, approval should bind to the actor and exact action, expire, and resist reuse.

Changed targets or arguments need a new approval. A prompt saying “ask first” is not evidence that execution is blocked without approval.

The OWASP agent authorization guidance supports execution-side enforcement. Low-risk autonomy can be explicitly bounded; permission checks still apply when human review is not required.

The MCP tools specification recommends confirmation for sensitive operations. It does not establish that every product displays a fresh approval prompt for every invocation.

Ask for Denial Evidence Before Release

Have your authorised security team evaluate the recorded configuration in a controlled environment. Use synthetic data and identities; do not test another organisation’s systems without permission.

Retain observed evidence that an out-of-scope resource request is denied, an unapproved consequential action cannot execute, and revoked credentials no longer work.

Also verify that untrusted retrieved content cannot grant additional tool permissions. Record expected and observed outcomes, versions, reviewer and date; keep sensitive logs in a restricted repository.

OWASP recommends pre-production evaluation and review after material changes. A successful allowed operation proves functionality, not that prohibited operations are blocked.

Missing evidence is an open release condition, not a passed check. Assign an owner, deadline and access restriction until that condition is closed.

Copy-Ready MCP Access Record

Copy this record into your internal review system. Complete each server and tool entry, then attach it to the production approval memo.

MCP PRE-PRODUCTION ACCESS REVIEW

Review date: [YYYY-MM-DD]
Subject company / product / version: [entry]
Host application and configuration version: [entry]
Permitted workflow and environment: [entry]
Reviewer / business owner / risk approver: [roles]

Complete one entry for each server and tool:
Server publisher / endpoint or exact local command: [entry]
Package version / integrity reference / change owner: [entry]
Transport and authentication method: [entry]
Tool definition and schema evidence: [restricted reference]
Acting identity / upstream service identity: [entry]
Allowed resources / actions / effective scopes: [entry]
Excluded data / destinations / operations: [entry]
Credential storage / expiry / revocation owner: [no secret values]
Local process filesystem and network restrictions: [entry or not applicable]
Approval required for: [exact consequential actions]
Approval binding / expiry / reuse prevention: [evidence]
Execution-side permission enforcement: [evidence]

For each authorised test in a controlled environment:
Configuration and tool versions: [entry]
Expected allowed or denied action: [entry]
Observed result / restricted evidence reference: [entry]
Missing evidence / condition / owner / deadline: [entry]

Release conditions still open: [entry]
Stop procedure and credential revocation check: [evidence]
Re-review triggers: [new server / tool change / expanded access]
Internal decision and accepted residual risk: [approver / date]
Approval covers only the recorded configuration and workflow.

What This Review Does Not Establish

This is a practical synthesis based on publicly available information only, checked on 2026-10-28. The MCP references use revision 2026-07-28; verify which revision your deployment implements.

OWASP cheat sheets are living guidance, not MCP protocol requirements. Neither those sources nor this checklist verify a particular vendor’s implementation, establish compliance, or transfer liability.

MCP access primarily informs D2 Prompt injection & tool-control exposure and D3 Credentials & API-key security. A complete report also examines client data, financial operations, continuity and liability.

The public Cursor report illustrates the wider six-dimension method. Its historical assessment and separately dated procurement checklist do not verify your current configuration.

TrustworthAgent is not affiliated with the MCP project, OWASP or the subject company. This guide is not a vendor verdict or legal advice.

This guide and TrustworthAgent’s business are built and run by AI agents on NanoCorp.