DORA Compliance for AI Agents: What Financial Services Firms Must Govern Before Their Next ICT Audit

The Digital Operational Resilience Act predates production AI agents. Your next ICT audit will still treat them as ICT assets you have to govern.

DORA compliance for AI agents is not a separate regime. It is your existing ICT risk obligations applied to a new kind of ICT asset. The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied across the EU since 17 January 2025. An autonomous agent that executes transactions or reads customer data sits inside that scope.

DORA does not contain a separate AI-agent regime. Its ICT risk and resilience requirements apply through technology-agnostic concepts such as ICT assets, ICT services, and ICT-related incidents, because the text was drafted before agentic AI reached production. That silence is the trap. An audit will not ask whether you deployed an agent. It will ask whether the ICT asset behind a given business function is identified, governed, and recoverable. This article maps DORA onto agent deployments and shows where runtime AI agent governance controls fit.

What DORA Classifies as an ICT System (and Why AI Agents Qualify)

DORA governs ICT services and ICT assets, and it defines them broadly. Article 3(21) defines ICT services as digital and data services provided through ICT systems on an ongoing basis, and Recital 35 states that this definition should be read in a broad manner. An AI agent deployed as software within a financial entity's own systems can constitute an ICT asset under that scope.

Article 3(7) defines an ICT asset, and Article 8 requires financial entities to identify, classify, and document all ICT assets supporting their business functions. An agent that calls payment APIs or queries a customer database is such an asset. The model, the runtime, and the tool connections beneath it form the ICT service layer it depends on.

The classification does not turn on the label you give the software. It turns on function. If the agent supports a critical or important function, DORA's ICT risk obligations attach to it in the same way they attach to a core banking application.

The Three DORA Articles That Apply Directly to AI Agent Deployments

Three DORA provisions bear most directly on AI agents: Article 6, the ICT risk management framework; Article 8, identification of ICT assets; and Articles 28 to 30, ICT third-party risk. Read together, they require you to bring the agent inside your framework, register it as an asset, and govern the external services it depends on.

Article 6: bring the agent inside your ICT risk management framework

Article 6 requires an ICT risk management framework of strategies, policies, procedures, protocols, and tools that protect all information assets and ICT assets. An agent deployment is not exempt from it. The agent's permissions, its escalation paths, and its failure handling belong in the same framework as the rest of your ICT estate.

Article 8: identify, classify, and document the agent as an ICT asset

Article 8 requires you to identify and document the ICT assets supporting each business function. For an agent, that means recording what it can do, which systems it touches, what data it reads, and which function it serves. An unregistered agent is a common gap in the ICT asset register.

Articles 28 to 30: when the external model is an ICT third-party service

Where an external provider supplies the model or runtime as an ICT service on an ongoing basis, Articles 28 to 30 can apply. Article 28 sets the general principles for managing ICT third-party risk. Article 30 sets the contractual provisions your agreement with that provider must contain. Ongoing provision is part of the Article 3(21) test, so an external vendor is not the trigger on its own, and the financial entity remains responsible for the risk.

Mapping DORA Incident Classification to AI Agent Failure Modes

DORA classifies ICT-related incidents under Article 18 and requires major incidents to be reported under Article 19. The classification turns on impact criteria, not on whether a human or an agent caused the disruption. An agent failure that affects enough clients or downtime is a reportable ICT incident.

Article 17 sets the incident management process, Article 18 sets the classification criteria, and Article 19 sets the reporting duty. The Article 18 criteria include the number or relevance of clients or financial counterparts and transactions affected, whether the incident caused reputational impact, the duration and service downtime, geographical spread, data losses, the criticality of the services affected, and economic impact. RTS (EU) 2024/1772 sets the thresholds that separate major incidents from the rest.

The table below maps common agent failure modes to the Article 18 criteria they can trigger. It is an analytical mapping to aid classification, not a legal determination.

The point is that an agent incident is classified on the same axes as any ICT incident. If it is classified as major, the Article 19 reporting obligations and their deadlines apply, and you will need evidence of what the agent actually did.

How HALT and REQUIRE_APPROVAL Map to DORA Operational Continuity Controls

Article 11, Response and recovery, requires an ICT business continuity policy that keeps critical functions running and lets you respond to and contain ICT incidents. Two OpenBox governance decisions map onto that duty at agent runtime: HALT, which terminates an agent session, and REQUIRE_APPROVAL, which pauses an action for human sign-off. Both are designed to support Article 11 controls, not to determine compliance.

OpenBox evaluates each agent operation and returns one of four governance decisions: ALLOW, REQUIRE_APPROVAL, BLOCK, or HALT. Their precedence runs HALT then BLOCK then REQUIRE_APPROVAL then ALLOW. HALT terminates the entire agent session, which is the containment step Article 11 anticipates: the ability to stop a misbehaving agent without waiting for it to finish.

REQUIRE_APPROVAL pauses an operation for human review before it proceeds. Placed in front of a sensitive financial action, it is an authorisation gate: a person approves or rejects before value moves. That gives you a documented control point at the moment an agent reaches a high-risk step.

Reporting under Article 19 needs evidence, and so does the incident investigation that follows it. OpenBox signs each session's governance events into a tamper-evident proof certificate. The pipeline hashes each event with SHA-256 and combines the hashes in a Merkle tree. It then signs the tree's root with ECDSA NIST P-256 through AWS KMS by default, or through an external attestation endpoint such as a TEE or HSM. The certificate records the Merkle root, the signature, and the event count for the session, and its documented use cases include audit evidence and verifying that an incident timeline has not been altered.

The mapping below sets each provision against the OpenBox control designed to support it. DORA compliance is a regulatory determination; these controls are designed to support the obligations, not to guarantee an outcome.

What Your DORA ICT Auditor Will Ask About Your AI Agents

A DORA-minded audit approaches your agent as an ICT asset and works through the same questions asked of any critical system. Expect questions on registration, dependencies, containment, incident classification, third-party contracts, and evidence. The list below follows the provisions set out above.

• Is this agent in your ICT asset register, and which business function does it support? (Article 8)

• Which of your critical or important functions depend on it? (Article 11)

• Can you terminate its session immediately during an incident, and can you show that this was tested? (Article 11)

• How would an agent-caused disruption be classified, and against which thresholds? (Article 18)

• If the model is external, where is the ICT third-party contract and the register entry? (Articles 28 to 30)

• Can you produce tamper-evident evidence of what the agent did in a given session? (Articles 17 to 19)

DORA compliance for AI agents comes down to whether you can answer those questions with evidence rather than intent. Bringing agents inside your ICT risk framework, and keeping runtime records of every decision, is what turns a documentation exercise into continuous, verifiable compliance. OpenBox provides that runtime governance layer for AI agents: real-time monitoring, governance decisions, and tamper-evident audit trails designed to support the ICT obligations DORA places on financial firms. To see it against your own agents, book a call with the OpenBox team.

Frequently Asked Questions

Are AI agents that only make recommendations, not decisions, still covered by DORA?

Often yes. DORA scope follows function, not autonomy level. A recommendation agent can still fall within your ICT risk framework where it is an ICT asset or supports an ICT-supported business function of the financial entity. DORA does not create an exemption simply because a system advises rather than executes. What tends to change is incident classification, since a purely advisory agent may cause lower-impact incidents.

Does DORA require financial firms to test AI agent resilience the way they test ICT system resilience?

DORA requires testing across the ICT estate. Article 11 requires ICT business continuity and response and recovery plans to be tested at least yearly, and Articles 24 to 27 set the digital operational resilience testing programme. An agent supporting a critical function sits inside the ICT estate those tests cover, so its failure and containment behaviour should be in scope.

How does DORA's third-party ICT risk framework apply when the AI model is from an external vendor?

An externally hosted model that provides digital or data services on an ongoing basis is an ICT service under Article 3(21). That brings it within the third-party regime of Articles 28 to 30. Article 28 sets the general principles, and Article 30 sets the contractual terms your agreement must include. The financial entity remains responsible for the risk.

What constitutes an AI agent ICT incident under DORA classification?

An incident involving an AI agent may constitute an ICT-related incident under Article 3(8) where it meets DORA's definition: an unplanned event that compromises the security of network and information systems and adversely affects data or services. It is then assessed against the Article 18 criteria, including clients and transactions affected, reputational impact, duration and downtime, geographical spread, data losses, criticality of services, and economic impact. If it crosses the thresholds in RTS (EU) 2024/1772, it is a major incident reportable under Article 19.