MCP Governance for Financial Services: 10 Controls for Banks

MCP governance is the set of policies and controls that decide which Model Context Protocol servers an AI system may connect to, what each tool can do, whose identity it acts under, and what evidence it leaves. Our view at HRTG: banks should govern every MCP server like a third-party integration.

The Model Context Protocol (MCP) has become the standard way to plug AI assistants and agents into enterprise systems. That is good news for builders. It is also a new control surface for banks. One configuration change can give an agent access to a ticketing system, a document store, or a CRM.

This guide is for bank technology, security, and risk leaders who need a practical MCP governance model now.

What is MCP governance?

MCP is an open protocol. An MCP client, such as an AI assistant or agent platform, connects to MCP servers. Each server exposes tools, data, or prompts from an underlying system. The protocol's authorization specification treats a protected MCP server as an OAuth resource server and the client as an OAuth client.

The protocol defines how connections are made. It does not decide which connections your bank should allow. That is the job of MCP governance. It answers four questions:

1. Which servers are approved, and who owns each one?
2. Which tools on each server are enabled, and for which users or agents?
3. Whose identity and permissions does each call run under?
4. What record exists of every call, and who reviews it?

Why does MCP governance matter more in financial services?

Banks cannot lean on model risk guidance here. The revised interagency guidance issued in April 2026, SR 26-2, places generative AI and agentic AI models outside its scope. It says an organization's own risk management and governance practices should set controls for tools outside its coverage. We covered what that means for agents in our agentic AI governance checklist for banks.

Third-party expectations still apply. The 2023 interagency guidance on third-party relationships expects banks to manage risk across the life cycle of each relationship, from planning and due diligence to ongoing monitoring and termination. A vendor-hosted MCP server that reads customer data or writes to a system of record fits that pattern.

The threat model is also specific. The OWASP MCP Top 10, currently in beta, lists risks such as tool poisoning, privilege escalation through scope creep, shadow MCP servers, and lack of audit and telemetry. Each one maps to a control a bank can own.

What does the MCP specification already require?

More than many teams realize. The current specification and its security best practices set firm rules:

• MCP clients must use resource indicators so each token names the specific MCP server it is meant for.
• MCP servers must validate that tokens were issued for them and must not accept tokens issued for other resources. The spec calls the forbidden pattern "token passthrough."
• MCP proxy servers must implement per-client consent to prevent confused deputy attacks.
• Clients that support one-click local server setup must show the exact command and get explicit user approval first.
• Scopes should start minimal and grow through step-up authorization, not broad grants up front.

These rules protect the connection. They do not tell you whether a given server should exist in your environment. A bank needs its own layer on top.

What MCP governance controls should a bank put in place?

We recommend ten controls, grouped by the four questions above.

A few notes on the controls that matter most.

Default to user-delegated access. AWS prescriptive guidance on MCP governance distinguishes machine-to-machine access from user-delegated access. It advises against propagating user credentials through the agent system and recommends scoped, purpose-built tokens and audience validation. For a bank, user-delegated access keeps an agent inside the same entitlements as the person using it.

Separate read tools from write tools. Many MCP servers expose both. Enable read tools broadly. Enable write tools only for named use cases, with confirmation.

Treat tool descriptions as code. The model reads tool descriptions to decide what to call. A changed description can change behavior. Review changes the way you review code.

How should MCP governance work in practice across system categories?

Risk varies by the system behind the server. A simple tiering helps:

• Knowledge and collaboration (for example Confluence, SharePoint, Slack, Google Drive): mostly read. Permission-aware retrieval is the main control.
• Work management and ITSM (for example Jira, ServiceNow, Asana): frequent writes. Confirmation and logging matter most.
• Customer and revenue systems (for example Salesforce, HubSpot, Dynamics 365): customer data. Due diligence and tight scopes come first.
• Core and financial systems (for example core banking, payments, general ledger platforms): highest risk. Most banks should keep these out of MCP until the controls above are proven.

Platforms can carry much of this load. Glean's MCP security documentation says its MCP server enforces source permissions on every call, lets admins choose which tools each server exposes, and keeps activity logs by server, tool, user, and date. Glean also lets admins connect remote MCP servers and enable each tool separately for agents or for conversational use. Those are useful controls. A bank still has to decide how to set them and keep the evidence. See our guide to governing Glean agents in a regulated bank.

Where should a bank start with MCP governance?

Start small and sequence it:

1. Week 1 to 2: Inventory every MCP client and server in use, including developer tools. Assign an owner to each.
2. Week 3 to 4: Set the allowlist. Turn off write tools that lack a named use case.
3. Month 2: Route vendor-hosted servers through third-party risk. Confirm logging reaches your security monitoring.
4. Quarterly: Review enabled tools, token settings, and usage against the register.

MCP governance also depends on context quality. An agent with perfect permissions can still act on stale or conflicting content. That is why we pair it with context engineering and an enterprise context layer.

Where does HRTG fit?

HRTG helps regulated organizations put Glean and agentic AI into production with governance a risk team can sign off on. Our Glean Readiness Assessment includes an MCP and connector inventory and a control gap review. Foundation sets permissions, admin roles, and logging. Activate and Operationalize add agents and MCP tools in tiers, with evidence built in. Optimize keeps the register and reviews current. We draw on delivery experience that includes a 250-user Glean pilot at a bank.

If you are deciding which MCP servers your bank should allow, use the form below to talk with our team.

FAQ

What is MCP governance? MCP governance is the set of policies and controls that define which Model Context Protocol servers an AI system may use, which tools are enabled, whose identity each call runs under, and how activity is logged and reviewed.

Does the MCP specification handle security on its own? It handles connection security. The specification requires audience-bound tokens and forbids token passthrough. It does not decide which servers or tools your organization should approve. That decision needs its own governance.

Is an MCP server a third-party relationship for a bank? Often, yes. A vendor-hosted MCP server that reads bank data or writes to bank systems fits the life-cycle approach in the 2023 interagency third-party guidance, including due diligence and ongoing monitoring.

Should AI agents use write tools through MCP? Only for named use cases, with scoped permissions, human confirmation, and full logging. Read-only tools are a safer place to start.

What is a shadow MCP server? A shadow MCP server is one connected without approval or oversight, often by a developer or a single team. OWASP lists shadow MCP servers among the top MCP risks. An owned register and a client allowlist are the main defenses.