MCP security best practices for customer security reviews
Review MCP servers before production rollout, customer security questionnaires, or AI agent governance reviews. Score identity, tool permissions, STDIO isolation, secrets, prompt injection, architecture, and registry risk.
MCP review snapshot18 point score
IdentityExplicit auth, scoped tokens, revocation path
Tool accessLeast privilege, approvals, denied actions
RuntimeSTDIO isolation, sandboxing, config review
EvidenceLogs, owner approval, package provenance
What this checklist produces
Use it as a practical review artifact before customer questionnaires or production agent rollout.
Why this belongs in security reviews
MCP is not a security questionnaire tool, but it is becoming part of the same buyer trust conversation.
Customer AI reviews
Enterprise customers increasingly ask how vendors govern AI agents, tool calls, data access, and audit trails.
Agent-to-tool access
MCP connects agents to useful tools, which means tool permissions and execution boundaries need review.
Evidence reuse
A completed MCP security checklist can become a reusable answer-library artifact for future questionnaires.
Vendor comparison
Security teams may need to compare MCP scanners, gateways, identity controls, and agent governance vendors.
MCP search intent map
Use the page differently depending on what the customer or internal reviewer is really asking.
MCP checklist output
Use the checklist as a lightweight tool that produces score, evidence, answer-library content, and remediation work.
Readiness score
A simple 0 to 18 score that helps decide whether the MCP setup is blocked, reviewable, or production-candidate.
Evidence fields
Owner, transport mode, tool permissions, identity source, token scope, approval logs, and monitoring location.
Questionnaire answers
Reusable customer-facing answers for AI agent governance, MCP server controls, prompt injection, and audit trails.
Remediation backlog
A short fix list for authentication, STDIO isolation, secrets, tool poisoning, registry provenance, and logging gaps.
Production MCP security checklist
Use this as a first-pass triage before deeper AppSec, GRC, or platform engineering review.
| Area | Check | Risk if missing | Fix window |
|---|---|---|---|
| Inventory | List every MCP server, client, config file, transport mode, owner, and environment. | Unknown agent tooling becomes an unmanaged security review surface. | Today |
| Authentication | Require explicit authentication for remote MCP access and disable anonymous endpoints. | Unauthenticated access lets external users call tools or inspect metadata. | Today |
| Authorization | Map each tool to least-privilege scopes, allowed users, data boundaries, and approval rules. | A useful tool can become an over-scoped action surface for agents. | Today |
| STDIO isolation | Treat STDIO configs as command execution surfaces and isolate launched processes from the host OS. | Command execution and config manipulation can survive product-level patches. | Today |
| Secrets | Keep API keys and tokens out of tool descriptions, prompts, logs, config repos, and agent memory. | Agents can leak or overuse credentials that were never meant to be exposed to tool calls. | This week |
| Prompt injection | Assume tool output and retrieved content may contain malicious instructions. | External content can steer the agent toward unsafe calls or data exfiltration. | This week |
| Tool poisoning | Review tool names, descriptions, metadata, and schema changes before they reach production agents. | A poisoned tool description can change what the agent believes the tool should do. | This week |
| Registry supply chain | Install MCP servers from verified sources, pin versions, and review package provenance. | Third-party MCP packages can become a software supply-chain entry point. | This week |
| Monitoring | Log tool calls, denied actions, config changes, token use, and unusual data access patterns. | Without audit trails, teams cannot answer customer or incident-response questions. | Ongoing |
Simple scoring model
Give each checklist item 0, 1, or 2 points. The goal is fast triage, not certification.
0-7: High risk
Do not use this MCP setup for production customer data.
8-13: Review needed
Limit access, fix identity and isolation gaps, then retest.
14-18: Production candidate
Controls are mostly in place. Keep monitoring drift and tool changes.
MCP security architecture
Use this control map before production rollout, enterprise review, or customer AI security questionnaires.
Common MCP security risks and issues
These are the risks most likely to turn into customer review questions, internal exceptions, or audit follow-ups.
When to use an MCP security scanner or gateway
Scanners and gateways help, but they do not replace ownership, approval, and evidence records.
Copyable MCP security review questions
Use these directly in an AI vendor security questionnaire, GRC ticket, or answer-library row.
| Area | Question to ask |
|---|---|
| Inventory | Can you provide an inventory of all MCP clients, servers, transports, owners, environments, and tools that can touch customer data? |
| Authentication and authorization | How do MCP clients and servers authenticate users or workloads, validate tokens, enforce least privilege, and revoke access? |
| Tool approval | Which tool calls require human approval before data export, write operations, admin changes, or external sharing? |
| Tool poisoning | How do you review tool names, descriptions, schemas, and server updates so hidden instructions cannot steer the agent? |
| Prompt injection | How do you treat retrieved content and tool output as untrusted before allowing sensitive follow-up tool calls? |
| Runtime isolation | How are STDIO-launched processes, local file access, network access, and secrets isolated from the host environment? |
| Audit logs | What logs exist for tool calls, denied actions, policy decisions, token use, configuration changes, and incident response? |
| Supply chain | How do you approve MCP packages, pin versions, review provenance, and detect shadow or unapproved MCP servers? |
MCP security questionnaire answer pack
Use these answer patterns as starter rows in an answer library. Replace the evidence column with your actual records before sending to customers.
| Customer question | Reusable answer pattern | Evidence to attach |
|---|---|---|
| Do you use MCP servers or agent tools that can access customer data? | We maintain an inventory of MCP clients, servers, tools, owners, environments, and data boundaries. Production access is reviewed before rollout and updated when tools or scopes change. | MCP inventory, owner list, data classification, last review date |
| How do you control MCP tool permissions? | MCP tools are mapped to least-privilege scopes, approved users or workloads, allowed environments, and high-impact action rules before customer data access is permitted. | Tool permission matrix, approval policy, denied-action log |
| How do you prevent prompt injection and tool poisoning? | Retrieved content and tool output are treated as untrusted. Tool names, descriptions, schemas, package sources, and version changes are reviewed before production agent exposure. | Prompt injection policy, package provenance, schema review, rollback plan |
| How do you handle secrets and tokens used by MCP tools? | Secrets are kept out of prompts, tool descriptions, local config, logs, and agent-visible context. Tokens are scoped, rotated, and revocable through documented procedures. | Secrets manager policy, token scope sheet, revocation runbook |
| What MCP audit logs can you provide? | We log tool calls, denied actions, policy decisions, config changes, token use, and unusual data access patterns so customer review and incident response can inspect agent activity. | SIEM destination, event schema, retention policy, sample log |
Evidence and source trail
These sources explain why MCP security moved from niche protocol detail to practical review topic.
NSA MCP security design considerations
External sourceNSA's May 2026 guidance frames MCP security as an AI-driven automation design concern covering access control, token lifecycle, approval, and context-sharing risks.
OWASP MCP Tool Poisoning
External sourceOWASP describes MCP tool poisoning as an indirect prompt injection risk where tool metadata can steer an agent toward unsafe behavior.
MCP security best practices
External sourceThe official MCP guidance covers consent, authorization, token passthrough risk, confused deputy concerns, and session hijacking considerations.
Docker MCP Gateway documentation
External sourceDocker's MCP Gateway docs describe a gateway running MCP servers in containers, injecting credentials, and applying security restrictions before forwarding requests.
Traefik MCP gateway best practices
External sourceTraefik's MCP gateway best practices highlight upstream controls like authN/authZ before prompts reach the LLM, PII filtering/redaction, jailbreak detection, and observability for audit trails.
MCP STDIO execution risk
External sourceVentureBeat reported on OX Security research around MCP STDIO execution behavior and exposed server risk.
MCP Security checklist
External sourceThe MCP Security project tracks hardening categories including provenance, runtime isolation, secrets, logging, and policy controls.
Agent identity and NHI
External sourceIBM Think coverage highlights why agentic systems create new identity, token, and non-human identity questions.
Agent skills supply chain
External sourceTechRadar covered agent skills as an enterprise supply-chain governance problem.
MCP security FAQ
Short answers for teams adding MCP review questions to security questionnaires.
What is MCP security?
MCP security is the set of controls used to safely connect AI agents to tools, data sources, local processes, and remote services through the Model Context Protocol.
Why does MCP security matter for security questionnaires?
Customers may ask how AI agents access data, execute tools, store credentials, log actions, and prevent prompt injection. MCP deployments can become part of that review surface.
Is a checklist enough to secure MCP servers?
No. A checklist helps triage gaps, but teams still need implementation controls such as authentication, least privilege, sandboxing, secret management, monitoring, and change review.
What is MCP security architecture?
MCP security architecture is the control map around clients, servers, identity, gateways, tool registries, secrets, logs, and human approval paths used to make agent tool access reviewable.
What MCP security risks should teams document?
Teams should document token theft, prompt injection, tool poisoning, remote code execution, secret leakage, over-scoped tools, supply-chain risk, and missing audit logs.
What are the most important MCP security considerations for customer reviews?
The most important considerations are identity, least-privilege tool access, token handling, STDIO isolation, prompt injection controls, tool poisoning review, package provenance, audit logs, and owner approval.
How should MCP OAuth scopes be documented?
Document each integration, minimum scopes, credential type, token storage location, revocation path, approval owner, and last review date. Use the MCP gateway checklist when OAuth and token passthrough are central to the architecture.
Should teams build an MCP scanner first?
Not always. For early validation, a scored checklist is cheaper and can reveal which risks buyers care about before investing in a scanner.
Need a shortlist for your workflow?
Send the formats you receive, your current answer-library setup, and whether you need portal support. We will use those signals to prioritize the next comparison updates.