MCP servers as third-party vendors: the diligence question your TPRM program hasn't caught up to

For what the Model Context Protocol actually is, start with our companion piece, **our MCP explainer. This post makes one narrow, uncomfortable argument on top of it: **an MCP server is a third-party vendor, and if your third-party risk management (TPRM) program isn't treating it like one, you have a category of relationship touching your data that never went through the front door.

What happened

The Model Context Protocol (MCP) is the connector standard that lets AI assistants reach tools and data — a USB-C port for AI, in the common phrasing. It matured fast. As of the November 2025 specification, any MCP server reachable over the internet must implement OAuth 2.1 with PKCE — no exceptions — and the ecosystem standardized on protected-resource metadata (RFC 9728) and audience-bound tokens (RFC 8707) so a token issued for one server can't be replayed at another (MCP authorization spec; Stack Overflow, Jan 2026). The 2026-07-28 release candidate is the largest revision since launch — a stateless core, server-rendered UI ("MCP Apps"), long-running Tasks, and authorization aligned more closely with OAuth and OpenID Connect (MCP blog, Jul 2026). In the enterprise, the gateway pattern — one proxy validating tokens and producing a unified audit log in front of many servers — became the dominant deployment shape (WorkOS, 2026).

That's a lot of security machinery, and it's genuinely good. But notice what it's about: it makes the connection trustworthy. It says nothing about whether the company running the server should have your data. That's a vendor question, and vendor questions belong to you.

Why it matters

Strip away the protocol vocabulary and here's what an MCP server is: a piece of software, usually run by someone else, that you grant network access and a scoped token so it can read or act on your data. Rewrite that sentence without "MCP" and it's the exact definition of a third-party service provider — the thing your TPRM program exists to diligence.

The problem is how MCP servers enter your environment. A traditional vendor arrives through procurement: a contract, a security review, a place on the vendor list. An MCP server arrives when someone technical adds a connector — often in minutes, often to move faster, often without anyone in compliance knowing a new third party now touches your data. It's shadow IT with a standards body. The OAuth machinery makes the connection clean, which paradoxically makes the governance gap easier to miss: the handshake looks secure, so no one asks the vendor questions.

This is why MCP belongs in this series next to A2A and the agent-identity problem. Each is a different route by which something acts on your data without passing through the oversight you built for "vendors." MCP is the most direct: it's an actual server, run by an actual party, holding an actual token.

The incumbent data says the gap is real. In Ncontracts' 2026 State of TPRM survey (n=173), AI risk tied cybersecurity as financial institutions' top third-party concern for the first time — yet 72% of respondents were only partially aware which of their vendors even use AI, and 0% called themselves "extremely confident" managing it. If firms can't see the AI inside vendors they already contracted with, a server a developer wired up last quarter is nowhere on the map.

What it means for you

If you're a credit union or community bank — This is your sharpest version of the problem, for a structural reason: the NCUA cannot examine your third-party technology vendors (GAO-25-107197, May 2025; a legislative fix has been recommended since 2015 and still isn't law). There is no examiner backstopping the company behind an MCP server. If it holds a token to member data, the entire diligence burden is yours — and an MCP server that entered through a developer's connector never got even the diligence you do perform. Do-this-Monday: add one line to your vendor intake and your AI use inventory — does any tool connect to our systems through MCP or a similar connector, and if so, what does it reach and who runs it? Then apply your existing framework. NCUA diligence is proportional (07-CU-13 / SL 07-01): a server that touches member PII or core data gets real diligence; a read-only connector to a public calendar gets a light-touch note. The move isn't more work — it's making sure these relationships land in the framework you already run instead of beside it.

If you're an RIA or broker-dealer — Reg S-P requires written policies for ongoing oversight, due diligence, and monitoring of service providers (17 CFR 248.30(a)(5)), with 72-hour provider-to-firm and 30-day customer breach-notice obligations and a written incident-response program — and it's a named SEC Examinations FY2026 priority. An MCP server holding a token to client data is a service provider under any honest reading of that rule. If it's not on your provider list, your "ongoing oversight" has a hole exactly where a token lives. Do-this-Monday: inventory the connectors touching client systems, and for each, capture who runs it, what it can reach, and how you'd learn if it were breached. That last question is the one Reg S-P's 72-hour clock makes unavoidable — you can't receive a breach notice from a vendor you never recorded as one.

How to get ahead of it

1. Put "MCP server" on your definition of "vendor." One sentence in your TPRM policy: any external service granted access to firm or customer data — including MCP servers and AI connectors — is a third-party service provider subject to this program. That sentence closes the shadow-IT door on paper, which is where oversight starts.
2. Inventory the connectors. You can't diligence what you can't see. The connectors your team has wired up are discoverable — through the OAuth grants and integrations in your identity provider and SaaS admin consoles. (Our Playbook on reading OAuth grants walks the exact mechanics.)
3. Scope the token, then diligence the party. For each server: what data can it reach, who operates it, is the connection OAuth-scoped and audience-bound, and can you revoke it in one move? Proportionality decides how deep you go.
4. Prefer the gateway pattern where you can. A single MCP gateway that validates tokens and produces one audit log turns "many ungoverned connectors" into "one governed choke point with a log." If your environment supports it, it's the difference between diligence you can evidence and diligence you assert.

What to watch out for

The overreaction: banning MCP outright. It's becoming standard plumbing for the AI tools your staff already use; a ban drives the connectors underground, which is the exact failure mode you're trying to prevent. Govern the doorway, don't brick it.

The snake oil: "MCP-secure" or "MCP-compliant" vendor badges. The protocol's OAuth 2.1 machinery secures the connection; it certifies nothing about the company on the other end or what they do with your data once the token clears. A locked door tells you nothing about who you handed the key to. Diligence the party, not just the handshake.

The false comfort: "it's read-only, so it's fine." Read-only still means a third party is reading your regulated data, which is precisely the access a data-protection rule cares about. Read-only lowers the action risk, not the diligence obligation. It's a proportionality input, not an exemption.

The bottom line

An MCP server is not a feature; it's a vendor wearing a protocol's clothes — a company you've given a token and a line to your data, usually without a contract, a review, or a spot on the list. Bringing those connectors into the TPRM program you already run is the whole job, and it starts with seeing them. That inventory — every connector, what it reaches, who runs it, and a dated record you can hand an examiner — is exactly what a Discover scan produces. Behind each entry sits our vendor research library, so the diligence questions come pre-answered instead of pre-asked.

Request your Discover scan — we run it with you, and the connectors your team wired up are the first thing it finds.