DORA expects financial entities to limit access to ICT and information assets to what each legitimate, approved function needs, using strong authentication, least privilege and regular review. An AI agent is an identity like any other: it needs its own credentials, permissions scoped to each capability, no access it cannot justify, and a place in every access review.
What does DORA require on access control, in plain words?
DORA (Regulation (EU) 2022/2554), which applies from 17 January 2025, requires financial entities to have an ICT risk management framework. Protection and prevention sit at its centre, and access control is a large part of that. In substance, financial entities must:
- limit physical and logical access to information and ICT assets to what is required for legitimate and approved functions and activities;
- grant access rights on need-to-know, need-to-use and least-privilege principles;
- use strong authentication mechanisms, based on recognised standards;
- manage identities across their lifecycle, from creation to removal;
- control and monitor privileged access more tightly;
- review access rights regularly and remove what is no longer needed;
- protect cryptographic keys and credentials.
The detailed technical standards under DORA set out these expectations more fully. For the regulation itself, see what DORA is.
Who does it apply to?
The financial entities within DORA's scope: banks, investment firms, payment and e-money institutions, insurers and reinsurers, crypto-asset service providers, trading venues and others, with proportionality for smaller and less complex entities.
The duties sit with the financial entity. If an agent runs on a vendor's platform, the entity must still make sure access is controlled, which means the contract must give it the right to set and verify the agent's permissions. That links to DORA contractual provisions for AI agent vendors.
What changes when the identity is an agent?
Access control was built for people and for service accounts that run fixed jobs. An agent is neither. It decides at runtime which tools to call and what data to read. That breaks three assumptions.
Permissions granted are permissions used. A person with broad read access usually looks only at what their task needs. An agent with broad access may read everything it can reach while trying to be helpful, or because an injected instruction told it to. Least privilege for agents must be tight, because the agent will use whatever it has.
Systems-level access is too coarse. Giving an agent write access to a payments API is a systems-level grant. What matters is which payments it can make, to whom and up to what amount. For agents, least privilege has to reach the action: this capability may initiate payments to existing beneficiaries up to the customer's limit, and nothing else.
Delegated access can exceed the delegator. An agent acting for a member of staff should never be able to do more than that person could. If the agent runs under a powerful service account, it can.
Our guide on how to give an AI agent least-privilege access covers the build, and the principle itself is defined in what least privilege is.
How do you meet DORA's access duties for agents?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Access limited to legitimate, approved functions | Each agent capability granted only the tools and data its approved task needs | Capability-to-permission map with approvals |
| Least privilege at the action | Every action checked against role scope, certificate, sources, the entity's limits and platform guardrails | Filed verdict per action, naming the deciding bound |
| Strong authentication | Agent identities use short-lived, scoped credentials, not shared passwords | Credential configuration and rotation records |
| Identity lifecycle | Agent identities created on approval and removed on retirement | Identity register reconciled to live agents |
| Privileged access control | Actions that move money or are hard to undo held for a named person | Held-action records with approver identity |
| Delegated access bounded | Agent acting for a user cannot exceed that user's rights | Permission checks recorded per action |
| Regular access review | Agent identities included in periodic access reviews | Review records with agents listed |
| Key and credential protection | Credentials held in a secrets store, never in prompts or agent memory | Secrets store audit logs |
The privileged access row is where human oversight and access control meet. Holding high-impact actions for a person is an oversight control under the EU AI Act, as discussed in EU AI Act human oversight, as a control, and a privileged access control under DORA.
What will a supervisor or auditor ask?
- List every agent identity with access to production systems.
- For this agent, what can it read, write and execute, and who approved each permission?
- How do you stop an agent doing more than the employee it acts for?
- Are agents in your last access review? What was removed?
- Where are the agent's credentials stored, and can the agent see them?
- What happens to an agent's access when it is retired?
What does DORA access control not cover?
It does not say how much autonomy an agent should have; that is a risk appetite decision. It does not address whether the agent's outputs are correct, which is a testing and validation question. It does not address data protection lawfulness, which sits with GDPR. And it does not replace contractual controls over the vendor's own staff access to your environment, which belongs in third-party risk. For the full set of DORA and AI Act controls, see AI agent regulation mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Where Pryme fits
Pryme grants authority per capability and checks every action against five bounds at the moment it is taken, so least privilege reaches the action, not just the system. Actions at depth 4 are held for a named person unless certified otherwise, and every verdict is filed with the bound that decided it.
Questions people ask
Should each agent have its own identity?
Yes. Shared service accounts make it impossible to tell which agent did what and to revoke one agent's access without affecting others. One identity per agent, with permissions per capability, is the workable minimum.
Can an agent hold a long-lived API key?
It should not. Short-lived, scoped credentials issued at runtime limit the damage if a key leaks or the agent is manipulated.
Do read-only agents need access reviews?
Yes. Read access to customer data is still access to information assets, and over-broad read access is a common source of data exposure.