Over the past few months banks and insurers we talk to have raised, in some form, the same question: does DORA apply to our AI agents? The short answer is “yes, it does”. The Digital Operational Resilience Act (Regulation (EU) 2022/2554) has applied since 17 January 2025 and does not mention AI once. However, it doesn’t need to. An agent is simply an “ICT system”, and every obligation in the regulation thus applies to it. The ESAs said as much in their 31 July 2026 statement on frontier AI: the framework “remains technology-neutral”, and asset inventories should include “AI/ML components”.

The more useful question is what the obligations look like when the ICT system is an agent. We give our own interpretation of DORA and the (technical) measures it requires, for three types of agents: agents you build yourself, agents you buy, and the (coding and productivity) agents you already use. At Kyvvu, we are not lawyers; so the post below is not legal advice. However, we have been building runtime controls for agents since early 2026, and hence we have some technical advice on dealing with DORA.

What DORA asks

DORA applies to twenty types of “financial entities” (Art. 2(1)): banks, payment institutions, investment firms, insurers, pension funds, crypto-asset service providers and so on. In the Netherlands, DNB and the AFM supervise. The regulation itself is fairly high level; much of the detail sits in a technical standard, the RTS on the ICT risk management framework (Delegated Regulation 2024/1774). Below, “DORA Art.” refers to the regulation and “RTS Art.” to that standard.

Reading both with agents in mind, we ended up with four things DORA asks that agents make harder. In our estimate of how much harder, most first:

  1. Least privilege, and no combinations that circumvent it. DORA Art. 9(4)(c) wants access limited “to what is required for legitimate and approved functions and activities only”. RTS Art. 21 adds “least privilege principles”, segregation of duties against “combinations of access rights that may be used to circumvent controls”, and accountability: “users are identifiable for the actions performed in the ICT systems at all times”.
  2. Independent approval of changes. DORA Art. 9(4)(e) wants every change “recorded, tested, assessed, approved, implemented and verified in a controlled manner”; RTS Art. 17(1)(b) wants the approver independent from whoever implements. RTS Art. 16 covers development, including (16(9)) systems “developed or managed by users outside the ICT function”.
  3. Logs, detection, incidents. RTS Art. 12 wants logs of “ICT operations, including ICT system activities”, protected “against tampering, deletion, and unauthorised access”. DORA Art. 10 wants anomalous activity detected, DORA Art. 17 wants incidents logged and their root cause found, and DORA Art. 19 wants major incidents reported. The RTS on incident reporting (2025/301, Art. 5) sets the clock: initial notification within four hours of classifying an incident as major (and no later than 24 hours after detection), intermediate report within 72 hours, final report with root cause within a month.
  4. Third parties. DORA Art. 28(1)(a): you remain “fully responsible” whatever you contract out. DORA Art. 28(3): a register of all ICT service contracts, critical or not. DORA Art. 30: mandatory contract terms, among them data location (30(2)(b)), incident assistance (30(2)(f)) and, for critical functions, audit rights (30(3)(e)) and an exit strategy (30(3)(f)).

There is more (yearly testing of critical systems under DORA Art. 24, TLPT under Art. 26, business continuity under Art. 11), but the four above are the most relevant to agents. The management body carries “the ultimate responsibility” for all of it (DORA Art. 5(2)(a)).

Why agents make the four requirements harder

All four requirements assume, as far as we can tell, that what a system can do is fixed when the system is designed: you grant rights to a known application, approve a change before it ships, log what the application does. An agent is different in one way: a model picks the next action at runtime, and the harness (the loop that turns model output into tool calls) executes whatever was picked, with whatever rights the agent holds. The rights are the outer bound; the actual sequence of actions is decided step by step, while the agent runs.

So least privilege on credentials bounds which actions are possible, but says nothing about their order, and RTS Art. 21(b) is about order: an agent that may read a customer file and may send e-mail holds a combination that circumvents the control. A line in the system prompt (“never e-mail customer data”) is a request to the model, not a restriction. Change approval covers the agent’s code, not the actions it will pick next week. And after an incident you need the actions the harness executed, not the text the model produced.

Three kinds of agents

Agents you build. A claims agent on LangGraph is an ICT asset like any other: into the inventory with its tools and the functions it supports (DORA Art. 8). The model API behind it is a third-party ICT service: into the register, with DORA Art. 30 terms, and for a critical function an exit strategy and a concentration assessment (DORA Art. 29). Most agents run on a handful of model providers, so that assessment is not a formality. (The first list of critical ICT providers, from November 2025, has Microsoft, Google Cloud and AWS on it, but no model-only provider.) At runtime you own the harness, so you own the controls: an identity per agent, a log per action, a way to stop the agent.

Agents you buy. The vendor is your ICT third party and the agent is the service. Responsibility stays with you (DORA Art. 28(1)(a)); what you can do moves into the contract. Data location (30(2)(b)) has to cover where the agent sends data at runtime, including the vendor’s model provider, which is a subcontractor. Incident assistance (30(2)(f)) has to include action logs: a vendor that logs only model inputs and outputs cannot tell you what was executed. And audit rights (30(3)(e)) should reach the controls on what the agent may do, not just the vendor’s certifications.

Coding and productivity agents. Claude Code, Cursor, Copilot and Codex in your developers’ terminals; a Copilot or ChatGPT subscription with connectors into mail and SharePoint. Nobody filed a procurement request for these, but each is a third-party ICT service (into the register, DORA Art. 28(3)). Beyond the register: a coding agent that writes, tests and merges its own change runs into RTS Art. 17(1)(b), unless a human approval step is enforced. It usually runs with the developer’s credentials (shell, git token, cloud CLI), which is privileged access under RTS Art. 21 and blurs who did what. A productivity agent sees whatever its user sees and sends it to a model hosted elsewhere (DORA Art. 9(2), 30(2)(b)). And an agent a business user builds in Copilot Studio is a system “developed or managed by users outside the ICT function” (RTS Art. 16(9)). None of this forbids these agents; it means the existing articles apply, and your ICT policies have to say how.

Where Kyvvu comes in

For each agent, the four requirements come down to two things. First, a control that decides at runtime, action by action, whether the agent may take the next step: the least privilege, the approval gate and the stop all have to happen before the action runs, not be discovered afterwards. Second, a record of what the agent then actually did, so you can show the control was in place and reconstruct an incident. Both have to sit in the harness, the component that executes every action. Credentials and contracts set the outer bounds but decide nothing per action; and a log of what the model said is not a log of what the harness did, which is the log DORA asks for.

The harness is where Kyvvu runs. We build an Agent Security Kernel: a policy engine inside the agent’s own process that sees every step the harness is about to execute, evaluates it against the history of the task so far (policies on paths), and returns allow, warn or block before the step runs, deterministically, with no model in the loop. The policies are yours, written as plain YAML manifests in your own git; we ship standard manifests (an OWASP agentic baseline among them) that cover the common cases out of the box.

  1. Least privilege over sequences. The standard manifests limit an agent to the tools it declared at registration; on top of that you write the path rules DORA’s segregation of duties needs, e.g. no external message after a read of customer data, no more than N write actions per task (rules reference).
  2. Independent approval. The standard manifests require a passed approval gate before code execution and deletes; you can extend that to deploys, merges or anything else, and require that one approval covers exactly one action.
  3. Logs and incidents. Because the engine sits in the harness, its trace is the full sequence of actions the harness executed, per agent and per task, recorded by the same component that enforced the policies, so every entry carries the policy decision taken on it. The trace is tamper-evident and goes to your own log platform; a warn or block becomes an incident with the whole task path behind it, which is what an incident report and a root-cause analysis need (incidents).
  4. Third parties. If you ask us, you should only run agents whose harness is Kyvvu-ready: the vendor ships the SDK (Apache 2.0, so nothing stops them) and the agent registers in your workspace. You assign the policies, and the trace and the incidents land with you, the same as for an agent you built. Written into the contract, the 30(2)(f) and 30(3)(e) clauses become something you can check rather than take on trust.

The same engine goes into your own agents through a decorator, a LangChain / LangGraph handler or the REST API, and into Claude Code through kyvvu-claude (other coding agents in progress). For each agent the platform shows which manifests are assigned, at which git commit, and when the agent last fetched them; audit reports (PDF or XML) summarise active policies, incidents and trace integrity (reports).

The engine makes no network call while evaluating, so no agent data goes to Kyvvu; and if our platform is down, agents keep enforcing their cached policies. Kyvvu is an ICT third party too, but a light one: the policies are YAML in your own git, and the code is on PyPI to inspect (SDK Apache 2.0, engine BSL 1.1).

The register, the contracts, TLPT and business continuity stay with you; the engine supplies evidence to them (registered agents and their tools, per-task traces, incident records), not the process. And, as with any reference monitor, the check covers the actions the harness integration brings under it, which is why we opened the vocabulary the engine evaluates as the Agent Action Grammar: so anyone can verify an integration is complete.

Whether a supervisor accepts a given control as meeting a given article is settled in your own control framework and your conversation with your supervisor (DNB or the AFM, in our case). For agents, the harness is where the evidence for that conversation comes from, whoever built the agent.

If you want to see the check in action: pip install kyvvu and kyvvu try gives you a local run with no account and a first policy block in under a minute; docs at docs.kyvvu.com. If you are working through DORA for your agents and want to talk it through, mail Jeroen at jeroen@kyvvu.com.