Beyond the inventory: governing AI agents under DORA

Governing human-mimicking AI agents under DORA is tough without central registers. Dr. Heiko Klarl, CEO, Nexis shares best practices for continuous identity control.

When a supervisory examiner reviews access controls under the EU’s Digital Operational Resilience Act, the regulation does not ask whether a person or a piece of software requested the transaction. It asks who authorised the access, whether that authorisation is documented, and whether it is subject to ongoing control. DORA defines obligations by the function performed, not by the nature of the actor performing it. An agent that reconciles payments, screens transactions, or edits vendor master data on behalf of a bank or payment institution carries the same regulatory weight as the staff member whose work it does.

That is a problem, because most financial entities are only now identifying which AI agents run in their environment: reconciliation bots, fraud-screening agents, customer service assistants with account access, procurement agents touching vendor master data. Organisations built or bought these tools function by function, without a central register of what exists, what each tool can reach, or who answers for it. That inventory work is necessary, and a growing number of institutions have started it.

But an inventory is a snapshot of what you have today. DORA and the operational resilience expectations behind it demand continuous, demonstrable control over what these agents are allowed to do, who is accountable when something goes wrong, and how conflicts of interest are prevented. Discovery answers what an institution has. Governance answers who is responsible, how compliance keeps reviewing it, and how it stops an agent from doing two things it should never do at once. Those are three separate problems, and each breaks in its own way once agents join the identity population alongside employees.

An inventory without an owner is a liability list

Every entitlement a human employee holds is supposed to trace back to a manager, a role, and a business justification. Extend that expectation to agents and the gaps show up quickly. An agent gets built by a development team, handed off to a business unit, and left running: nobody updates its access when the process changes, and nobody revokes it when the project that created it ends. What changes with AI agents is scale: a service account typically does one narrow thing, while an agent can be granted broad, adaptable access and use it differently from one task to the next.

The fix is unglamorous but non-negotiable: group agents by business function and put a named sponsor behind each group, someone who answers for its entitlements and policies the way a line manager answers for a subordinate’s access. Assign that ownership at deployment; do not retrofit it after an audit finding. Without it, an inventory is simply a longer list of things nobody is responsible for.

Ownership is only as good as the record behind it. For human roles, institutions already maintain structured governance documentation: application summaries, user structures, applicable regulations, risk assessments, and an IAM governance documentation that grades each entitlement by criticality, precisely what DORA and national regulations like BAIT and VAIT in Germany expect. Agents need the same record: IAM governance documentation, a risk classification, and a defined regulatory scope, tied to the owner who signs off on it. Without that record, no owner is meaningfully accountable.

Certify the rule set, not the roster

Financial institutions already run periodic access recertification for employees: a manager or compliance officer attests, on a schedule, that a given person’s access is still justified. That process barely survives contact with human headcount as it is. It cannot survive contact with an agent population that may outnumber employees several times over and whose permission footprint can shift with every new integration.

The answer is not to certify each agent individually, but to recertify the policy that governs each class of agent: what it may touch, under what constraints, reviewed and re-approved by compliance on a fixed cycle. Any agent instance under that policy inherits the review automatically, which turns an unmanageable per-instance workload into a bounded one. Instead of showing an examiner that you reviewed agent number 4,000, you show them the rule that governs every agent of that type. Reviewing rules rather than instances, drawn from the same governance documentation, is what makes recertification tractable once agents are counted alongside people.

Segregation of duties cannot stop at the org chart

Segregation of duties (SoD) is a foundational control in payments: the person who initiates a wire transfer cannot also be the one who approves it. Institutions designed that control for people sitting in defined roles. It breaks down the moment an agent performs one side of that transaction, or both.

Consider an agent that can both update vendor banking details and initiate payments to that vendor. Whether that combination of entitlements sits with one person, one agent, or is split across a human and an agent working in sequence, the conflict and the fraud risk are identical. Compliance teams built most SoD matrices with only human roles in mind, and few have gone back to add the equivalent conflict pairs for agents that now hold the same access. That is a blind spot, not a theoretical one: it is precisely the kind of gap an auditor or a fraud investigation will find first, because no one modelled it to include machine actors. Define and enforce SoD rules across the combined population of human and non-human identities; do not maintain them as two separate, unconnected control sets.

What examiners will expect to see

DORA’s technical standards will keep maturing, and NIS2 reinforces the same expectation from a network and information security angle. Neither will wait for the industry to finish its AI agent pilots first. Institutions that treat ownership assignment, up-to-date IAM governance documentation, policy-level recertification, and cross-identity segregation of duties as foundational controls, built alongside deployment rather than after an incident, will be the ones that can answer an examiner’s questions with evidence rather than explanation.

About the author

 

Dr. Heiko Klarl is the CEO of Nexis and a distinguished expert in Identity and Access Management (IAM) with more than 20 years of experience. With a strong background in cybersecurity, Heiko excels in structuring complex projects and leading high-performing teams. His ability to connect business and technology enables him to effectively address customer challenges.

Heiko is a regular speaker at conferences and publishes research and articles focused on IAM and cybersecurity.

 

 

About Nexis

 

Nexis delivers the leading Identity Visibility and Intelligence Platform (IVIP) that unifies identity-related data across IGA, PAM, and any kind of IAM system, spanning human and non-human identities and AI agent governance. The NEXIS Platform provides a unified view across the enterprise identity landscape for AI-driven analytics and real-time risk assessment, enabling automated remediation of identity security issues.