Mapping AI Governance to EU AI Act with ATCP

Three EU regimes, different scopes, one underlying demand: prove that an automated action stayed inside the authority a human granted it. Here is the honest mapping and the line where a control layer stops and your compliance programme begins.

[embed]

The clocks are already running. DORA has applied to financial entities since 17 January 2025. NIS2’s national transposition has been underway since the October 2024 deadline. And the EU AI Act’s obligations for deployers of high-risk AI systems Article 26 become binding on 2 August 2026 (a 2025 proposal to delay some high-risk dates to late 2027 exists but has not been enacted, so August 2026 is the date to plan against).

These three instruments were written for different reasons by different parts of Brussels. But when you read them as an operator of AI agents, they rhyme. Each one, in its own language, asks four things of anything that acts on your systems:

1. A named human is accountable for the action.
2. Access is least-privilege limited to what was actually approved.
3. You can intervene suspend or stop the actor in real time.
4. You can produce a tamper-evident record of what happened.

The trouble is that all three were drafted around a human actor with a login and a session, overseen by other humans, leaving human-shaped logs. An autonomous AI agent is a different animal: it acts continuously, at machine speed, it is not a natural person, and it can be subverted by prompt injection into doing something its operator never intended. Traditional IAM was not built to answer the one question every auditor will eventually ask who authorised this agent, what exactly was it allowed to do, and can you prove it?

That question is what ATCP is built to answer. Here is how its controls and evidence map onto each regime.

EU AI Act, Article 26 (deployers of high-risk AI)

Article 26 is the operational core for organisations that use high-risk AI. It requires deployers to use the system per the provider’s instructions (26(1)) to assign human oversight to a competent person with the authority to intervene (26(2), reinforced by the Article 14 oversight design, including the ability to interrupt the system) to monitor operation and suspend use where a risk is identified (26(5)) and to retain the automatically generated logs for at least six months with financial institutions keeping them as part of their financial-services documentation (26(6)).

Where ATCP maps:

• Human oversight (26(2), Art. 14). The signed mandate is the oversight decision, cryptographically bound to a named, authenticated human who chose the scope, budget, constraints, and duration. The “ability to intervene” is instant revocation a human-traceable kill of the agent’s authority.
• Monitor and suspend (26(5)). Every action is an explicit allow/deny decision at the enforcement point budget-ceiling breaches trigger automatic revocation. ATCP suspends the authority your team still owns the monitoring and reporting process around it.
• Six-month logs (26(6)). A hash-linked, append-only audit trail records every decision and ties it back to the originating human consent. Retention and durable export are a deployment choice (ship the chain to object storage), not an afterthought.

NIS2 (essential and important entities)

NIS2 puts accountability on the management body to approve and oversee security measures (Art. 20), and prescribes a baseline of risk-management measures (Art. 21(2)) including access-control and asset-management policies, the use of multi-factor or continuous authentication, and cryptography backed by a three-phase incident-reporting timeline of a 24-hour early warning, a 72-hour notification, and a one-month final report (Art. 23).

Where ATCP maps:

• Management accountability (Art. 20). The mandate ties every automated action to an accountable human authority, and the audit chain reconstructs who authorised what the governance evidence regulators expect for actions taken on your behalf.
• Access control and least privilege (21(2)(i)). Default-deny, with per-call enforcement of an attenuated scope: the agent can do only what the mandate permits, checked on every request.
• Continuous authentication (21(2)(j)). Proof-of-possession on every call (a fresh DPoP proof plus workload mTLS identity) authenticates the agent continuously on each action, not once at session start. This is one of the cleanest fits in the whole mapping.
• Incident handling and reporting (Art. 21/23). Real-time denials provide detection the tamper-evident trail is the evidence base your team draws on to file the 24h / 72h / one-month reports.

DORA (financial entities)

DORA is the closest fit, because it is financial-sector-specific and acts as lex specialis where its requirements equal or exceed NIS2, DORA takes precedence. Its ICT risk-management framework (Arts. 5–16) includes Article 9 (“Protection and Prevention”), which mandates strong authentication and makes least privilege a legal obligation: 9(4)© requires logical access to be limited to what is required for legitimate and approved functions only. It requires prompt detection of anomalous activity (Art. 10) and structured ICT-incident management and reporting (Arts. 17–23).

Where ATCP maps:

• Least privilege (Art. 9(4)©). A mandate plus per-call enforcement is, almost verbatim, access limited to approved functions checked every time, for a non-human actor.
• Strong authentication (Art. 9). Short-lived workload identities and key-bound tokens no static API keys anywhere.
• Prompt detection (Art. 10). Each policy or constraint violation is denied in real time with a specific reason code, and over-budget activity auto-revokes.
• Incident records (Arts. 17–23). The hash-linked chain is a documented, classifiable record of every decision, reconstructable to the authorising human in seconds the raw material for incident classification and reporting.

The reference “bank pays Alice’s bills” scenario is, in effect, a DORA-shaped scenario already: a regulated financial entity, an automated actor, least-privilege access, real-time control, and an auditable trail.

The reality these three regimes are mapping toward

Strip away the differences and the AI Act, NIS2, and DORA are all converging on the same operational truth: when something acts on a regulated system, you must be able to show, not say that it acted within authority a human granted, and you must be able to stop it and reconstruct it. AI agents make that harder, because the actor is fast, autonomous, and subvertible.

ATCP exists to make the answer a single verifiable artifact: who authorised this agent, what it was allowed to do, that the boundary held, and the cryptographic chain proving it. That is the reality these three frameworks are pointing at and it is the part of the problem you can put in front of an auditor.

Sources

• EU AI Act, Article 26 — Obligations of Deployers of High-Risk AI Systems: https://artificialintelligenceact.eu/article/26/ and the EU AI Act Service Desk: https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-26
• EU AI Act high-risk application timeline: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
• NIS2 Directive (EU) 2022/2555, Articles 20, 21, 23: https://www.nis-2-directive.com/NIS_2_Directive_Article_21.html and ENISA mapping guidance: https://www.enisa.europa.eu
• DORA Regulation (EU) 2022/2554, ICT risk management (Arts. 5–16), Article 9 protection & prevention, incident management (Arts. 17–23): https://www.cssf.lu/en/ict-and-cyber-risk-for-dora-entities/

https://ai.soa.team/