MCP Security Assessment
The Model Context Protocol (MCP) lets an AI agent discover and invoke external tools, resources, and prompts exposed by an MCP server — file systems, databases, SaaS APIs, internal services, or another agent. That's exactly what makes an MCP server request a different review than a normal SaaS or API integration: you're not just granting a system access to data, you're granting a language model the ability to autonomously decide when and how to invoke that access, based on untrusted natural-language input it processes along the way. This guide gives security teams a structured assessment framework for reviewing MCP server integration requests, aligned to the NIST AI Risk Management Framework (AI RMF 1.0), its Generative AI Profile (NIST AI 600-1), NIST SP 800-53 Rev. 5, and the OWASP Top 10 for LLM Applications.
Scope: This covers reviewing a specific MCP server before/during onboarding — not general LLM application security or model-level risk (training data, model theft, etc.), which are covered elsewhere.
Why MCP Servers Are a Distinct Risk Category
A conventional API integration has a fixed, human-written call graph — a developer decided exactly which endpoints get called, when, and with what parameters. An MCP-connected agent has none of that determinism: the model reads tool descriptions and decides at runtime whether and how to call them, often chaining multiple tools based on the content it retrieves from those same tools. That creates threat patterns with no direct legacy-API equivalent:
| Risk |
Description |
| Indirect prompt injection via tool output |
Content returned by a tool (a web page, a file, a ticket description, an email body) is injected into the model's context and can contain instructions the model may follow — the untrusted data source becomes an attacker-controlled command channel. |
| Tool description / schema poisoning |
The tool's name, description, and parameter schema — not just its output — are part of what the model reads. A malicious or compromised server can embed hidden instructions in a tool description that never appears in any UI the human reviewer sees. |
| MCP "rug pull" |
A server a user or admin already approved silently changes its tool definitions or behavior after approval (on the next connection, a tool's description or code changes) — the trust decision was made against a version that no longer exists. |
| Excessive agency / confused deputy |
The agent frequently runs with the combined privilege of the user's session and the MCP server's own credentials, and can be induced to use that combined privilege in ways neither party individually intended. |
| Tool shadowing / name collision |
A second, malicious MCP server registers a tool with a name or description similar to a trusted one, or overrides expected behavior when multiple servers are connected in the same session. |
| Cross-server / cross-session data leakage |
An agent with multiple MCP servers connected in one session can be induced to move data from a sensitive server (e.g., internal ticketing) to an untrusted one (e.g., a public web-fetch tool), exfiltrating via the agent itself rather than any traditional network path. |
These map directly onto OWASP LLM01 (Prompt Injection), LLM07 (Insecure Plugin Design), and LLM08 (Excessive Agency) — treat an MCP server request as a plugin/tool review, not a routine SaaS approval.
Assessment Domains
1. Identity, Authorization, and Least Privilege
| Check |
What You're Looking For |
| Authentication mechanism |
OAuth 2.1 (MCP's recommended approach for remote/HTTP servers), signed API keys, or mTLS — not static shared secrets embedded in client config |
| Credential scope |
Does the server's credential map to a least-privilege service account, or does it inherit a broad user/admin identity? |
| Per-user vs. shared identity |
Does the agent act as the requesting user (preserving individual accountability) or as a shared service identity that flattens all actions to one principal in downstream audit logs? |
| Confused-deputy exposure |
Can the agent be induced to use the MCP server's own elevated credential to perform an action the requesting user individually could not authorize? |
| Token storage |
Are OAuth tokens/API keys stored in an OS credential store or secrets manager, not plaintext in a config file readable by the user's full session? |
| Consent granularity |
Does the client surface which tools/scopes are being granted, or is it an all-or-nothing connection with no visibility into individual capabilities? |
| Check |
What You're Looking For |
| Full capability enumeration |
List every tool the server exposes — not just the ones described in its marketing/README. Call tools/list and review the actual returned schema. |
| Destructive/write capability |
Does any tool perform writes, deletions, financial transactions, or irreversible actions? These require a materially higher bar than read-only tools. |
| Code/command execution |
Does any tool run arbitrary code, shell commands, or SQL as constructed by the model? This is the highest-risk capability class and should default to deny absent a specific, documented business case. |
| Parameter constraints |
Are tool parameters tightly typed/enumerated, or do they accept free-form strings that get passed to a shell, SQL query, or file path with no server-side validation? |
| Human-in-the-loop gating |
Does the client require explicit user confirmation before executing high-risk tool calls, or does it auto-execute anything the model decides to call? |
| Tool description integrity |
Read the actual tool descriptions and parameter schemas character-for-character — this is where hidden instructions get planted. Don't rely on a vendor's summary of what a tool does. |
3. Data Flow and Exfiltration
| Check |
What You're Looking For |
| Data classification touched |
What's the highest sensitivity of data this server can read or write (public, internal, confidential, regulated/PII)? |
| Egress destination |
Is the server local/on-prem, or does it call out to a third-party cloud API? Where is that provider's data residency, and what's their retention/training-use policy on data passed through? |
| Cross-server data movement |
In sessions where multiple MCP servers are connected simultaneously, can data plausibly flow from a sensitive server to a lower-trust one via the model's own reasoning chain? |
| DLP coverage |
Does existing DLP tooling have visibility into agent-mediated data flows, or does the agent represent a blind spot relative to traditional user-initiated transfers? |
| Output handling |
Is tool output re-validated/sanitized before being rendered back to the user or passed to another system, or trusted implicitly (OWASP LLM02 — Insecure Output Handling)? |
4. Supply Chain and Provenance
| Check |
What You're Looking For |
| Publisher identity |
Is the server published by a known, accountable vendor or maintainer, or an anonymous/unverified community package? |
| Distribution channel |
Installed from an official registry with package signing/checksums, or a raw git clone / unpinned npx/pip install from an arbitrary URL? |
| Version pinning |
Is the server pinned to a specific, reviewed version, or does the client auto-update to whatever the maintainer ships next (directly enabling the "rug pull" pattern above)? |
| Dependency review |
Has the server's own dependency tree been through the same SCA/vulnerability scanning your org applies to first-party code (see SAST and SCA)? |
| Source availability |
Is the server open source and reviewable, or a closed-source binary whose actual tool implementations can't be audited? |
| Change notification |
Does the vendor provide a changelog, release signing, or notification mechanism your team can monitor for re-review triggers? |
5. Transport and Infrastructure Security
| Check |
What You're Looking For |
| Transport mode |
stdio (local subprocess — trust boundary is the local host/container) vs. HTTP/SSE (remote — trust boundary includes the network path and the remote server's own security posture) |
| TLS enforcement |
For remote servers, is TLS mandatory with certificate validation, or does the client silently accept plaintext HTTP or unverified certs? |
| Network egress control |
Can the host running the MCP server reach only what it needs (egress allow-listing), or does it have unrestricted outbound access that a compromised tool could exploit? |
| Process isolation |
Does the server run in a container/sandbox with a dedicated non-privileged account, or with the full privilege of the invoking user's session? |
| Resource limits |
Are there rate limits, timeouts, and resource quotas preventing a single runaway or malicious tool call from causing a denial-of-service condition (OWASP LLM04)? |
6. Logging, Auditability, and Human Oversight
| Check |
What You're Looking For |
| Tool-call logging |
Is every tool invocation (caller, parameters, timestamp, result) logged centrally, correlated to the initiating user/session? |
| Log integration |
Do these logs reach the same SIEM as other identity and data-access logs, or live only in a local client log file nobody reviews? |
| Retention |
Does log retention meet the same bar as other access logs for the data classification involved? |
| Explainability of agent actions |
If an incident occurs, can you reconstruct why the agent called a given tool (what context/prompt led to it), not just that it was called? |
| Approval workflow |
Is there a documented, accountable approval step before a new MCP server is connected in a production or business-data context — not an individual user's ad hoc choice? |
Risk Tiering
Use capability and data sensitivity — not vendor reputation alone — to set the review bar:
| Tier |
Criteria |
Review Bar |
| Low |
Read-only, public/internal data, well-known publisher, local stdio transport |
Standard checklist review; lightweight approval |
| Medium |
Read/write on internal (non-regulated) data, or read-only on confidential data; established vendor |
Full checklist; security team sign-off; documented ignoreip-equivalent scoping of what the credential can touch |
| High |
Write/execute capability, confidential or regulated data, remote/third-party hosting |
Full checklist + architecture review; time-boxed pilot with monitoring before broad rollout |
| Critical |
Arbitrary code/command execution, regulated data (PCI/PHI/PII at scale), unverified/community publisher |
Default deny; requires a documented, narrowly scoped business justification, compensating controls (sandboxing, human-in-the-loop on every call), and named accountable owner — treat exceptions the same way Application Control recommends handling any security exception |
Pre-Approval Checklist
| # |
Item |
Status |
| 1 |
Full tool/capability list enumerated and reviewed (not vendor summary) |
☐ |
| 2 |
Tool descriptions and parameter schemas read in full for embedded instructions |
☐ |
| 3 |
Authentication mechanism confirmed (OAuth 2.1 / mTLS / scoped API key — no static shared secrets) |
☐ |
| 4 |
Credential scoped to least privilege, not a broad admin/service identity |
☐ |
| 5 |
Data classification and destination (local vs. third-party cloud) documented |
☐ |
| 6 |
Publisher/provenance and distribution channel verified; version pinned |
☐ |
| 7 |
Dependency/SCA scan completed for the server's own codebase |
☐ |
| 8 |
Transport secured (TLS + cert validation for remote; sandboxed process for local) |
☐ |
| 9 |
Egress/network access from the server's host restricted to what's required |
☐ |
| 10 |
Tool-call logging wired into central SIEM, correlated to user identity |
☐ |
| 11 |
Human-in-the-loop confirmation required for destructive/execute-class tools |
☐ |
| 12 |
Risk tier assigned and matching controls applied |
☐ |
| 13 |
Accountable owner and re-review trigger (version bump, capability change) documented |
☐ |
Ongoing Assessment — Recertification Triggers
Treat MCP server approval as a point-in-time decision that expires, not a permanent grant:
- Any version update to the server — re-diff the tool list and descriptions before allowing the update through, given the rug-pull pattern above.
- Any new tool or changed parameter schema appearing at connection time.
- A scheduled recertification (e.g., annually, or per your standard third-party risk cadence) even with no observed change, to catch silent publisher/ownership changes.
- Any incident or anomalous tool-call pattern in logs — unexpected data destinations, unusual call volume, calls outside expected business hours.
NIST AI RMF (AI RMF 1.0) Function Mapping
| Function |
Applied to MCP Server Review |
| Govern |
Establish an accountable approval process, ownership, and risk-tiering policy for MCP server connections before any team can self-service one in |
| Map |
Enumerate the specific context: what data, what tools, what identity, what downstream systems this server touches once connected |
| Measure |
Assess against the checklist above — capability risk, data sensitivity, provenance, transport, logging coverage |
| Manage |
Apply tiered controls (sandboxing, human-in-the-loop, egress restriction), monitor logs, and recertify on the triggers above |
NIST AI 600-1 (Generative AI Profile) — Relevant Risk Categories
| GAI Risk Category |
Relevance to MCP |
| Value Chain and Component Integration |
The primary category — MCP servers are third-party components integrated into a GenAI system's decision loop; this is the risk this whole guide addresses |
| Information Security |
Tool execution, code-execution capability, and credential handling reviewed in Domains 1–2 above |
| Data Privacy |
Data classification and cross-border/vendor data-residency review in Domain 3 |
| Information Integrity |
Tool description/output poisoning and prompt injection risk covered in the threat model section |
| Human-AI Configuration |
Human-in-the-loop gating for high-risk tool calls (Domain 6) |
NIST SP 800-53 Rev. 5 Control Mapping
| Control |
Title |
Applied Here |
| AC-3 |
Access Enforcement |
Least-privilege credential scoping for the MCP server (Domain 1) |
| AC-4 |
Information Flow Enforcement |
Preventing cross-server data exfiltration via the agent's own reasoning chain (Domain 3) |
| AC-6 |
Least Privilege |
Risk-tiered capability restriction, deny-by-default on execute-class tools |
| IA-2 / IA-5 |
Identification & Authentication / Authenticator Management |
OAuth 2.1/mTLS enforcement, credential storage, rotation |
| SC-7 |
Boundary Protection |
Egress restriction on the host running the MCP server |
| SC-8 |
Transmission Confidentiality/Integrity |
TLS enforcement for remote transport |
| SI-4 |
System Monitoring |
Centralized tool-call logging and anomaly alerting |
| SI-10 |
Information Input Validation |
Parameter schema constraints, output re-validation before downstream use |
| SR-3 / SR-4 / SR-5 |
Supply Chain Controls, Provenance, Acquisition Strategies |
Publisher verification, version pinning, dependency scanning (Domain 4) |
| CA-7 |
Continuous Monitoring |
Recertification triggers and ongoing log review |
OWASP Top 10 for LLM Applications — Mapping
| OWASP Category |
MCP-Specific Manifestation |
| LLM01 — Prompt Injection |
Indirect injection via tool output content |
| LLM02 — Insecure Output Handling |
Tool results trusted and acted on without re-validation |
| LLM04 — Model Denial of Service |
Unbounded/expensive tool calls without rate limits or timeouts |
| LLM05 — Supply Chain Vulnerabilities |
Unverified publisher, unpinned versions, unreviewed dependencies |
| LLM06 — Sensitive Information Disclosure |
Cross-server data movement, third-party data residency |
| LLM07 — Insecure Plugin Design |
The MCP server itself — loose parameter typing, missing auth, no scoping |
| LLM08 — Excessive Agency |
Auto-executing destructive tools with no human confirmation |
References