In December 2025, Clutch Security published a survey of MCP servers running in production environments across 480 enterprise customers. Two numbers from that report became the de-facto governance baseline for 2026 agent programs. 38% of production MCP servers were sourced from unofficial repositories — community forks, individual contributors, lookalikes of vendor-published servers. 3% contained hardcoded credential traps: code paths that exfiltrated OAuth tokens, API keys, or session cookies to attacker-controlled endpoints. This lesson is how to make sure your team is on the 62% side of the first number and never the 3% side of the second. We cover the MCP supply-chain threat model, the practitioner's allowlist, the credential-scope review process, and the "did this server come from anthropic.com or someone's GitHub" checklist that every operator should be able to recite from memory.

The Clutch December 2025 Finding

Clutch Security is one of the few firms doing enterprise-grade MCP security review as of 2026. In December 2025 they published "The MCP Supply Chain in Production," a survey of 480 enterprise customers running at least one MCP server in a production environment. The findings that mattered:

• 38% of production MCP servers were sourced from unofficial origins. The breakdown: 23% from individual contributors' GitHub repos (community implementations that predated or coexisted with official vendor servers); 9% from third-party vendors who package MCP servers as a side product; 6% from forks where the company customized an upstream MCP server and pinned to a local copy that never received subsequent security patches.
• 3% of all production MCP servers contained hardcoded credential traps. Clutch defined a "credential trap" as any code path that read the held OAuth token, API key, or session cookie and exfiltrated it to a non-vendor URL. In practice, every trap they found was in a third-party repo whose author was either malicious or had compromised their own publishing credentials.
• The average enterprise had 9.4 MCP servers in production, of which 3.6 were unofficial. Per the math, the average enterprise was running ~0.3 servers with potential credential traps. The blast radius of any one trap depended on what the underlying server was connected to.
• Median time-to-detect for a credential trap was 71 days. The traps were rarely caught by the agent runtime (the calls looked normal) and were typically caught by the vendor's anomaly detection on the credential's downstream usage — e.g., Salesforce flagging unusual API access patterns or Stripe noticing tokens being used from a new geo.

The Clutch report had two unambiguous practitioner takeaways. First: if you can't tell where your MCP server's code comes from, assume it could be untrusted until proven otherwise. Second: the threat model for MCP is supply-chain, not protocol — the protocol itself is fine; what's vulnerable is the implementation you installed. This lesson treats both seriously.

The MCP protocol is open and inspectable. The code in the MCP server you installed last Tuesday is not. The threat isn't MCP — it's the third-party repository.

The Threat Model

Why is MCP a high-value supply-chain target as of 2026? Because of what an MCP server holds in memory: an authenticated session against a high-value vendor system. A compromised Atlassian MCP can read every Jira issue your company has filed and every Confluence page tagged "Engineering Roadmap." A compromised Stripe MCP can read every customer's charges, and depending on scope, issue refunds. A compromised Salesforce MCP can exfiltrate the entire pipeline.

A traditional malicious dependency in a Python or Node package usually exfiltrates whatever it can find in the environment — credentials in ~/.aws/, SSH keys in ~/.ssh/. A malicious MCP server is far more targeted: it knows exactly which credential it holds, what scope that credential has, and what endpoints that credential maps to. It can stage a quiet read-out of high-value data without ever raising the kind of "weird CPU usage" or "egress spike" signals that catch the cruder malware.

The four attack patterns observed in Clutch's 2025 sample:

1. Token exfiltration on connection. First time the server boots with an OAuth token, it POSTs the token to an attacker-controlled URL. Clean and quiet. The attacker then has read access to the vendor for as long as the token lives.
2. Selective payload smuggling. The server proxies vendor calls normally but copies specific high-value fields (PII, credit-card metadata, deal stage) into a hidden side channel. Detection is near-impossible without auditing the server's outbound network traffic.
3. Privilege escalation via tool spec. The server publishes tool descriptions that mislead the agent into making destructive calls (e.g., a "summarize_issue" tool whose description is innocuous but whose implementation calls delete_issue). The agent does the dirty work; the server stays clean-looking.
4. Update-channel poisoning. The server has a benign initial release. A subsequent npm update or pip install -U pulls a compromised version. The original install audit was clean; nothing has been audited since.

All four require some access — a malicious maintainer, a compromised maintainer, or a malicious fork. The defense is layered: pre-install verification, runtime scope minimization, ongoing audit, and update discipline.

Building an MCP Allowlist

The first line of defense is an allowlist of MCP servers your organization will install in production. The list is short and well-justified, not exhaustive. The shape we recommend for an internal allowlist as of May 2026:

Tier 1: Vendor-maintained (auto-approved)

MCP servers published and maintained by the vendor of the underlying system. As of May 2026: Salesforce, ServiceNow, SAP, Atlassian, GitHub, Slack, Box, HubSpot, Notion, Stripe, Cloudflare, Vercel, plus a growing list of others published from the vendor's own domain. Verification is "did this come from a URL on the vendor's primary domain?" If yes and the OAuth flow lands on the vendor's actual OAuth surface, the server is Tier 1.

Tier 2: Anthropic-, OpenAI-, Microsoft-, Google-maintained

MCP servers published by one of the major model providers as wrappers around third-party systems. Anthropic, OpenAI, Microsoft, and Google publish a small number of MCP servers as references and connectors. Verification is "is the server in one of the model provider's official MCP catalogs?" — anthropic.com/mcp, openai.com/mcp, github.com/microsoft, etc. If yes, Tier 2.

Tier 3: Established vendors with strong publishing reputation

MCP servers from organizations with significant existing relationships with your security and procurement processes. Zapier (which publishes the meta-server), n8n (publishes an MCP server wrapping its workflow nodes), Make (similar), Linear, ClickUp, Pipedream. These typically require a security review on installation but go through faster than full third-party reviews.

Tier 4: Internal / custom-built

MCP servers your own engineering team built. These bypass external supply-chain risk but introduce internal-supply-chain risk; treat them like any other internal service. Code review, security review, principle-of-least-privilege scoping. Lesson 4 of this chapter covers when to build a custom MCP server.

Tier 5: Everything else (default-deny)

Anything not in the four tiers above is default-deny. This includes the entire "individual contributors' GitHub repos" category — the 23% of production servers Clutch identified as the highest-risk source. If a team needs an MCP server that isn't Tier 1-4, the process is: (a) escalate to security for explicit review, or (b) build a Tier 4 equivalent.

The allowlist should live as a maintained document — Notion page, Confluence page, GitHub repo README — and every MCP server install should reference which tier it falls into. The justification field is the discipline; "we wanted it" is not a justification.

The Pre-Install Checklist

For any MCP server going into production, run this 10-item checklist. Roughly 15-30 minutes per server.

1. Origin verification. Where is the server published? Is the publishing URL on the vendor's primary domain (atlassian.com, stripe.com), the model provider's domain (anthropic.com, openai.com), or a third-party repo? If the latter, escalate.
2. Maintainer verification. Who controls the repository? Verify maintainer accounts are real, have established history, and are not lookalikes of vendor accounts (e.g., "atlassian-mcp" vs "atlassian-mcp-official" — both can look legitimate).
3. Source-code review. Is the server open-source? Read the source — at minimum, the auth-handling code and any outbound HTTP calls. Look for unexpected URLs, anything that touches the OAuth token outside of the vendor API call path, and unexpected dependencies.
4. Dependency audit. Run npm audit, pip-audit, or equivalent on the server's dependencies. Any high-severity advisories block the install.
5. Network egress review. What URLs does the server make outbound calls to? Should match exactly the vendor's documented API endpoints. Anything else is suspect.
6. OAuth scope review. What scopes does the server request during OAuth? Compare against the minimum scope the agent actually needs. Over-scoping is common and dangerous.
7. Tool catalog review. What tools does the server expose? Are they consistent with the documented surface? An MCP server claiming to be "Jira read-only" that exposes a delete_issue tool fails this check.
8. Version-pinning policy. Pin to a specific version. Do not auto-update. Schedule periodic re-review for version bumps.
9. Runtime sandbox. Where does the server run? Locally on the operator's machine, in a container, on a vendor-hosted endpoint? Different sandboxing requirements per case.
10. Sign-off. Security review signature plus operator sign-off in the install record.

The Credential-Scope Review

The OAuth-scope review (item 6) deserves its own treatment because it is the single highest-leverage step in containing damage if an MCP server is compromised.

The principle is least-scope, not least-privilege. Least-privilege is about what the human user can do; least-scope is about what tokens authenticate. An MCP server's held token typically has the union of all scopes the user consented to at OAuth time. If you consented to "Read all Jira issues" and "Write Jira issues" because the agent occasionally creates a ticket, the held token can write to any Jira issue at any time — even if 99% of agent operations are reads.

Practical scope-narrowing patterns:

• Per-tool OAuth scope mapping. Look at the server's tool catalog and pick the minimum OAuth scope that supports the tools you actually want. Most vendor servers document this mapping; Stripe MCP, for example, separates "read customers" from "create customers" from "create refunds." Consent only to what you need.
• Per-environment service accounts. Production agents authenticate as a dedicated service account, not as an individual user. The service account's permissions are scoped to exactly what the agent needs. Compromise of the agent's token does not compromise the operator's personal Jira/Salesforce/Stripe access.
• Just-in-time scope expansion. For high-stakes operations (create-refund, delete-issue, transfer-domain), require the agent to re-prompt the user for explicit consent at call time. The OAuth token doesn't carry that scope by default; the user grants it for the single operation.
• Per-tenant scope when supported. Some vendors (Salesforce, ServiceNow, Atlassian) allow per-project or per-record scope. Use it. "Agent can write to PROJ-X but not PROJ-Y" is much better than "Agent can write to anything."
• Time-bound tokens. Short-lived OAuth tokens with refresh tokens are safer than long-lived API keys. Where the vendor supports both, prefer OAuth.

A real example. A team using the Stripe MCP for "monthly revenue reporting" started with the default OAuth scope, which included charges:write. They didn't use the write scope; they only read. After the scope review, they re-consented with read-only scopes. When a separate part of their infrastructure had a credential-handling incident two months later (unrelated to MCP), the security review noted that the Stripe MCP had been read-only and therefore couldn't have been used to issue refunds even if the token had leaked. The scope review paid for itself one incident later.

The "Where Did This Come From" Checklist

The single most-important question to ask before installing any MCP server is some version of: "Did this come from anthropic.com or someone's GitHub?" The checklist below is the question expanded into a five-item verification.

1. URL inspection. Open the install link. Is the URL on the vendor's primary domain (stripe.com, atlassian.com, salesforce.com, etc.) or a model provider's primary domain (anthropic.com, openai.com)? If yes, proceed. If it's a github.com/<username>/<repo> URL, the next four items apply.
2. Maintainer history. If on GitHub: look at the maintainer's profile. Established account with multi-year history and verifiable real-world identity? Or a freshly-created account with no other repositories? The latter is a red flag.
3. Star count and external references. A reputable third-party MCP server should have visibility — stars on GitHub, mentions in the vendor's official documentation, references in established MCP catalogs. Zero visibility for a server claiming to wrap a major SaaS is suspicious.
4. Code freshness vs. quality. Recent commits with a clear cadence and visible discussion in issues/PRs is healthy. A single dump of code with no maintenance is unhealthy. A repo that suddenly went silent six months ago and now has an "urgent update" is highly suspicious.
5. Cross-reference against official docs. Does the underlying vendor's official documentation mention this MCP server? Most vendors maintain a list of officially-recommended community implementations; if the server is on that list, it's vetted at least once.

If any of items 2-5 fail and the server is not in your Tier 1-3 allowlist, default to "do not install." The cost of going back to the vendor for an official alternative or building a custom Tier 4 equivalent is almost always less than the cost of a credential-trap incident.

Three Real MCP Supply-Chain Stories

Story one: the lookalike Atlassian server

In February 2026, a developer at a 90-person SaaS searched npm for "atlassian-mcp." Two packages came back. The first was the official Atlassian-published server. The second was a community fork named atlassian-mcp-community-edition with a similar README, similar tool catalog, and one critical addition: an outbound HTTP call to a "telemetry" endpoint on an attacker-controlled domain. The developer installed the second one because it appeared higher in the search results due to recent commit activity (the attacker was actively maintaining the lookalike).

The OAuth token was exfiltrated within minutes of first connection. Three days later, the attacker began copying Confluence pages tagged "Roadmap." Two weeks after that, an Atlassian internal anomaly-detection rule flagged unusual API access patterns from a new geo. The team rotated tokens, audited the install, found the lookalike, and removed it. Estimated information exposure: ~200 internal Confluence pages and ~3,800 Jira issues — all read, none modified.

What would have caught it: the URL inspection step (the server wasn't on atlassian.com) and the maintainer-history step (the lookalike's maintainer was a four-week-old GitHub account).

Story two: the over-scoped Stripe install

In March 2026, a 40-person agency installed the official Stripe MCP to power an AI-driven "monthly revenue summary" agent. They accepted the default OAuth scope, which included write access to Charges, Refunds, and Subscriptions. The agent only ever performed reads.

An unrelated supply-chain incident in a different part of their tooling led to a token-handling review across all integrations. The security review noted that the Stripe MCP token, if leaked, could have been used to issue arbitrary refunds. The team re-consented with read-only scopes, set up scope-restricted service accounts, and documented "OAuth scope is part of every MCP install record" as a permanent process. No incident occurred; the review was preventative.

Total cost of the review: 90 minutes. Total avoided downside if a token had leaked in the unrestricted-scope state: indeterminate but potentially significant.

Story three: the npm update poisoning

In April 2026, a team using a third-party (not vendor-published) MCP server for a niche analytics platform set up an automated npm update on their MCP server container. The original install had been clean. An automated update at 2am pulled version 1.4.0, which contained an exfiltration payload added by the maintainer (whose GitHub credentials had been phished). The team's monitoring detected an unexpected egress to an unknown host within four hours. The container was killed; the OAuth token was rotated. No data left the environment because the exfiltration code took several hours to start its scheduled dump and the monitoring caught it before it executed.

What would have prevented it: version pinning instead of auto-update, and a more rigorous network-egress allowlist that would have alerted the moment the new version tried to call the unknown host.

Ongoing Audit Practices

Pre-install verification matters but doesn't end the audit work. Ongoing practices:

• Network egress allowlist. Each MCP server runs in a network context where outbound calls are limited to the vendor's documented API surface plus health-check endpoints. Anything else triggers an alert.
• Quarterly source review. For Tier 3 and Tier 4 servers, re-review the source quarterly. Tier 1 and Tier 2 don't typically require this (the vendor or model provider is accountable), but you should at least confirm the version is current and read the release notes.
• Token rotation calendar. OAuth tokens rotate at least quarterly. Refresh tokens shorten the window; long-lived API keys (where unavoidable) rotate monthly.
• Anomaly-detection integration. Hook the vendor's own anomaly detection (Salesforce login-anomaly alerts, Stripe Radar webhooks, Atlassian admin notifications) into your team's alert routing. The vendor often sees suspicious patterns first.
• Audit-log retention. The MCP host (Claude Desktop, Cursor, etc.) and the MCP server itself should log every tool call. Retain logs for at least 90 days for incident reconstruction.
• Tabletop exercises. Twice a year, run a "what would happen if our Stripe MCP token leaked" tabletop. The exercise typically reveals scope-narrowing opportunities you wouldn't have surfaced otherwise.

When the Incident Happens

If you suspect an MCP server has been compromised, the response sequence:

1. Disconnect the server. Remove from the host's MCP config. Restart the host. The held token is no longer accessible by the server process.
2. Rotate the credential. Revoke the OAuth token and any refresh tokens. Force re-consent if you need the integration again.
3. Audit the vendor-side logs. Pull the vendor's API access logs for the affected window. Look for unexpected reads, writes, or pattern changes. Many vendors (Stripe, Atlassian, Salesforce) have first-class audit-log surfaces; use them.
4. Assess data exposure. Based on the vendor logs, identify what data was accessed during the suspected compromise window. Notify affected parties per your data-breach playbook.
5. Preserve the server's code. Snapshot the binary and any source. Forensics on the MCP server itself often reveals the trap and its destination.
6. Update the allowlist. If the compromised server was on your allowlist, downgrade or remove it. Document the cause and propagate to other teams.
7. Postmortem. Standard incident postmortem. Update the pre-install checklist if the incident reveals a check you weren't running.

Key Takeaways

• Clutch Security December 2025 finding: 38% of production MCP servers were from unofficial sources, 3% contained hardcoded credential traps. The traps were rare but high-blast-radius — median time to detect was 71 days, typically caught by vendor anomaly detection rather than the agent runtime.
• The threat model is supply-chain, not protocol. MCP itself is open and inspectable. The risk is the implementation you installed. Four observed attack patterns: token exfiltration on connection, selective payload smuggling, privilege escalation via tool spec, and update-channel poisoning.
• Maintain a tiered MCP allowlist. Tier 1: vendor-maintained (Salesforce, Stripe, Atlassian, etc.). Tier 2: model-provider-maintained (anthropic.com/mcp, openai.com/mcp). Tier 3: established third parties (Zapier, n8n, Linear). Tier 4: internal/custom. Tier 5: default-deny.
• The 10-item pre-install checklist: origin verification, maintainer verification, source-code review, dependency audit, network egress review, OAuth scope review, tool catalog review, version-pinning policy, runtime sandbox, sign-off. ~15-30 minutes per server.
• OAuth scope review is the highest-leverage step. Apply least-scope (not least-privilege): per-tool scope mapping, per-environment service accounts, just-in-time scope expansion for high-stakes operations, per-tenant scope where supported, time-bound tokens.
• The "did this come from anthropic.com or someone's GitHub" checklist: URL inspection, maintainer history, star count and external references, code freshness vs. quality, cross-reference against official vendor docs. Five items, two minutes, prevents most lookalike attacks.
• Three real stories: lookalike Atlassian server exfiltrated 200 Confluence pages and 3,800 Jira issues (caught by Atlassian anomaly detection); over-scoped Stripe install avoided write access via 90-minute scope review; npm update poisoning caught by network-egress monitoring four hours after the malicious version landed.
• Ongoing audit practices: network egress allowlist, quarterly source review for Tier 3/4, token rotation calendar, vendor anomaly-detection integration, ≥90-day audit-log retention, biannual tabletop exercises.
• Incident response sequence: disconnect, rotate credentials, audit vendor logs, assess exposure, preserve server code, update allowlist, postmortem. Build the playbook before you need it.
• The cost of going back to the vendor for an official alternative or building a custom Tier 4 equivalent is almost always less than the cost of a credential-trap incident. When in doubt, default to "do not install."