MCP, explained for people who get audited

Governance Watch — our take on the news a compliance owner actually has to answer for.

If you run risk or compliance at a credit union, a bank, or an RIA, you have probably never been asked about the Model Context Protocol. You will be. Not by name — examiners don't ask about protocols — but by its consequences: "What can this AI tool actually reach? Who approved that? Where's the record?" MCP is the plumbing behind all three of those questions. This is the practitioner's version of what it is and why it lands on your desk.

What happened

MCP — the Model Context Protocol — is now the default way AI tools connect to your data and your systems. It started as an Anthropic open standard in late 2024 and, in about eighteen months, became the thing everyone agreed on: as of early 2026 it was seeing on the order of 97 million SDK downloads a month, was supported by every major AI vendor — Anthropic, OpenAI, Google, Microsoft, AWS — and had ~3,000 servers registered in its official public registry (state of MCP, NimbleBrain).

Think of MCP as a universal adapter. Before it, every AI-to-app connection was a bespoke integration. Now an AI assistant can talk to your calendar, your files, your ticketing system, or a vendor's database through one common protocol — via little connectors called MCP servers. Your staff don't install "MCP." They turn on a feature in a tool they already use, and MCP is what lets that tool reach out and touch something.

Here's the part that matters for you. The protocol's own security model is solid on paper — the current specification requires OAuth 2.1 best practices, resource-scoped tokens, the works. But adoption of that security lags the adoption of the convenience. As of early 2026, industry analysis found only about 8.5% of MCP servers actually used OAuth, security researchers filed 30-plus CVEs in the first two months of the year, and the first real incidents hit the news — a cross-tenant data leak at Asana's MCP connector, a path-traversal flaw at a registry that exposed thousands of apps, and a class of "tool poisoning" attacks against open-source servers (NimbleBrain). The standards body has since shipped an Enterprise-Managed Authorization extension — centralized auth, single sign-on across connected servers, being adopted by Anthropic, Microsoft, and Okta — which is exactly the right direction. It also tells you the plumbing shipped before the locks did.

Why it matters

Strip away the acronyms and MCP is a new, fast-growing, largely invisible layer of third-party access to your data — and it's spreading through the tools your people already have, not through a procurement request you'd see.

You already run a discipline for this. It's called third-party risk management, and your whole job description is knowing who can touch your data and being able to prove you vetted them. MCP doesn't create a new obligation. It creates a new surface your existing obligation now covers — and it's a surface most TPRM programs cannot currently see, because it doesn't look like a vendor contract. It looks like a toggle a staffer flipped in an app you already approved.

The uncomfortable translation: every MCP server your organization connects is, functionally, a vendor with a key to something. If 91.5% of that category isn't using the strong-authentication pattern the standard recommends, then "we use AI responsibly" is not a claim you can currently back with evidence. And an unbacked claim is the thing that turns a routine exam into a finding.

What it means for you

If you're a credit union or community bank: MCP is a TPRM problem wearing a technology costume. Your examiner can't examine your AI vendors directly — NCUA doesn't have that authority, and no federal regulator is doing that diligence for you — so the burden of knowing what these connectors reach is yours, structurally. The move is not to ban MCP. It's to bring it inside the assessment you already do: treat connected MCP servers as in-scope third parties, inventory what data scopes they hold, and keep the analysis proportional the way 07-CU-13 already lets you (a read-only calendar connector is not a core-system integration — don't over-govern the low-risk case). The trap is doing nothing because it never crossed your procurement desk.

If you're an RIA or broker-dealer: this runs straight into Reg S-P. Since June 3, 2026, you're required to maintain written policies for the ongoing oversight of your service providers — and an AI tool reaching client data through an MCP connector is a service-provider access path you're now accountable for. The question an examiner is entitled to ask is simple: which of your AI-enabled tools can reach client records, and what's your basis for trusting them? If the honest answer today is "I'm not sure," that's the gap to close before it's asked, not after.

For both of you, the concrete exposure looks like our canonical example: a meeting-notes AI holds calendar and drive read-access for eight of your staff, retains recordings, and has no SOC 2 on file. Whether that tool reaches your data over MCP or an older integration, the diligence question is identical — and it's the question you want answered on your own timeline.

How to get ahead of it

You get ahead of MCP the same way you get ahead of any third-party surface: inventory, classify, and keep a record.

1. Find the connectors. The AI tools your people use authorize their access through your identity provider — Google Workspace or Microsoft Entra. The list of third-party apps and the data scopes they hold is already sitting in your admin console. That inventory is your first MCP map, whether or not anyone calls it that. (Our playbook on reading OAuth grants walks the steps.)
2. Ask the access question, not the AI question. For each tool: what can it reach, for how many people, since when, and does the vendor publish how it handles that data? "Is it AI?" is less useful than "what does it hold a key to?"
3. Write down your reasoning. Proportional diligence is a defensible position if it's documented. "We reviewed this connector, it's read-only and non-core, here's our basis" is an exam-ready sentence. An unreviewed connector is not.
4. Favor the tools moving toward managed auth. The Enterprise-Managed Authorization work is the healthy signal — vendors and platforms that centralize and log AI access are the ones you can actually govern. Reward them in your selection.

The team that has this inventory before its next exam turns a hard question into a short answer. That's the whole game.

What to watch out for

• "We're MCP-compliant" is not a security claim. Following the protocol says nothing about whether a given server uses strong auth, scopes tokens correctly, or handles your data well. The spec is a floor, and — per the adoption numbers — a floor a lot of servers haven't reached. Make vendors show you their posture, not the protocol's.
• The firewall won't save you. MCP access is authorized access — a key you (or your staff) handed over — not an intrusion. Network tools that look for bad traffic don't see a legitimately-granted connector doing exactly what it was permitted to do. This is an access-governance problem, not a traffic problem.
• Don't confuse convenience adoption with governance adoption. The reason MCP spread so fast is that it's genuinely useful. That same ease is why it outruns oversight. Assume the tools are already in your environment and work backward, rather than assuming a gate you didn't build is holding.
• Beware the over-correction. Banning all AI connectors reads decisive and ages badly — your people route around it, and you lose the visibility you had. Proportional, documented governance beats a prohibition nobody follows.

The bottom line

MCP is the standard that decided how AI reaches your data, and it won the argument before most compliance teams knew there was one. It doesn't hand you a new rule; it quietly widens the third-party surface your existing rules already cover — and it does so through connectors that never crossed your desk. The institutions that will answer the exam question well aren't the ones that banned MCP. They're the ones that inventoried what their AI can touch, wrote down why they trust it, and can produce that record on request.

That inventory — every AI tool your people connected and exactly what data each can reach — is precisely what a Discover scan is built to produce. But you can start the map yourself this week from the admin console you already have.

Related: A2A — Agent2Agent, when your vendors AIs start talking · MCP servers as third-party vendors · Shadow AI is an access problem not a traffic problem