Financial firms spent most of 2025 standing up their DORA programs. Access reviews, incident reporting, third-party registers, resilience testing. Then 2026 arrived and the same firms started moving AI agents out of pilots and into production. Those two efforts meet in a place most DORA readiness work never mapped, which is what an agent is actually allowed to do once it is running.
DORA does not mention AI agents once. It does not need to. Its access and resilience obligations already cover them, and that is the piece to get right before your agents start calling internal tools on their own.
I spend most of my time with security and identity teams in regulated industries, and the agent question tends to land in the same spot every time, which is the space between proving who an identity is and controlling what it can actually do.
Authentication vs authorization for AI agents under DORA
Most financial entities have the identity side of this in good shape. Entra, Okta, CyberArk, and the rest answer two questions well. Who is this identity, and is it allowed to hold this credential. That work maps cleanly onto DORA's language around strong authentication and controlled access provisioning, and it is where most programs have spent their budget.
The question that stack does not answer sits one layer down. For this specific call, right now, given the human behind this agent and the data it is reaching for, should this action go through. That is authorization, and it is a different decision from identity.
Authentication tells you the agent is who it claims to be. It says nothing about whether this particular action is one the agent should be permitted to take at this moment.
DORA is explicit that this second question is in scope. Article 9(4)(c) requires financial entities to limit logical access to information and ICT assets to what is required for legitimate and approved functions only. That is least privilege written as a legal obligation, and least privilege is an authorization control, not an authentication one.
A vaulted, strongly authenticated credential that can still do far more than the task in front of it fails that test, no matter how well the identity was proven.
Why AI agents are already in scope for DORA
DORA applies to financial entities and the systems they run, not only to the people using them. An AI agent that calls an internal API to read a position, move data between services, or trigger a workflow is an ICT asset acting inside a financial process. It comes into scope the moment it touches that process. There is no separate AI clause to wait for.
Two things make this urgent. The first is scale. Machine identities already outnumber human ones by 109 to 1 inside the average organization, up from 82 to 1 the year before, according to CyberArk's Identity Security Landscape report. Agents add to that population, and unlike a static service account, an agent's next action is not fixed in advance. It decides at runtime what to call, which is exactly the behavior least-privilege controls are meant to bound.
The second is timing. AI deployment across financial services keeps accelerating through 2026, as the Cambridge Centre for Alternative Finance tracked in its 2026 global report on AI in the sector, and agentic systems are the fast-moving edge of it. So the population of things making access decisions on your behalf is growing quickly, at the same time your DORA obligations around access management, logging, and operational resilience already apply to every one of them.
What runtime authorization for AI agents actually means
The fix is to take the access decision out of the agent and put it somewhere you can govern. Every time an agent tries to call a tool or reach a piece of data, that request becomes a policy check evaluated by a separate engine before anything runs. In the standard pattern this is a policy enforcement point sitting in front of the action and a policy decision point making the call, the same PEP and PDP model used for human access.
This matters because the alternative is to write the rules into the agent itself, in its prompt or its framework config. Rules embedded there are probabilistic. The agent can be argued out of them, and a security team cannot version, test, or prove them. Moving the decision outside the agent turns it into something legible. One place to see what every identity can access, one change-management trail, and the ability to revoke in seconds rather than chase down keys.
It is also distinct from what a privileged access manager does. Vaulting takes custody of the credential. It governs who can check the key out. It does not evaluate what that key is allowed to do on each individual call once the agent is holding it. Because an agent carries the context of the human who set it running, an externalized decision can weigh both the agent and the human behind it in a single check, which is the part neither authentication nor vaulting was built to do.
How runtime authorization maps to DORA obligations
Runtime authorization lines up with the obligations DORA already names. Least privilege under Article 9 becomes a policy that grants the minimum scope needed for the specific call, rather than one broad API key issued per agent class. Strong authentication paired with dedicated control systems becomes authorization treated as its own control system, not a set of rules scattered through application code.
Audit is the other half of it. DORA's ICT risk framework expects you to reconstruct what happened and show that access decisions were intentional and controlled. When every agent-to-tool call runs through a policy engine, every one of them produces a record. Which human was behind the agent, what it asked to do, whether the request was allowed or denied, and which rule decided. When a regulator or an internal auditor asks you to account for an agent's action, you can show the decision and its reasoning, not just a service account line in a log that says something happened. That is the difference between describing your controls and proving they ran.
None of this makes an organization DORA compliant on its own. Compliance is a program, not a single control, and authorization sits alongside incident reporting, third-party risk, and resilience testing rather than replacing any of them. What runtime authorization does is cover one obligation DORA clearly names, and do it in a way that also produces the evidence you need when someone asks you to prove it was working.
How to prepare AI agent authorization for DORA
The work is more tractable now than it will be once agents are everywhere.
Start by finding them. Inventory the non-human identities and agents already running, including the ones a team stood up without telling security.
Give each agent a named human sponsor whose status governs the agent's lifecycle, so an agent is never running on behalf of nobody.
Move the authorization decision out of the agent and into an external engine, so the rules live somewhere you can govern centrally.
Wire the audit chain so the sponsor, the purpose, and the policy decision travel with every call.
Then test fail-closed behavior, because an authorization layer that fails open when it cannot be reached is not a control, it is a gap waiting for its worst day.
For firms where public or hosted tools are not permitted, and that describes most of the larger banks, the decision engine can run inside your own infrastructure. Policies, decision logs, and audit trails stay where your data residency and DORA obligations require them to stay, which is often the deciding factor for a G-SIB choosing between deployment models.
Where runtime authorization for AI agents goes next
Agents scale further in the second half of 2026, and the gap between authenticating an identity and authorizing its actions gets wider as they do. Expect a wave of products relabeling existing privileged access or API gateway tooling as agent authorization. The signal to watch is whether the access decision is genuinely decoupled from the agent and expressed as policy you can read and test, or whether it is the same perimeter control with a new name on the box.
The direction of travel is already visible in the standards. Externalized authorization now has a shared interface in OpenID AuthZEN, a working group I co-chair, and its specification was ratified in January 2026. Agreeing on a common way to ask for an authorization decision is a good sign the industry treats the decision layer as its own concern, rather than something to bury back inside each application or agent.
DORA did not create this requirement for AI. It set the standard for ICT access management and operational resilience, and agents walked straight into scope. Getting the authorization layer right is the work. The regulation just made the deadline for doing it something other than optional.
Try Cerbos to see how externalized authorization works across human and non-human identities, or book a call to talk through your agent architecture with our team.
Go deeper:
FAQ
Tagged in
