MCP Compliance Requirements for Financial Services Firms
Existing financial regulations apply to AI agents but weren't designed to handle them.
An emerging agent-connectivity standard turns AI agents loose on the systems that already run financial services: customer databases, trade ledgers, pricing engines, credit models. Anthropic introduced MCP in November 2024 as a standard way for AI assistants to plug into wherever data lives, and by late 2025 the ecosystem had grown to 97 million monthly SDK downloads with more than 18,000 servers listed on MCP Market. None of the rules built for this industry, SOX, GLBA, SEC cybersecurity requirements, FINRA supervision, were written with a machine that acts on its own, at machine speed, in mind. Every one of them still applies the moment an MCP tool call touches customer data, moves money, or writes to a record. Firms waiting for regulators to write MCP-specific rules aren't running a strategy. They're making a bad bet.
Start with what actually happens when an agent runs. An agent reading a customer's account history through an MCP tool call is a GLBA nonpublic personal information access event, full stop, and it needs the same safeguards, access controls, and logging any human-initiated access would need. An agent writing to a trade ledger or sending an order falls inside SOX books-and-records scope, and a missing trace of that action gets treated by examiners the same way a missing paper record would. An agent calling an outside API with customer data attached can trigger GLBA's third-party sharing obligations. Any agent whose output nudges a credit decision, a price, or an investment call lands inside SR 11-7 model risk territory. Regulators aren't waiting around for statutes tailored to this technology to catch up, either: the SEC and OCC are already examining AI governance practices, and FINRA's 2026 Annual Regulatory Oversight Report flags AI agents by name as an emerging supervisory concern inside its GenAI section.
The regulatory stack financial firms must map MCP against
Start with GLBA. The 2023 Safeguards Rule amendments require encryption, access controls, multi-factor authentication, and audit log retention for any system touching customer information, and that language covers AI agents pulling account data, transaction history, or credit profiles just as much as it covers a human employee doing the same thing. The catch is scale. GLBA's access controls have to apply to each discrete operation, because every tool call an agent makes constitutes its own access event. An agent calling an external API with customer data attached can raise GLBA data-sharing considerations too.
SOX is just as unforgiving. Every agent action that touches a ledger, a transaction, or a financial report needs a log that's both prompt and complete, because recordkeeping requirements apply regardless of whether a human or an automated process originated the action. The problem is that MCP agents often reason across several steps before producing an output, and those multi-step chains create attribution gaps: which tool call actually produced which result, and who signed off on it? If a firm can't answer that during an exam, the silence itself is the violation.
SR 11-7 adds another layer for anything touching a financial decision. Models that influence pricing, credit, or investment outcomes fall under model risk management requirements covering inventory, validation, monitoring, and governance. Sophistication doesn't buy an exemption here. An MCP agent calling a pricing or credit tool is in scope whether or not anyone on the compliance team thought of it as a "model."
FINRA's 2026 Annual Regulatory Oversight Report flags AI agents as an emerging supervisory concern, identifying risks around unauthorized action, scope creep, reasoning traceability, and data misuse. FINRA's prescribed approach reads like a checklist: narrow scope, explicit permissions, complete audit trails, human checkpoints before anything executes.
NYDFS Part 500 is among the more operationally detailed pieces of financial regulation touching AI governance, folding AI systems into covered institutions' cybersecurity programs, with a separate NYDFS industry letter issued in October 2024 addressing that scope. Firms with EU exposure carry an entirely separate clock. The EU AI Act entered into force on August 1, 2024, with prohibited-AI bans landing in February 2025, general-purpose AI model obligations arriving August 2, 2025, high-risk system requirements for standalone Annex III systems pushed to December 2027 under Regulation (EU) 2026/1744, and full applicability by August 2028. High-risk obligations cover areas including risk management, data governance, technical documentation, logging, transparency, human oversight, and cybersecurity requirements. Penalties run up to €35 million or 7% of global turnover for prohibited practices, €15 million or 3% for everything else.
None of the major governance frameworks were actually built for this, and firms need to stop treating them as if they were. NIST's AI Risk Management Framework, organized around Govern, Map, Measure, and Manage, has become the go-to standard across regulated industries, and NIST launched a dedicated initiative in February 2026 aimed specifically at autonomous-agent standards. The Cloud Security Alliance's AI Controls Matrix, released in July 2025, lays out 243 control objectives across 18 security domains and maps to ISO 42001, ISO 27001, NIST AI RMF 1.0, and BSI AIC4, which makes it a useful bridge between an existing compliance program and what MCP actually needs. But NIST AI RMF, ISO 42001, and the EU AI Act all predate agentic AI as a serious deployment pattern. None of them were built to handle cascading failures across chained tool calls, scope creep, or the attribution gaps unique to MCP. Firms have to stretch these frameworks to cover ground they weren't drawn for, and that stretch is exactly where the gap shows up.
Where MCP's architecture creates compliance exposure that traditional controls miss
Conventional application security assumes interfaces that are machine-checked and fixed in place. MCP breaks that assumption at the root: it puts natural-language tool descriptions directly into the control loop, so an agent's behavior gets decided at inference time by text that can be rewritten, disguised, or manipulated. That's a different kind of attack surface than anything a firewall or a static access list was built to catch.
Authentication is the most basic failure point, and the spec itself is to blame for it. MCP's OAuth 2.1 authorization framework does not enforce authentication as mandatory, and a July 2025 internet scan turned up at least 1,862 publicly reachable MCP instances answering unauthenticated requests. No authentication means no identity attached to a tool call, and no identity attached to a tool call means no audit trail that satisfies GLBA, SOX, or FINRA. That's not a minor gap. It's a missing foundation, and anyone treating it as a configuration detail to fix later has the priorities backwards.
The audit trail problem runs deeper than authentication alone. Multi-step agentic reasoning produces no built-in per-call attribution, meaning nobody automatically records which LLM decision triggered which tool with which parameters. FINRA's 2026 report calls out reasoning traceability gaps as a primary concern, and financial regulators already treat a missing trace as a recordkeeping violation in its own right. The absence of a log isn't a security weakness sitting next to the compliance problem. The absence of the log is the compliance problem.
Minimum-necessary access runs into trouble too. GLBA implies access should be scoped tightly, operation by operation, but most MCP servers expose broad tool sets with no per-tool permission layer sitting on top. An agent connected to a CRM's MCP server can often reach every customer record on that server, not just the ones relevant to its actual task. Scope, in other words, tends to default to "everything," not "only what's needed," and that default is the wrong one for a regulated firm to accept.
Then there's the rug pull problem. MCP has no cryptographic content-addressing or version pinning for tool descriptions, so a server that passed audit at one point in time can behave completely differently later, with no notice to anyone. Security researchers have found that MCP clients generally don't alert users or systems when a tool description changes after initial setup. For compliance, that's a real headache: the tool description an examiner reviews during an audit may bear no resemblance to what was actually running when an agent made a consequential decision months earlier.
Shadow usage compounds all of it. Governance is not keeping pace with adoption, plainly. Employees standing up their own MCP servers without looping in IT creates tool calls that are unlogged, ungoverned, and invisible to whatever compliance program exists on paper.
The MCP-specific attack classes that turn compliance gaps into active regulatory risk
This isn't theoretical. Between January and February 2026 alone, researchers filed over 30 CVEs against MCP servers, clients, and surrounding infrastructure, and as of May 2026 seven confirmed high- or critical-severity CVEs span major MCP-integrated platforms.
Tool poisoning, catalogued by OWASP as MCP03:2025, is the clearest example, and it's the one every compliance team should worry about first. Malicious instructions get embedded inside tool descriptions, parameter schemas, or even response content, and agents treat that content as trusted operational context because MCP has no built-in way to flag or block the injection. Invariant Labs demonstrated this in April 2025: a single poisoned tool description pulled out SSH private keys and local config files with zero user interaction. A related follow-up that same month showed the same technique pulling WhatsApp message history, and a separate GitHub MCP demonstration in May 2025 showed private repository exfiltration using the same underlying flaw. In controlled testing, poisoned tool calls have been found to succeed at high rates when agents had auto-approval switched on. For a financial firm, a poisoned call that pulls customer NPI is a GLBA breach outright; if it touches a trade record instead, it's a SOX event. And because the agent was following what it read as a legitimate instruction, the firm has no clean way to show the access was ever authorized.
Cross-server tool shadowing extends the same logic across a whole agent session. Invariant Labs's April 2025 research showed a malicious "random fact of the day" server embedding instructions aimed at a separate, legitimate WhatsApp server connected to the same session, and the agent pulled WhatsApp message history as a result. Translate that into financial services: a low-trust server, a calendar integration, a note-taking tool, can redirect an agent that's also connected to a high-trust system like a trading platform or customer data store. Research has recorded a 72.4% cascade rate once multiple servers in a session are compromised, which matters a lot for any firm running multi-server agent setups, and most do.
Session hijacking is its own category. CVE-2025-6515 lets a network attacker guess future MCP session IDs and hijack a legitimate client session, then feed back malicious responses through the oatpp-mcp server. CVE-2025-6514, found in the mcp-remote package, carries a CVSS score of 9.6 and affected a package downloaded more than 437,000 times before anyone disclosed the flaw. This one cuts at the heart of audit integrity: commands run inside a hijacked but authenticated session show up in logs looking exactly like legitimate, authorized actions. The audit trail stops being a compliance control and turns into false evidence instead.
Rug pull attacks close the loop. A server operator changes behavior after a firm's onboarding process already established trust, and there's no cryptographic tie between the tool description that got audited and what the server actually does at runtime. A server that IT and security signed off on six months ago might now be doing something entirely different, quietly, while the firm's compliance file still describes a tool that no longer exists in that form.
None of this is edge-case behavior, either. Endor Labs found 82% of file operations across the MCP implementations it studied were prone to path traversal, and Equixly found 43% of tested MCP servers vulnerable to command injection. That's baseline exposure, not a rare failure mode, and any firm treating these as tail risks is misreading the odds.
What compliant MCP deployment actually requires across authentication, authorization, and audit
Authentication has to be non-negotiable, full stop, no exceptions carved out for internal tools or "trusted" servers. Every MCP tool call needs to tie back to an authenticated identity. OAuth 2.1 already provides the framework; the fix is making its use mandatory rather than optional, which is how the spec currently leaves it. SSO integration keeps the identity behind a tool call lined up with the same identity governed by a firm's existing IAM policies and provisioning rules. SCIM provisioning matters just as much: when an employee leaves or changes roles, their agent credentials need to be pulled along with everything else, because an orphaned credential sitting on an MCP server is a GLBA access control failure waiting to be found during an exam. Just-in-time credential issuance, where an agent gets access scoped to a specific task and a specific window of time rather than standing access to a whole server's tool set, closes off a lot of that exposure before it starts. GLBA's MFA requirements for systems touching NPI need to be enforced down at the tool-call level, not just at the system login level.
Authorization needs the same granularity, and any firm setting permissions at the server level rather than the tool-call level has already lost the plot. Permissions belong on individual tool calls, because an agent cleared to read a customer's contact info shouldn't automatically be able to pull their full transaction history too. That means policy enforcement has to sit at tool-call depth, defining which agents can call which tools with which parameters, and checking that in real time as calls happen. FINRA's guidance calls for human checkpoints before any high-risk execution, things like transactions, data exports, or API calls carrying NPI, and for narrow, explicit provisioning: agents get access to the tools a specific workflow actually needs, not the full capability set a server happens to expose.
Audit logging is where most of the current gap lives, and it needs to be tamper-proof and granular down to the individual tool call: which tool got called, with what parameters, under which identity, at what time, and what came back. OpenTelemetry tracing gives firms the technical groundwork for putting together a full reasoning chain, tool call to model decision to output, which is exactly the kind of traceability SOX and FINRA are asking for. Retention periods have to match whatever framework applies, and a missing or incomplete log is the compliance failure itself, not a lesser issue sitting next to it. SR 11-7 model inventory records need updating whenever an MCP server's tool set changes, too, since a server that alters its tool descriptions has effectively changed the model's behavior and may need re-validation as a result.
None of this works if detection only happens after the fact, and firms betting on log review as their primary control are already behind. Tool poisoning, prompt injection, and gradual intent drift can't be caught by reviewing yesterday's logs, because by the time anyone reviews a poisoned tool call that pulled customer data, the GLBA breach already happened. Real-time detection built for these specific MCP threats, poisoning, injection, drift, exfiltration attempts, is what turns a detection system from a forensic tool into an actual preventive control. That gap, between finding out what happened and stopping it from happening, is the entire difference between a compliance program on paper and one that holds up under an exam.
