None of these frameworks has a chapter on AI agents. What they require is older and narrower: segregation of duties, user accountability, access restriction, change control, protected logs, and, for a small set of AI systems, human oversight by named people. An agent authorization layer can meet some of those clauses outright, contribute evidence toward others, and does nothing at all for most of the obligations in these texts, which are organisational. This page states which is which, clause by clause, and quotes the binding text rather than a summary of it.
How to read the grades
- SATISFIES. The mechanism is the thing the clause describes.
- SUPPORTS. It is evidence toward the clause. Meeting the clause remains yours.
- DOES NOT ADDRESS. The mechanism contributes nothing. The obligation is organisational, and no product discharges it.
The mechanisms graded below are the ones this section describes: refusal by default, a signed policy bundle with a rising version number, a quorum of distinct signing identities, receipts on an append-only chain anchored outside the issuing system, and a credential that stays with an executor you run. Each is defined in agent authorization, dual authorization and the AI agent audit trail.
DORA and its technical standard
Sources: Regulation (EU) 2022/2554 and Commission Delegated Regulation (EU) 2024/1774.
| Article | Requirement | Mechanism | Grade |
|---|---|---|---|
| RTS Art. 21(b) | "the segregation of duties designed to prevent ... the allocation of combinations of access rights that may be used to circumvent controls" | Quorum of distinct signing identities; the proposer is outside the approval set for what it proposed | SATISFIES |
| RTS Art. 21(c) | "user accountability, by limiting ... generic and shared user accounts and ensuring that users are identifiable for the actions performed ... at all times" | A signed receipt binds the action, the policy version and the identities that signed; an agent is not a shared service account | SATISFIES |
| Art. 9(4)(c) | "implement policies that limit the physical or logical access to information assets and ICT assets to what is required for legitimate and approved functions" | Refusal by default; an unknown resource is graded at the highest tier and unknown reversibility is treated as irreversible | SUPPORTS |
| Art. 9(4)(e) | ICT change management ensuring "all changes to ICT systems are recorded, tested, assessed, approved, implemented and verified in a controlled manner" | The policy bundle is signed and its version must rise on every publish, so a rollback is refused | SUPPORTS |
| RTS Art. 12(2)(c)(i), (d) | log events on "logical and physical access control ... and identity management"; protect logs "against tampering, deletion, and unauthorised access" | Append-only receipt chain anchored where a second party reads it | SUPPORTS, and only for agent actions, not for the estate |
| Art. 17(1) to (3), Art. 19(1) | an incident management process, and reporting major ICT-related incidents to the competent authority | None | DOES NOT ADDRESS |
| Art. 6(1), 6(5) | a "sound, comprehensive and well-documented ICT risk management framework", reviewed at least yearly | None | DOES NOT ADDRESS |
| Art. 5(2) | the management body shall "define, approve, oversee and be responsible for" the framework | None | DOES NOT ADDRESS |
DORA itself contains no dual-authorization article. Anyone citing one is citing something that is not there.
The EU AI Act
Source: Regulation (EU) 2024/1689.
| Article | Requirement | Mechanism | Grade |
|---|---|---|---|
| Art. 14(5) | "no action or decision is taken ... unless that identification has been separately verified and confirmed by at least two natural persons with the necessary competence, training and authority" | A 2-of-2 quorum on distinct signing identities, checked at the executor | SATISFIES, and the scope is Annex III point 1(a) biometrics only |
| Art. 12(1) to (2) | "technically allow for the automatic recording of events (logs) over the lifetime of the system", at a traceability level fit for the purpose | Every graded proposal leaves a signed receipt: the action, the grade, the policy version, the signers, the time | SUPPORTS |
| Art. 14(4)(d) | the overseer can "decide ... not to use the high-risk AI system or to otherwise disregard, override or reverse the output" | A held action releases only on a quorum, and refusal is the default answer | SUPPORTS |
| Art. 14(4)(e) | "to intervene ... or interrupt the system through a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state" | A quorum that does not form ends the hold with nothing run; the executor never started | SUPPORTS |
| Art. 26(6) | deployers "shall keep the logs automatically generated ... for a period ... of at least six months" | None; the SDK stores, forwards and logs nothing, so retention is yours | DOES NOT ADDRESS |
| Art. 26(2) | deployers "shall assign human oversight to natural persons who have the necessary competence, training and authority" | None; a signature count is checked, never competence or training | DOES NOT ADDRESS |
| Art. 9(1) to (2) | a risk management system run "throughout the entire lifecycle", identifying, estimating and evaluating risk | None | DOES NOT ADDRESS |
| Art. 43 | conformity assessment before placing on the market | None | DOES NOT ADDRESS |
This page maps clauses, not the timetable. The application dates sit in Article 113 and in any amending act, and they should be read from EUR-Lex rather than from a vendor page.
NIS2
Source: Directive (EU) 2022/2555.
| Article | Requirement | Mechanism | Grade |
|---|---|---|---|
| Art. 21(2)(i) | "human resources security, access control policies and asset management" | The agent holds no credential; the executor holds them and acts only on a verified receipt | SUPPORTS |
| Art. 21(2)(h) | "policies and procedures regarding the use of cryptography and, where appropriate, encryption" | Receipts signed under two independent signature algorithms, both required; approver keys never leave the approver's device | SUPPORTS |
| Art. 21(2)(a) | "policies on risk analysis and information system security" | A signed policy bundle grades every proposal, and refuses where no rule exists | SUPPORTS |
| Art. 21(2)(b) | "incident handling" | None | DOES NOT ADDRESS |
| Art. 21(2)(g) | "basic cyber hygiene practices and cybersecurity training" | None | DOES NOT ADDRESS |
| Art. 23 | a 24-hour early warning, a 72-hour notification and a final report within one month | None | DOES NOT ADDRESS |
| Art. 20(1) to (2) | management bodies approve the measures, are liable for them, and must follow training | None | DOES NOT ADDRESS |
The letters of Article 21(2) are widely misquoted. In the authentic text, (g) is cyber hygiene and training, (h) is cryptography, (i) is access control and (j) is multi-factor authentication. A page citing "21(2)(e) access control" is wrong: (e) is security in acquisition, development and maintenance.
ISO/IEC 27001:2022 Annex A
Source: ISO/IEC 27001:2022. Control numbers and titles only. The control text is copyrighted and is not reproduced.
| Control | Title | Mechanism | Grade |
|---|---|---|---|
| A.5.3 | Segregation of duties | Quorum of distinct identities; a proposer cannot approve its own proposal | SATISFIES |
| A.8.2 | Privileged access rights | Zero credentials in the agent, neither vaulted nor brokered | SUPPORTS |
| A.8.3 | Information access restriction | Refusal by default; an unknown resource is graded at the highest tier | SUPPORTS |
| A.8.15 | Logging | Signed receipts on an append-only, externally anchored chain | SUPPORTS |
| A.8.16 | Monitoring activities | Eight executor refusal classes, each raising a critical alert to an audience the signed bundle names | SUPPORTS |
| A.8.32 | Change management | A signed bundle whose version must rise on every publish | SUPPORTS |
| A.5.24, A.5.25 | Incident management planning and preparation; assessment and decision on information security events | None | DOES NOT ADDRESS |
| A.5.36 | Compliance with policies, rules and standards for information security | None; attestation is organisational | DOES NOT ADDRESS |
ISO/IEC 27001 has no non-repudiation control. AU-10 is a NIST SP 800-53 identifier, and the nearest ISO neighbour is A.8.15 Logging. Clause identifiers do not transpose between frameworks.
MITRE ATLAS
ATLAS is not a regulation. It is a knowledge base of
adversary techniques against AI-enabled systems, and it is the vocabulary an
agent threat model is written in. Technique pages are at
https://atlas.mitre.org/techniques/<ID>.
| Technique | Name | Mechanism | Grade |
|---|---|---|---|
| AML.T0051 | LLM Prompt Injection, as initial access | Refusal by default; the injection succeeds and still reaches no credential | SUPPORTS |
| AML.T0051.000, .001, .002 | Direct, Indirect, Triggered | The same. The Triggered sub-technique is newer than most published mappings, which stop at direct and indirect | SUPPORTS |
| AML.T0053 | AI Agent Tool Invocation | Every tool call is a proposal graded against signed policy | SATISFIES |
| AML.T0080 (.000 Memory, .001 Thread) | AI Agent Context Poisoning | Decision values are recomputed from the signed bundle and never read from the proposal | SATISFIES |
| AML.T0081 | Modify AI Agent Configuration | The policy bundle is signed: one changed byte fails verification, and the version must rise | SATISFIES |
| AML.T0011 | User Execution | None | DOES NOT ADDRESS |
Two things are deliberately absent from this table. Technique counts for the current ATLAS release are not printed here, because the figures in circulation trace to vendor blogs rather than to ATLAS release notes. Two technique names quoted in earlier mappings of ours do not resolve to identifiers in the current data file under those names, so they are omitted until the identifiers are re-derived from the source.
What the primary texts do not say
Five claims appear often enough in agent security material to be worth contradicting in writing.
- "The AI Act requires two humans." It does not. Article 14(5) binds Annex III point 1(a), remote biometric identification, and is disapplied for certain law enforcement, migration, border control and asylum uses.
- "DORA requires two-person approval." No article does. The nearest binding text is RTS Article 21(b) and 21(c), written as segregation of duties and user accountability.
- "Article 12(3) lists the log fields every high-risk system must record." Those minimum fields are Annex III point 1(a) only. The general logging duty is Article 12(1) and 12(2).
- "An anchored ledger meets the six-month retention duty." It does not. Article 26(6) is a duty on the deployer, over the deployer's own logs.
- "ISO 27001 has a non-repudiation control." It does not. That identifier belongs to NIST SP 800-53.
Where does ZIFFER stand against this table?
The mechanisms graded above are ZIFFER's: a signed policy bundle you hold the key to, refusal as the default answer, a quorum of two named humans on irreversible actions, receipts signed under two independent algorithms on an append-only chain anchored where a second party can read it, and your credentials held by your executor rather than by the agent or by us. That is the SATISFIES and SUPPORTS column. The DOES NOT ADDRESS rows are equally binding and are not softened anywhere else on this site: no incident is reported for you, no risk management framework is written for you, no conformity assessment is performed, no approver's competence is assessed, and the SDK keeps nothing, so retention is yours to build. The published limits are listed in what ZIFFER does not do yet, the receipt format and what checking it proves are in the specification, and the named refusals are in every refusal.