How AI-agent tool calls fall under DORA’s ICT risk framework — what supervisors ask, where default setups fall short, and the controls that evidence the obligations.
QUICK ANSWERDORA has no AI carve-out. An agent calling tools is an ICT system the financial entity owns under Chapter II, and external MCP servers can be ICT third-party providers under Arts. 28–30. The recurring expectation: access limited to approved functions, attributable to a unique identity, and reconstructable for incident reporting.
DORA — Regulation (EU) 2022/2554, applying since 17 January 2025 — does not certify a protocol; it places obligations on EU financial entities and their ICT third-party providers. An external MCP server fits DORA’s broad definition of an ICT service: digital and data services delivered through ICT systems on an ongoing basis. Three things put agent traffic in scope.
A financial entity deploying agents owns that ICT risk under Chapter II, and the management body bears ultimate responsibility under Art. 5(2) — including the policy on use of ICT third-party services.
Externally-operated MCP servers and AI vendors serving a financial entity are ICT third-party providers — they belong in the register of information under Art. 28(3) with the mandatory contract clauses of Art. 30.
No regulator has issued MCP-specific guidance. But the supervisory direction (ESMA, the ESAs Joint Committee, the European Parliament’s Nov 2025 resolution) is consistent: agentic AI is ICT, and supervisors expect access control, traceability and human accountability.
The DORA articles MCP traffic is tested against. For each: what it requires, the question a supervisor asks of your AI traffic, the default-setup gap, and the gateway control that closes it. Access-control detail comes from RTS (EU) 2024/1774 identity-management and access-control provisions.
The management body defines, approves, oversees and bears ultimate responsibility for the ICT risk framework, including approving and periodically reviewing the policy on the use of ICT third-party services.
Can the board point to an approved, enforced policy over what agents may do across the third-party MCP estate?
Agent access is configured ad hoc in client configs — there is no single, board-reviewable artefact governing what agents may do.
A central, version-controlled policy: one artefact the management body can approve and periodically review, enforced on every call.
31,002 tools across 4,628 servers is what the board is implicitly accountable for.
Logical access is limited to what is required for legitimate and approved functions only, with sound administration of access rights, strong authentication and cryptographic-key protection. RTS Arts. 20–21 spell out unique identity per person and system, least privilege and need-to-use, segregation of duties, individual accountability, privileged access on a need-to-use basis, withdrawal on termination, and reviews at least every six months for systems supporting critical or important functions.
Is each agent acting under a uniquely identified, least-privilege grant — or a broad shared credential?
Broad service tokens: the access is unattributable, unbounded and unreviewable, with shared accounts standing in for individual identity.
Per-person scoped grants give a unique identity and least privilege; per-call policy evaluation enforces need-to-use on every call; central credential custody protects the keys; argument conditions act as call-level segregation of duties.
1,773 destructive + 1,649 execute + 7,607 write + 154 financial tools = the critical-function surface RTS Art. 21 targets; a flat credential grants all of it.
Mechanisms to promptly detect anomalous activities, with multiple layers of control and defined alert thresholds and criteria that trigger incident-response processes, including automatic alerts. The RTS requires tamper-protected logs of logical access and identity management, detailed enough for anomaly detection.
Would you notice an agent calling a tool it never calls, or a spike in destructive calls?
Traffic terminates at the upstream servers — there is no consolidated, tamper-protected record to detect anomalies against.
One chokepoint logs every call; rate limits and policy verdicts function as defined alert thresholds; a deny verdict is the automatic signal.
With 1,773 destructive tools in the estate, “anomalous” is concrete.
A business-continuity policy and ICT response and recovery plans to contain incidents and restore operations.
When an agent or upstream server misbehaves, can you contain it immediately?
Containment means rotating shared credentials or editing every client config — slow, and never clean.
Revoke a grant or flip a policy to deny for instant containment; the audit log feeds the post-incident review.
A central kill-switch across 4,628 servers, versus per-client credential rotation.
Detect, manage, log, categorise and classify ICT-related incidents; major incidents reach the management body and are classified against criteria such as clients affected, geographic spread, data losses, duration and economic impact; major incidents are reported to the competent authority on the DORA initial / intermediate / final reporting cadence.
If an agent triggers an incident, can you reconstruct what happened fast enough to classify and report it?
With no per-call record, scope and root cause are unknowable inside the reporting window.
The audit log captures the grant, tool, argument keys, deciding rule and verdict — the raw material for classification and the report’s root-cause section.
154 financial + 1,773 destructive tools are the calls most likely to cross materiality thresholds.
A register of information on all contractual arrangements (Art. 28(3)); exit strategies (Art. 28(8)); concentration-risk assessment (Art. 29); mandatory clauses (Art. 30) covering SLAs, data-processing locations, access, recovery and return on termination, cooperation with authorities, termination rights, and unrestricted rights of access, inspection and audit with ongoing performance monitoring.
Do you have an accurate register of every MCP server your agents touch, and can you exercise audit and termination rights over them?
Servers are added in client configs with no inventory, no contracts and no enforced exit.
The upstream registry feeds the register of information; central custody makes termination a single revoke; the log evidences the entity exercising its monitoring right.
4,628 catalogued servers — the scale of the estate to register.
A digital operational resilience testing programme for all in-scope entities, with selected larger or critical entities also performing threat-led penetration testing (Arts. 26–27), and Art. 30 requiring providers to cooperate in it.
Can you exercise agent-tool paths under test, and scope provider participation in it?
With traffic scattered across direct client-to-server connections there is no single surface to instrument or test against.
A single instrumented surface to exercise agent-tool paths and scope provider participation in threat-led testing.
Illustrative policies — not complete compliance controls on their own.
Read tools are allowed; privileged tools stay denied by default — the unique-identity, need-to-use, least-privilege posture RTS Art. 21 targets. Each denied attempt is itself a tamper-protected access record.
{
"version": "1",
"default": "deny",
"tools": {
"list_accounts": {},
"get_account": {},
"list_transactions": {}
}
} Payment lookups run; transfers above a threshold do not. The deny verdict lands in the audit log with the deciding rule — the raw material for incident classification.
{
"version": "1",
"default": "deny",
"tools": {
"get_payment": {},
"transfer_funds": {
"deny_if": [
{
"conditions": [
{ "path": "args.amount", "op": "gt", "value": 10000 }
]
}
]
}
}
} See Writing policies for the policy format, operators, and quota shapes.
DORA looks for traceability — governance to control to execution to recorded proof — sustained over time. The artefacts a gateway deployment hands over for the obligations above:
| What the auditor asks for | What the gateway exports |
|---|---|
| Register-of-information entries in the ESAs’ data model (providers, functions, criticality flags — first cycle April 2025) | The upstream server registry populates the technical fields: provider, the function each server supports, and risk classification. |
| Access-rights reviews evidencing least privilege and the six-monthly review for critical-function systems (Art. 9 / RTS Art. 21) | Exportable grant roster — every identity, its scoped tool set, issue date and last review — alongside the enforced policy. |
| Tamper-protected incident logs sufficient to classify and report (Arts. 17–19) | The per-call audit log: grant, tool, argument keys, deciding rule and verdict. |
| Art. 30 contract-clause evidence — audit and access rights, termination, TLPT cooperation | The gateway demonstrates the entity exercising its monitoring and access rights over actual usage, per server. |
| Management-body oversight of the ICT third-party policy (Art. 5) | The central, version-controlled policy with its approval and review history. |
Yes — indirectly but firmly. An agent is an ICT system, and the financial entity owns that risk under Chapter II, with the management body ultimately responsible under Art. 5(2). Supervisors treat AI as ICT with no carve-out, emphasising access control, traceability and human accountability.
External ones serving a financial entity are. DORA defines ICT services broadly — digital and data services delivered through ICT systems on an ongoing basis — so a vendor-operated MCP server fits. That puts it in the register of information under Art. 28(3) with the Art. 30 contract clauses, and the most systemic providers can be designated critical.
Access limited to what is required for legitimate, approved functions. RTS (EU) 2024/1774 spells it out in Arts. 20–21: a unique identity per person and system, least privilege and need-to-use, segregation of duties, no anonymous shared accounts, privileged access on a need-to-use basis, reviews at least every six months for critical-function systems, and strong authentication for privileged access. A flat shared agent credential fails all of these.
They can. An agent-caused ICT incident that crosses the materiality thresholds is a major incident and must be reported to the competent authority on the DORA initial / intermediate / final reporting cadence. You can only classify it inside that window if you hold call-level records of what the agent did.
It depends on your entity type. DORA covers around twenty categories, including investment firms, payment and e-money institutions, crypto-asset service providers, insurers and fund managers. And if you supply ICT services to such firms, you may be the third-party provider they have to register and contract under Arts. 28–30.
| Default setup | Through the gateway |
|---|---|
| One shared upstream API key on every laptop | Per-person scoped grant tokens, revocable individually |
| No record of what agents called | Per-call audit log: grant, tool, argument keys, rule, verdict |
| Every tool on a server is callable | Deny-by-default — each tool and argument explicitly granted |
| Access rules scattered across client configs | One central, version-controlled policy |
PolicyLayer doesn’t certify your organisation — it gives your compliance team enforceable controls and exportable evidence for the MCP slice of the audit.
Last reviewed 04-06-2026 by the PolicyLayer research team. This guide maps how the framework intersects with MCP deployments — it is not legal advice.
Per-person grants, deny-by-default policy and a per-call audit log — the DORA evidence for the MCP slice of your programme. Live in minutes.
Free to start. No card required.
4,600+ MCP servers and 31,000+ tools scanned and risk-classified.