What DORA is
DORA, Regulation (EU) 2022/2554, is the EU’s framework for the ICT risk of the financial sector. It entered into force on 16 January 2023 and has applied since 17 January 2025. It reaches more than 20 types of financial entity, including banks, insurers and investment firms, and brings critical ICT third-party providers under direct oversight by the European Supervisory Authorities.
DORA does not mention AI agents. It sets requirements in five areas: ICT risk management, ICT-related incident management and reporting, digital operational resilience testing, ICT third-party risk, and information sharing on cyber threats. An AI agent that acts on a financial entity’s systems is an ICT system inside the first four, and the entity is responsible for it whoever built it.
This page maps requirements to agent controls only where the mapping is plain. It is not legal advice.
ICT risk management is owned at the top
Article 5 requires each financial entity to have an internal governance and control framework that ensures effective and prudent management of ICT risk. The management body defines, approves and oversees the arrangements and bears ultimate responsibility for managing ICT risk, including approving the policy on ICT third-party arrangements.
The consequence for agents is that they cannot sit outside that framework as a team-level experiment. If the management body is responsible for ICT risk, it has to be able to see which agents exist, what they reach, and under what policy. An inventory built from real calls, including agents nobody registered, is the starting point.
Access limited to approved functions, strong authentication, protected keys
Article 9 sets out protection and prevention. Under Article 9(4) financial entities must implement policies that limit physical or logical access to information assets and ICT assets to what is required for legitimate and approved functions and activities only, with a set of policies, procedures and controls that address access rights, and implement strong authentication mechanisms and protection measures for cryptographic keys.
Three controls follow.
Least privilege per action. An agent that inherits broad access from a service account handed to it on day one does not meet “legitimate and approved functions and activities only”. The decision has to be per action and per target.
Verified identity. A header string is not strong authentication. Each agent needs an identity your identity provider verifies, and for high-risk agents a workload identity rather than a name it asserts about itself.
Key custody. The keys that protect downstream credentials belong in the entity’s own vault or key service, and a governing platform should be a user of them, not a custodian.
Every incident recorded, major incidents reported
Article 17 requires an ICT-related incident management process to detect, manage and notify incidents. Financial entities must record all ICT-related incidents and significant cyber threats, and their procedures must identify, track, log, categorise and classify incidents by priority and severity, ensure root causes are identified and documented, and report major incidents to senior management and the management body.
Article 19 requires major ICT-related incidents to be reported to the competent authority through an initial notification, intermediate reports, and a final report once root cause analysis is complete.
An agent incident is an ICT incident. Two things make it harder. Agents chain into other agents, so the root cause may be three hops back from the system where the outcome landed. And most application logs show a service account touching a system, not which agent, on whose authority, following which request.
What this asks for is a record of every agent call with the identity, the authority, the decision and the outcome, kept so the chain can be reconstructed for the final report, and tamper-evident so the record itself is not in question.
Article 17 also asks for early warning indicators. Out-of-pattern behaviour, a burst of calls, new systems, a run of refusals, a credential where it should not be, is an indicator that can be raised while the agent is still running.
Third parties do not carry your responsibility
Article 28(1) is the sentence that decides most vendor conversations. Financial entities that have in place contractual arrangements for the use of ICT services to run their business operations shall, at all times, remain fully responsible for compliance with, and the discharge of, all obligations under DORA and applicable financial services law. The management body must adopt and regularly review a strategy on ICT third-party risk.
Agents arrive from vendors, partners and licensed platforms. Under DORA their actions on the entity’s systems are the entity’s responsibility. A vendor’s agent has to present an identity the entity can verify, be governed by the entity’s policy, be stoppable by the entity, and leave a record the entity holds. Governance that lives inside the vendor’s product does not satisfy the entity’s obligation.
What is not mapped here
DORA’s resilience testing programme and information-sharing arrangements are not mapped to agent controls on this page; they are testing and sharing questions rather than controls in the call path.
The incident reporting clock
An incident an agent causes, or takes part in, is reported like any other. Under Commission Delegated Regulation (EU) 2025/301, the initial notification of a major ICT-related incident is due within four hours of classifying it as major and no later than 24 hours after the entity became aware of it. The intermediate report follows within 72 hours of the initial notification, and the final report within one month of the latest intermediate report. Meeting those deadlines depends on a record that already shows which agent did what, on whose authority.
Where KPATH sits
KPATH is the inline enforcement layer for enterprise AI agents. Every governed call passes through its Policy Enforcement Point before the payload reaches the target. It verifies the agent’s identity and, where policy requires, the person it acts for; applies least-privilege policy per action, budgets and inline human approval; can stop one agent or the whole in-flight chain; and writes a signed, tamper-evident record of who acted and what was decided to your SIEM, verifiable by an auditor without trusting KPATH.
Credentials are encrypted under a key in your own vault or key service. KPATH governs the request envelope and reads only the payload values you declare for a rule. A vendor’s agent is governed on the same terms as one your team built. It runs self-hosted, in your VPC, on-prem or air-gapped, with a failure behaviour you decide in advance.
Start in monitor mode: observe only, enforce no policy, rewrite no agents. Then set policy and flip to enforce by repointing egress.