Blocker
Tool can access customer data with weak identity, broad scopes, no logs, or unsafe local execution.
Do not approve production use.MCP security
MCP security risks for customer security reviews
Map MCP security risks to customer questionnaire answers, evidence, and red flags before agents can use tools that touch customer data.
Risk review outputRisk to evidence
Risk
Acceptable control
Evidence
Red flag
Direct answer
MCP risk reviews should focus on whether an agent can be tricked, over-authorized, supplied with unsafe tools, given exposed credentials, or allowed to act without audit logs and human approval.
MCP risk to evidence table
Use this table as the working copy for AI security questionnaires, vendor risk reviews, and internal launch gates.
| Risk | What can go wrong | Acceptable control | Evidence to keep | Red flag |
|---|---|---|---|---|
| Prompt injection | Tool output, retrieved content, or external documents can instruct the agent to ignore policy or call unsafe tools. | Treat retrieved content and tool output as untrusted input before allowing sensitive follow-up actions. | Prompt injection policy, blocked-call tests, denied action logs, human approval rules. | The agent can call write, export, or admin tools directly after reading untrusted content. |
| Tool poisoning | A changed tool name, description, schema, or package can steer the agent toward unsafe behavior. | Review tool metadata, schema changes, package provenance, and version updates before production exposure. | Tool review checklist, package source, pinned version, approval ticket, rollback plan. | MCP package updates can change tool instructions without owner review. |
| Token theft | Long-lived or over-scoped tokens can leak through logs, local config, prompts, tool output, or compromised packages. | Use scoped credentials, short lifetimes, secrets storage, redaction, and tested revocation paths. | OAuth scope sheet, secrets policy, revocation runbook, token access log. | Shared static tokens or refresh tokens live in agent-visible files. |
| Over-scoped tools | A useful MCP tool can become too powerful if it grants broad read, write, export, or admin actions. | Map tools to least-privilege roles, denied operations, approval rules, data classes, and environments. | Tool permission matrix, approval policy, denied operation list. | One tool grants broad access across files, tickets, databases, and production systems. |
| STDIO command execution | Local STDIO launch patterns can turn configuration, scripts, or package behavior into an execution surface. | Limit approved clients, isolate launched processes, restrict file and network access, and review commands. | Approved client list, sandbox policy, command allowlist, host isolation notes. | Users can add arbitrary local MCP commands without review. |
| Registry supply chain | Unverified MCP servers, abandoned packages, typosquatting, or dependency drift can introduce hidden behavior. | Install from verified sources, pin versions, review provenance, and monitor package changes. | Package provenance, dependency review, version pinning, update approval. | Teams install MCP servers from public registries without ownership or review. |
| Confused deputy and token passthrough | An agent, gateway, or server can use a valid token in a context the user did not intend. | Document token flows, enforce audience and scope checks, require user consent, and avoid unsafe passthrough. | Token flow diagram, OAuth scope map, consent record, gateway policy. | End-user tokens are forwarded to tools without clear audience, consent, or revocation. |
| Missing audit logs | Without tool-call logs, teams cannot reconstruct what an agent did during a customer review or incident. | Log tool calls, denied actions, approvals, token use, config changes, and emergency disablement. | SIEM query, event schema, retention policy, sample audit log. | Logs only show generic agent activity, not individual MCP tool calls. |
Customer questionnaire mapping
Translate technical risks into answers that a security reviewer can verify.
| Customer question | Acceptable answer pattern | Evidence | Red flag |
|---|---|---|---|
| Which MCP risks have you assessed before production use? | We review prompt injection, tool poisoning, token handling, tool permissions, STDIO isolation, package provenance, audit logs, and emergency disablement before MCP tools can touch customer data. | Risk register, approval checklist, owner review date. | No written MCP risk inventory exists. |
| How do you prevent prompt injection from triggering unsafe tool calls? | Retrieved content and tool output are treated as untrusted. Sensitive actions require policy checks, allowlists, or human approval before execution. | Prompt injection test cases, approval policy, denied-call logs. | Untrusted content can directly influence write, export, or admin tool calls. |
| How do you prevent MCP tool poisoning? | Tool names, descriptions, schemas, package sources, and updates are reviewed before production exposure and can be rolled back if suspicious. | Schema review, package provenance, pinned version, change approval. | Tool metadata can change after approval without owner review. |
| How are tokens and OAuth scopes controlled? | Each integration has minimum scopes, credential storage rules, token lifetime, revocation owner, and change-review requirements. | OAuth scope sheet, token flow diagram, secrets manager record. | Shared tokens or broad scopes are reused across agents and tools. |
| What logs can you provide for MCP activity? | We capture caller, server, tool, decision, approval, denial, token use, data boundary, and incident response events. | Audit log sample, SIEM destination, retention policy. | Logs do not identify the tool call, caller, or authorization decision. |
Risk severity bands
Use severity to decide whether MCP use is blocked, restricted, or ready for customer-review evidence.
High
A known risk exists, but compensating controls are incomplete or not evidenced.
Restrict data access and create a remediation owner.Medium
Controls exist, but review cadence, package provenance, or customer-safe evidence is incomplete.
Allow limited use while evidence is completed.Low
Controls are documented, monitored, and tied to answer-library evidence.
Keep review dates and drift checks current.Evidence sources and references
Use external references for policy language, then keep your own customer-safe proof inside the answer library.
MCP security best practices
Official MCP guidance covers consent, authorization, token passthrough risk, confused deputy concerns, and session hijacking considerations.
OWASP MCP Tool Poisoning
OWASP describes MCP tool poisoning as an indirect prompt injection risk where tool metadata can steer an agent toward unsafe behavior.
MCP authorization specification
The MCP authorization specification helps reviewers ask about HTTP-based authorization flows, OAuth responsibilities, and token handling.
MCP client concepts
Client guidance reinforces explicit user control, consent, and tool-call authorization boundaries.
Next steps
Move from risk identification to controls, scanner requirements, gateway policy, and reusable questionnaire evidence.
MCP best-practices hub
Use the full checklist to turn risk findings into a production-readiness score.
MCP server controls
Map server inventory, auth, tool permissions, prompt injection controls, and logs.
MCP gateway controls
Use gateway policy, RBAC, OAuth scopes, token custody, and audit trails for enforcement evidence.
MCP scanner checklist
Convert risks into scanner requirements and manual review prompts.
AI vendor questionnaire
Translate MCP and AI risk controls into customer questionnaire questions.
Evidence checklist
Store owner, proof, review date, red flags, and reusable answer text.
MCP security risks FAQ
Short answers for teams preparing AI security questionnaire evidence.
What are the main MCP security risks?
The main MCP security risks are prompt injection, tool poisoning, token theft, over-scoped tools, unsafe STDIO execution, supply-chain drift, confused-deputy behavior, token passthrough issues, and missing audit logs.
Why do MCP risks matter in customer security questionnaires?
MCP can connect AI agents to business tools and customer data. Buyers may ask how tool access, OAuth scopes, agent actions, logs, and unsafe instructions are controlled.
Is tool poisoning the same as prompt injection?
No. Prompt injection usually comes from untrusted content or tool output. Tool poisoning changes or abuses tool metadata, descriptions, schemas, or packages so the agent chooses unsafe behavior.
What evidence should teams keep for MCP risk reviews?
Keep an MCP inventory, tool permission matrix, OAuth scope sheet, package provenance, prompt injection tests, approval logs, audit log sample, revocation runbook, and owner review date.
Should MCP risks be handled by a scanner or a gateway?
Use both when needed. A scanner helps find risky configuration, packages, and tool metadata. A gateway can enforce identity, policy, approval, logging, rate limits, and emergency disablement.
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.