MCP Compliance Requirements for Financial Services Firms

Financial services firms are already running MCP in production, making the compliance gap active. The protocol has become the standard way to connect AI agents to tools and data, and senior technical leaders at these firms point to fraud detection and prevention, internal process automation, and code generation as the use cases pushing adoption forward right now. Firms that wait for a finished compliance playbook to arrive will find themselves behind the firms that are working through the regulatory questions today, while adoption across the sector still trails other industries and security sits at the top of the list of obstacles firms name. That gap between ambition and readiness puts firms in a bind: the competitive case for deploying agents is strong, but the governance work needed to deploy them safely isn't done. The National Security Agency's own guidance on MCP security confirms the protocol now shows up in experimental and production AI systems across business, finance, legal work, and software development. Regulators and national security bodies are watching this space closely. None of this is a future scenario to plan around. Agentic AI in financial services moved into production during 2026, and the compliance question that matters is no longer what these systems might someday do but how banks are governing what their agents are doing already. The rules that apply, FINRA's, the OCC's, GDPR's, were written before agents like these existed, and firms now have to work out how those rules apply to a technology their authors never saw coming.

MCP's Risk Profile in a Regulated Environment

MCP changes the basic trust relationship that conventional client-server software relies on, and that change opens attack surfaces that existing compliance controls were never built to catch. In a typical system, a client asks a server for data, and the server responds. The NSA's guidance points out that MCP often flips this: servers can query, and sometimes act on behalf of, the clients connected to them. That reversal means the systems firms already trust to request and receive information can instead be pushed to query and execute instructions, and nothing in the standard compliance toolkit was designed to trace that kind of path. Security Boulevard's analysis cuts to the core of it: MCP's danger isn't that it moves data, it's that it moves influence. A compromised MCP component doesn't just leak information. It can steer an agent's judgment, which is a different category of harm than a data breach and a different category of control failure to defend against.

The protocol gives structure to how agents, tools, and data sources talk to each other, but it doesn't guarantee that any of those interactions are legitimate. MCP's building blocks, clients, servers, proxies, hosts, can be set up with no required access controls at all, and the NSA notes that many real implementations skip authentication entirely. Layering agent autonomy on top of that compounds the risk. An agent can choose its own tools, chain multiple calls together, and act on whatever content it retrieves, and no person checks each step. So if a bad instruction gets injected early in a chain, it can travel through several more steps before anyone notices it. The architecture itself, not any single bug or bad actor, is where the compliance gap lives. That is why the four threat classes below deserve names and specifics.

The four MCP threat classes that map directly onto regulatory obligations

Four attack patterns specific to MCP produce the concrete harms financial regulators actually care about: data exfiltration, unauthorized access, falsified records, and unmanaged third-party exposure, and each one lines up with a different part of the regulatory stack firms already answer to.

Tool poisoning hides malicious instructions inside a tool's own metadata, its description, so an agent follows what looks like a normal instruction but actually executes an attacker's command. Researchers at NYIT tested seven major MCP clients and found that five of the seven had no static validation of server-provided metadata, and tool poisoning turned out to be the most common and most damaging client-side vulnerability they identified. For a broker-dealer, that matters directly: tool poisoning can corrupt the very records that SEC Rule 17a-4 and FINRA Rule 4511 require to be accurate and resistant to tampering.

Credential and token theft works by guiding an agent to pull and expose secrets, API keys, SSH keys, tokens, passwords, from files, environment variables, or secret stores the agent's tools can reach, which opens the door to account takeover or lateral movement across systems. For a bank, a stolen credential means unauthorized access to customer financial data, a direct violation of data protection requirements under banking privacy law, and if that credential reaches a vendor system, it becomes a third-party risk problem under OCC guidance too.

Confused Deputy attacks, sometimes called OAuth proxy attacks, arise because MCP servers are built to sit between an AI client and the resources downstream, brokering access on the client's behalf. When a server holds authorization tokens but doesn't check each individual request against what that token is actually allowed to do, unauthorized tool calls aren't some rare exploit, they're the expected outcome of the design. CoSAI's post-RSAC 2026 analysis frames this as the question everyone kept asking: the confused deputy isn't exotic when brokered access is the design. For compliance purposes, an agent using a token provisioned for one purpose to reach into a different resource falls squarely under the risk FINRA names as "scope and authority".

Supply chain attacks and server impersonation round out the list. Bad actors register MCP servers with names that closely resemble legitimate ones, and if a firm installs the impersonator, it can mislead an agent into invoking it, exposing data or executing commands the firm never authorized. An analysis of the broader MCP landscape calls this a structural risk: clients choose servers based on names and descriptions, which makes impersonation a natural and repeatable attack, not an edge case. From a compliance standpoint, an impersonated server is a vendor the firm never vetted, which is a direct hole in OCC's third-party risk management requirements.

Cato CTRL's proof-of-concept research makes these risks concrete. In their scenario, an attacker sends a financial analyst a document disguised as an audit report. The analyst's MCP setup allows file access and outbound data transmission, so when the analyst uploads the document to an AI system, it triggers a hidden malicious prompt that grants the attacker unauthorized access to financial records, opening the door to data exfiltration, altered reports, or ransomware. Cato CTRL built this scenario to illustrate their proof-of-concept findings, not to describe an event that actually took place.

FINRA's 2026 guidance names agentic AI risk for broker-dealers

FINRA's 2026 Annual Regulatory Oversight Report is the clearest sign yet that a major regulator is actively working out how existing rules apply to agentic AI, and the four risks it names line up almost exactly with the structural gaps MCP creates. The report, published December 9, 2025, gives dedicated treatment to agentic AI systems in broker-dealer workflows for the first time, and it builds on guidance FINRA had already issued on generative AI.

The report names four risk vectors, and each one maps onto a specific MCP weakness covered above. Autonomy means AI agents act without a person validating each step, and that lines up with MCP's session-level trust model, where an agent that authenticates once can call any tool for as long as that session lasts. Scope and authority means agents act beyond what a user actually intended or authorized, mapping directly to the Confused Deputy issue and the lack of per-call authorization checks described earlier. Auditability and transparency, meaning that complex, multi-step agent reasoning becomes hard to trace after the fact, corresponds to MCP-T12 in CoSAI's threat taxonomy, the category for insufficient logging, monitoring, and auditability. Data sensitivity, meaning agents that unintentionally store, disclose, or misuse sensitive information, connects to the credential theft and context injection risks described in the threat classes above.

The practical weight of this falls on recordkeeping. FINRA Rule 4511 and SEC Rule 17a-4 already demand tamper-evident, auditable records for every books-and-records obligation under the Securities Exchange Act and FINRA's own rules, and agent-generated records fall inside that scope. The 2026 guidance makes clear that broker-dealers can't treat anything an agent produces as sitting outside the recordkeeping perimeter. Firms that have put MCP into broker-dealer workflows without addressing autonomy, scope and authority, auditability, and data sensitivity are not approaching a future risk. They are already sitting in a supervisory gap today.

OCC third-party risk guidance when MCP servers are the third party

Every MCP server a firm connects to counts, under OCC's framework, as a third-party relationship requiring documented risk assessment, and the sheer number of MCP servers in circulation, combined with the supply chain weaknesses described above, makes that requirement hard to satisfy in practice. OCC guidance calls for documented due diligence, continuous monitoring, and clear contractual accountability for any third party whose activities carry risk or criticality to the bank, and the MCP ecosystem, including public registries that host thousands of community-maintained servers, fits that description without much debate.

Server impersonation through name collision, the same risk described in the threat classes section, means a firm can believe it has connected to a server it vetted while its data actually routes through one it never evaluated at all. OCC's third-party risk framework has no exemption for that kind of mistake. CoSAI's threat taxonomy treats supply chain and lifecycle security, labeled MCP-T11, as a core threat category covering how servers get provisioned, updated, and eventually retired, a lifecycle that lines up closely with what OCC's ongoing monitoring requirement already expects firms to track.

Most firms run into a basic, practical problem before they even get to documentation: they cannot produce a full list of which MCP servers are currently connected to their agentic systems, let alone the due diligence records OCC expects for each one. Building that inventory, and keeping it current, has to come before any serious due diligence effort can begin. There's a partial signal that some firms already sense this. A third of surveyed firms host their MCP servers mostly on-premises or in a private cloud, a rate well above the average across other industries, which suggests some firms are deliberately narrowing their third-party exposure through architecture. But hosting a server on-premises doesn't remove the supply chain risk that comes from the server's own code and dependencies, so it narrows exposure without closing the underlying gap.

GDPR's data minimization and purpose limitation principles and MCP's context assembly model

MCP's defining technical feature, the way agents pull from several data sources in real time to assemble the context they reason over, is in direct tension with GDPR's requirements around data minimization and purpose limitation. GDPR requires that personal data be collected only for purposes that are specified, explicit, and legitimate, and that it not be processed in ways that go beyond those purposes. When an MCP agent dynamically retrieves and bundles customer records, transaction histories, and policy documents into a single context payload, that bundling can easily exceed the scope of whatever consent the firm originally obtained.

Security Boulevard's analysis of context injection as a structural threat applies just as much to privacy as it does to security. If an agent retrieves a document containing personal data as part of building its context, that retrieval is itself a processing event under GDPR, and the firm needs a lawful basis to justify it. That's a different compliance posture than the one most firms are used to, where data processing happens in discrete, predictable steps that a privacy team can map in advance. MCP's context assembly happens dynamically, at the moment an agent decides it needs more information, which makes the processing harder to anticipate and document ahead of time.

FINRA's data sensitivity risk, agents that unintentionally store, disclose, or misuse sensitive information, has a direct parallel under GDPR. Agents that log or cache the context payloads they assemble, payloads that may contain personal data, create data retention obligations the firm may not have planned for or even noticed. If a firm hasn't accounted for how long those cached payloads persist, or where they're stored, it has a GDPR exposure sitting quietly inside its own AI infrastructure. Closing that gap starts with knowing, concretely, what an agent retrieves, why it retrieves it, and how long any of it sticks around after the task is done.