Something shifted in financial services technology in 2024, and most governance teams didn't catch it. Not because it was obscure. Because it arrived looking like a developer tool.
The Model Context Protocol (MCP) was published by Anthropic as an open standard for connecting AI agents to external data sources. When it launched, most of the industry filed it under "developer tooling" and moved on.
That was probably the right call at the time. It isn't now.
Eighteen months later, FactSet, MSCI, S&P Global, Bloomberg, LSEG, and others have all shipped MCP servers, with more following every quarter. A meaningful number of asset managers, hedge funds, and banks are running AI agents against licensed financial data through MCP connections — Claude, GPT-5.5, Gemini, and others — with different models being chosen for different use cases across the same firm. Some are in production. Others are close enough that the distinction barely matters.
The governance frameworks those firms built over the last decade were designed for people. MCP agents are not people, and the gap that creates is already sitting quietly inside a number of production deployments.
Why MCP is different from what came before
MCP agents have three properties that make them genuinely new from a governance perspective.
They are autonomous. An MCP-connected agent doesn't wait for a human to kick off a query. It decides what data it needs and fetches it, often running overnight workflows that touch three or four data providers before anyone arrives at the office.
They are high-frequency. A risk agent checking MSCI factor exposures every fifteen minutes across a large portfolio generates more data calls in a single day than a team of analysts produces in a month.
They are opaque by default. When a portfolio manager pulls a FactSet report, there's a session log, a user account, a timestamp. When a Claude agent calls FactSet via MCP, the record that exists is whatever the developer happened to build. In most cases, not much was built.
Those three things together — autonomy, frequency, and opacity — are what make MCP a governance problem in a way that previous AI tools were not.
Three gaps that are already open
This isn't a future risk. It's already the situation at a number of firms. They just haven't run the inventory to know it yet.
Licence exposure. Most data licence agreements restrict access to named users and approved applications. An AI agent is neither. In conversations with data and compliance leads across FSI, we consistently find agents querying licensed sources at volumes and for use cases the licence doesn't cover — not because anyone decided to breach the agreement, but because nobody checked whether the licence covered autonomous programmatic access before deploying.
The audit trail gap. Ask a compliance lead whether they can produce a complete record of every dataset their AI agents accessed in the past ninety days. In almost every case, they can't. The record either doesn't exist, or it wouldn't survive examination scrutiny. For firms preparing for FCA review, that's an open exposure.
Governance teams haven't been looped in. MCP adoption has mostly been driven by engineering and data science teams who found a genuinely useful tool and ran with it. Governance teams weren't excluded deliberately. MCP looked like an infrastructure decision, not a governance one. By the time compliance is aware of what's running, the agents are already in production.
The current workaround is entirely manual. Where compliance teams have tried to address this, the approach is typically a spreadsheet tracking which teams are using which data sources, quarterly reviews of licence agreements, and ad hoc log exports from individual integrations when an audit or examination approaches. It works — just about — when the number of agents is small and queries are infrequent. It doesn't work when you have a dozen agents running overnight across four data providers on two cloud environments. The manual process doesn't fail gracefully. It just stops keeping up.
The architecture is getting more complex, not less
Here is where the problem gets harder. A typical mid-size asset manager today is running four or five agents across two cloud environments against three or four data providers. Governing that manually is simply no longer possible. Most firms are not heading towards a single agent on a single cloud querying a single data provider. They are heading towards something considerably messier: multiple AI models chosen for different tasks, multiple MCP servers connecting to different data sources, and infrastructure spread across Snowflake, AWS, Azure, and on-premises environments simultaneously.
In that world, governance cannot live inside each individual integration. A compliance team cannot manually track which Claude agent is calling which FactSet dataset under which licence terms, while a separate GPT-5.5 agent queries MSCI under different terms on a different cloud. That approach does not scale to two agents, let alone twenty.
What firms actually need is a single entitlement layer that sits across the whole architecture — one place where entitlements are defined, enforced, and audited regardless of which model is running, which data provider is being queried, or which cloud the infrastructure lives on. A layer that grows with the deployment rather than requiring a new governance process for every new agent or provider.
The answer is a proxy layer that sits between your agents and your data providers, handling entitlement enforcement on every call — validating access, logging the audit trace, and blocking anything outside scope before it happens.
How Entitle AI helps
Claude Enterprise and OpenAI's enterprise tier both provide MCP governance controls — server allowlists, SSO, spend limits, and basic usage logging. Those controls answer the IT security question: which agent connected to which server.
They do not answer the FSI compliance question: was that connection within the firm's data licence terms, and can you prove it to an FCA examiner? Anthropic's own audit logs exclude MCP server names from log entries by default. Neither platform has any concept of commercial data licence agreements, permitted use cases, or dataset-level entitlement scope.
That is the specific gap Entitle AI closes.
Entitle AI is that proxy layer.
Most governance tools audit what happened. Entitle AI intercepts what's about to happen — before the data reaches the agent, before the breach occurs.
Our ProxyMCP Server sits between your agents and your licensed data providers, such as FactSet, MSCI and S&P, and does three things in real time, on every call.
It validates entitlements. Before any data reaches the agent, Entitle checks whether that agent is permitted to access that dataset under your current licence terms. Not just at the provider level — at the individual dataset level, reflecting the actual commercial terms of your agreements. If the access is out of scope, it's blocked before it happens.
It writes the audit trail. Every access event is logged as an OpenTelemetry trace: agent identity, data source, dataset, timestamp, intended use. The audit store sits inside your Snowflake account. No data egress. The records are structured specifically around FCA MAR Article 16 and BCBS 239 obligations, not just raw API logs.
It produces outputs your compliance team can use. Not data that requires engineering support to interpret — actual compliance reports, ready to share with legal, internal audit, or a regulator. A licence exposure report shows exactly which agents are accessing which datasets and whether each access is within scope.
Entitle AI is deployed as a Snowflake Native App, which means it runs inside your existing Snowflake environment. No new infrastructure, no data leaving your perimeter. For firms not on Snowflake, the ProxyMCP Server is available as a standalone container deployment on any cloud or on-premises environment.
The question worth asking this week
Before your next ExCo meeting, there's one question worth having an answer to:
Can I produce, on request, a complete record of every dataset our AI agents accessed in the past ninety days, broken down by agent identity, data source, timestamp, and licence scope?
If you can answer it confidently, your governance framework has kept pace. If the answer is "probably not" or "it would take us a while to pull that together" — that's the gap we help close.
If you already know you have a gap, we're running a 30-day pilot programme right now. We instrument your existing agent workflows, no production changes required, and deliver a live entitlement exposure report at the end. The report alone is worth the 30 days.