Since 17 January 2025, the Digital Operational Resilience Act applies to banks, insurers, investment firms, payment institutions and crypto-asset service providers across the EU. It is mostly discussed in terms of cloud contracts and incident reporting. It also applies, with no special carve-out, to the moment an analyst at a regulated firm connects an MCP server to Claude.

This post reads DORA’s five pillars against an MCP deployment and sets out what a financial entity needs in place before AI clients start calling tools. Not legal advice; a map for the conversation with your compliance function.

An MCP server is an ICT third-party service

DORA’s definition of ICT services is broad: digital and data services provided through ICT systems on an ongoing basis. A remote MCP server that your staff’s AI clients call to read positions, open tickets or query a data warehouse fits comfortably. So does the AI client vendor, and so does the model provider.

That has an immediate consequence under Chapter V. Financial entities must maintain a register of information covering all contractual arrangements on the use of ICT services provided by third-party providers, and report it to the competent authority on request. If employees connect MCP servers individually, the register is wrong the day after it was compiled, and nobody can say by how much.

The fix is structural: an enforced allow-list of approved servers, each with an owner, a contract reference, and a classification of whether it supports a critical or important function. The register of information becomes an export of that list rather than a quarterly archaeology exercise.

Pillar 1: ICT risk management

Chapter II requires an ICT risk management framework that identifies, protects, detects, responds and recovers. The MCP-specific parts of “identify” and “protect” are:

  • Identify which servers are connected, which tools they expose, and which of those tools can move money, alter records or send data outside the firm. The scanner gives the tool inventory and a first risk read per tool.
  • Protect through per-tool, per-role rules: trading-desk assistants cannot call settlement tools; a research agent cannot post to external channels. Write tools that touch client records or payments stay behind human approval.
  • Authentication per user via OAuth with minimal scopes. Shared API keys in config files are an identity and access management finding waiting to be written up.

Pillar 2: incident management and reporting

Chapter III requires detecting, classifying and reporting major ICT-related incidents, with tight initial notification windows. An AI client that was manipulated by a poisoned tool description into exfiltrating client data is an ICT-related incident. Classifying it requires knowing the number of clients affected, the data involved and the duration.

None of that is answerable without a central log of tool calls with arguments and outcomes. The observability post covers what the log should contain; the DORA-specific point is that it has to exist before the incident, be complete across all clients, and be retained long enough to support the final report.

Pillar 3: resilience testing

Chapter IV requires regular testing of ICT systems, up to threat-led penetration testing for larger entities. For MCP the obvious test is adversarial: can a crafted document, web page or ticket body cause a connected AI client to call a tool it shouldn’t? That is a cheap test to run against a staging gateway with the production policy, and it maps directly onto the OWASP MCP risks covered in this post.

A second test is continuity. If the model provider or the gateway is unavailable, what stops? If the answer includes a critical or important function, that dependency belongs in your resilience planning, with an exit strategy as Article 28 expects.

Pillar 4: third-party risk

This is where MCP bites hardest. Chapter V expects pre-contractual due diligence, contractual provisions covering data location, access and audit rights, and ongoing monitoring of each ICT third-party provider. Applied per MCP server, that means:

  1. Due diligence before connection. Who operates the endpoint? Is it really the vendor? What does a security scan show? Is it a community wrapper with no legal entity behind it?
  2. A contract. For a vendor’s official server, your existing agreement likely extends to it, but check that data location and sub-processor terms still hold when access is via the AI client. For a third-party connector, there is usually no contract at all, which under DORA is the end of the conversation for anything near a critical function.
  3. Ongoing monitoring. A server’s tool definitions can change after approval. Drift detection is the MCP form of monitoring a provider’s service.
  4. Concentration risk. If most of your AI tool access runs through one model provider and one gateway, that is a concentration to document and plan for, as it would be for a cloud provider.

Pillar 5: information sharing

DORA encourages sharing threat intelligence between financial entities. Poisoned servers, lookalike endpoints and injection patterns are exactly the kind of indicator that benefits from sharing. A central scan record per server makes it possible to contribute and to consume such intelligence without re-investigating each case by hand.

Where gate fits: gate is the chokepoint these pillars assume. Each workspace approves servers centrally, scans them before connection and re-checks tool definitions for drift, scopes servers and tools to teams with allow, ask, or block rules per client, and logs every call with arguments, outcome and a plain-language summary, exportable for the register and for incident reports. gate runs on EU infrastructure (Frankfurt). It is one ICT third-party provider in your register, and it is built to make the rest of the register accurate.

A sequence for a regulated firm

  1. Freeze ad-hoc MCP connections and inventory what exists. Classify each server by whether it touches a critical or important function.
  2. Build the allow-list with owner, contract reference and scan result per entry. Feed it into the register of information.
  3. Put every AI client behind one gateway endpoint so the list is enforced, not advisory.
  4. Apply per-tool rules: read-only by default, payments and client-record writes behind approval, outbound sends blocked for clients that hold sensitive reads.
  5. Run an injection test against the staging gateway with the production policy, and repeat on each policy change.
  6. Confirm the log retention and export path can support an incident report within DORA’s windows.

DORA does not mention MCP, agents or language models. It asks whether you know which third parties your systems talk to, under what terms, and what happened when something went wrong. MCP without a chokepoint makes all three unanswerable. With one, they are reports.