Adopting MCP in a bank: the four risks to solve first

MCP standardizes how an agent connects to a tool; it does nothing to decide whether that agent should be allowed to. After months of looking at the Model Context Protocol through the eyes of a bank's architecture review, that is the sentence I keep coming back to. The protocol is good. It is also, by design, silent on most of the questions a regulator, an auditor or a model risk officer will ask.

That silence is not a flaw. A wire protocol should not encode a bank's risk appetite. But it means the work that matters most sits outside the spec, and teams that treat a working MCP connection as a finished integration are measuring the wrong thing. Here are the four areas I would resolve before any agent in a regulated institution gets a tool that can change anything.

Security: the attack surface is the tool description

Most security reviews start by asking whether the server is patched and authenticated. Those questions matter, but the more interesting risks live where traditional API review never looked. In April 2025, Invariant Labs described tool poisoning attacks, in which hidden instructions inside a tool's description steer the model while the user sees only a short, harmless tool name. The same research showed two variants that should worry anyone running a shared environment: a server that changes its tool description after the client approved it (a rug pull), and a malicious server whose description changes how the agent uses a different, trusted server.

The lesson for a bank is uncomfortable. Text that a model reads behaves like code, even if no engineer would call it that. The specification says as much: clients must treat tool annotations as untrusted unless they come from trusted servers, and a human should always be able to deny a tool call. Prompt injection sits at the top of the OWASP Top 10 for LLM Applications 2025, with excessive agency not far behind. In MCP those two risks meet.

My working rule is that tool metadata gets the same treatment as code. It is pinned, hashed and diffed on every change, and a changed description goes back through approval. Teams find this tedious until the first time a description changes underneath them.

Auditability: reconstruct the decision behind the call

Supervisors expect lineage, explainability and decisions you can defend after the fact. MCP gives you a clean record of the tool call: which tool, which arguments, what came back. That record is necessary and nowhere near sufficient. When an examiner asks why a customer's limit changed, the agent called update_limit is not an answer.

What you need is the chain around the call: the user request, the context the model saw, the policy version that permitted the action, the identity the agent acted under, and the human approval if one was required. Most of that lives in the host application, not the protocol. In my experience the teams that get this right design the audit record first and build the agent around it. Teams that bolt logging on later end up with mountains of tool traces and still cannot answer the examiner's question.

Privacy and residency: context is a data flow

Every time an agent pulls a customer record into its context window, that record has moved. It may have left a region, reached a third-party model provider, or landed in a log nobody classified. Banks already have strong rules for data minimization and purpose limitation. The gap is that agents create new, implicit data flows that existing controls never see.

The fix is mostly plumbing. Classify each MCP server by the highest sensitivity of data it can return. Filter or tokenize sensitive fields at the server, before they reach the model, instead of trusting a prompt to ignore them. Keep regional deployments of servers that touch regulated data, and record the model endpoint as a processor in your data maps. None of this is new. It has to be applied to a new kind of pipe.

Maturity: plan for a protocol that keeps moving

The protocol has changed a lot in a short time. The current authorization specification treats an MCP server as an OAuth 2.1 resource server, requires clients to bind each token to a specific server with a resource indicator, and forbids a server from passing the token it received through to downstream APIs. Those are exactly the controls a bank wants, and plenty of early servers predate them.

Registries help. The official MCP Registry, launched in preview in September 2025, is built so enterprises can run private sub-registries with the public catalog as their upstream source. That gives a bank a natural control point: assess public servers once, publish the approved ones internally, block everything else. Legacy integration, performance at enterprise scale and the upkeep of many small servers are still real costs. I budget for them as ongoing platform work, not a one-time project.

A worked example: onboarding one server

Abstract controls are easier to agree with than to apply, so here is how I would take a single MCP server from request to production. Suppose a team wants an agent to look up a customer's recent transactions to help service staff answer questions.

First, classify the server by the most sensitive thing it can return, which here is customer financial data. That one decision sets the rest: regional deployment, field-level masking for account numbers, and a model endpoint approved for that data class. Second, scope it to read-only, with a token bound to that server alone and no ability to pass it downstream. Third, pin the tool descriptions, hash them, and register the approved version in the internal registry so a later change triggers review instead of silently taking effect.

Fourth, write the audit record before the agent exists: who asked, under which identity, which policy version allowed it, what the model saw and what it returned. Then run it with a person reviewing every response for a defined period. Only when the record can answer a mock examiner's question end to end would I consider a second tool, and a write tool would go through the same steps again with a mandatory human approval in front of it. The pattern is slow for the first server and fast for the tenth, because the controls are reused.

Use the risk framework you already have

The mistake I see most often is a parallel governance track for agents. Banks already run model risk management, third-party risk management, data governance and change control. MCP adoption should plug into all four. A vendor's MCP server is a third-party component. An agent that makes or influences decisions belongs in the model inventory. A changed tool description is a change, and it goes through change control.

The NIST AI Risk Management Framework and its Generative AI Profile give engineers and risk partners a shared vocabulary built around govern, map, measure and manage. I use it less as a checklist and more as a translation layer, so that both sides mean the same thing when they say a control exists.

One sequencing rule has served me well. Start with read-only tools on low-sensitivity data, with a human approving every action. Widen scope only when the audit record proves you can reconstruct what happened. Autonomy is earned with evidence, one tool at a time.

“Architecture is not what you say you'll build; it's what you actually allow into production.”

The security concerns are real, and I think they are solvable with controls banks already know how to run. What I am still testing is where the line should sit between what a person must approve and what an agent may do alone. Where have you drawn that line for MCP tools in your organization, and what evidence moved it?