The Evidence Question

Version 2, September 2026. Version 1, 15 July 2026, doi:10.5281/zenodo.21325135.

TL;DR

• The obligations already reach agents. Neither DORA nor NIS2 names AI agents, but both are technology-neutral. An AI agent a bank runs is, or forms part of, an ICT asset under DORA, which for financial entities within NIS2’s scope applies instead of NIS2’s risk-management, reporting and supervision provisions. An agent run by an essential or important entity outside finance operates within a network and information system under NIS2, as transposed. Either way, the entity’s existing duties absorb it the moment it goes live.

• What the supervisor can already ask. Do you inventory this agent and the cryptography it carries. Is its access limited to approved functions and strongly authenticated. Can you detect it behaving anomalously. When something goes wrong, can you produce the record of what it did and under whose authority, and defend it in an inspection. DORA has applied since 17 January 2025.

• Where the answer isn’t. Across the three agent platforms reviewed here, OpenAI, Anthropic and Mistral, as publicly documented in July 2026 and re-checked in September, agent-level identifiers and traces have started to arrive, most of it beta or enterprise-gated, and most of it shipped since 2025. What has not arrived is the evidence property. Identity still authenticates at the organisation and its credentials, and the agent-level records do not carry consistent evidence properties: some surfaces are described as immutable, others are deletable, one was described in July as exporting into editable datasets, and none is documented as carrying an independently verifiable seal over the action and the authority it was taken under. The platform can attribute a request to an organisation-held credential. Nothing in its documentation shows that it can prove, on its own, which agent did what, on whose delegated authority, in a form a supervisor reads as evidence.

• The part underneath. Where a signature is what makes agent evidence authentic and attributable, that evidence depends on the signature remaining valid. If it is classical and fixed, the evidence a regulator will read years from now is being written today on cryptography with a deprecation horizon that NIST and the EU’s coordinated post-quantum roadmap have already sketched, around 2030 to 2035. That is the crypto-agility question, arriving through the compliance door.

• The instruments stop at outcomes. Neither DORA nor NIS2 requires agent identity, agent audit trails, or post-quantum cryptography by name, and both leave the mechanism to the operator. On those three platforms, the mechanism is not yet a consistent platform primitive, and today the regulated entity assembles it itself.

An inspection, 2027

A supervisor sits across from the CISO of a regulated financial entity. The scene is a composite, but each part of it is real: the DORA oversight framework for critical ICT third-party providers has begun operating, financial entities identified for testing are running their first threat-led penetration tests, and DORA gives competent authorities the power to access any document or data they consider relevant to their duties. The supervisor has read that the entity runs AI agents in its operations. In practice these duties sit with several authorities: the ESAs oversee the designated critical ICT third-party providers, the bank answers to the ECB or its national authority, and testing timetables vary by entity. Each question, though, is drawn from a duty already in force, and the one on delegated authority reads those duties at a granularity no text spells out.

Which of your agents touch systems that matter, and are they in your ICT inventory. When an agent acts, is its access limited to what its task requires, and how is it authenticated. If an agent behaves anomalously, do you detect it. And when you file the incident report the regulation requires, can you show what the agent did, on whose authority it did it, and that the record has not been altered since.

The CISO can answer the first version of each question at the level of the organisation. There is an inventory. There is an access policy. There are logs. There is an incident process. On the platforms reviewed later in this paper, though, what the platform provides attaches one level up from the agent: to the API credential the organisation holds, and to the organisation itself.

This is the evidence question. The duties and supervisory powers that carry these questions are already in force, exercised where relevant and proportionate. What would answer them at the granularity of the agent, and keep the answer durable, is the part of the estate that post-quantum migration programmes have not yet reached.

Terms. An AI agent is an AI system that holds credentials, or has access to tools, through which it acts on other systems. It chooses its actions at run time and acts on authority delegated by a person or an organisation, whether it runs behind a product interface or is called through an API. Evidence means a record a supervisor can rely on to establish what an agent did and under whose authority, and the term implies no view on admissibility in legal proceedings.

The obligations are technology-neutral, so they already apply

The instinct is to wait for regulation to name agents before treating them as regulated. That reads the law backwards. DORA and NIS2 were both written to be technology-neutral, which is precisely why they reach a technology their drafters did not anticipate.

Under DORA, an ICT asset is defined as a software or hardware asset in the network and information systems used by the financial entity. (Regulation (EU) 2022/2554, Article 3, point 7.) An AI agent a bank deploys is software in its systems, so it is, or forms part of, an ICT asset. Where the agent runs on a provider’s platform, the platform is an ICT service under Article 3, point 21, and the contract belongs in the register of information under Article 28(3), so a hosted agent is reached through the third-party regime as well. The duties that attach to ICT assets are concrete: financial entities must identify all information assets and ICT assets and map their configuration and their interdependencies, maintaining inventories that are updated periodically and every time a major change occurs, with the adequacy of the classification reviewed at least yearly. (Article 8(4), (6) and (1).) DORA has applied since 17 January 2025.

NIS2 works the same way from the other direction. A network and information system is defined to include “any device or group of interconnected or related devices, one or more of which, pursuant to a programme, carry out automatic processing of digital data”. (Directive (EU) 2022/2555, Article 6, point 1(b).) An agentic system processing data inside an essential or important entity operates within the systems that definition covers. The directive’s minimum security measures, which both essential and important entities must take, are an all-hazards baseline that includes cryptography policy, access control, and secure development. (Article 21(2).) For a bank the same definition arrives through DORA, which borrows it (DORA Article 3, point 2). DORA is the sector-specific act under NIS2 Article 4, so, for DORA financial entities that are also identified as essential or important entities under NIS2, NIS2’s Articles 21 and 23 and its supervision and enforcement chapter do not apply. (DORA Article 1(2), NIS2 Article 4(1) and recital 28.)

Neither instrument names AI agents. Both reach the agent through definitions written to be neutral.

Neither DORA nor NIS2 requires agent identity, agent audit trails, or quantum-safe cryptography by name. NIS2’s cryptography item is a policy obligation, and encryption within it is qualified by where appropriate; it mandates no algorithm and, in its current text, says nothing about the quantum transition. (Article 21(2), point h.) A Commission proposal of January 2026 would add a policy “for the transition to post-quantum cryptography” to each Member State’s national cybersecurity strategy, citing among its reasons “the future risks induced by quantum attacks on forging signatures”. It leaves the list of entity-level measures in Article 21(2) unchanged, and in September 2026 it was still awaiting a committee decision in the European Parliament. (COM(2026) 13 final, new Article 7(2), point k, and recital 8.) A claim that these instruments require post-quantum cryptography for agents does not survive contact with the text. The stronger argument runs the other way. The instruments require outcomes, technology-neutral and risk-proportionate, and they leave the mechanism to the operator. On the three agent platforms reviewed below, that mechanism is not yet a consistent platform primitive, and today the regulated entity assembles it itself.

Three questions the obligations already ask

Read against how agents are actually operated, the obligations sort into three families, and each lands on a capability that, on the platforms reviewed below, attaches to the organisation, not the agent.

Inventory. DORA’s Article 8 requires the financial entity to know its ICT assets and their interdependencies. An agent sits in that perimeter, and the cryptography it carries, the keys it authenticates with and the signatures it leaves, is what a mature implementation links to those assets. DORA’s regulatory technical standards on ICT risk management (the RTS, Commission Delegated Regulation (EU) 2024/1774) list the records kept for each ICT asset, from a unique identifier to its owner and interdependencies, and none of them is cryptographic (Article 4(2), point b). The closest duty is a register of all certificates and certificate-storing devices for at least the ICT assets supporting critical or important functions (Article 7(4)). It covers certificates. Where a platform authenticates with API keys or bearer tokens, as all three did in July, the credential falls outside it. Where it authenticates with an X.509 client certificate, as OpenAI has documented since 29 August 2026, the register reaches the certificate, though still not the agent. Paper II.2 introduced Agent-CBOM as the inventory instrument for this, because an inventory with no concept of the agent cannot list the agent’s cryptography. Most inventory tools do not yet record an agent as an asset together with the cryptography it carries, and the DORA RTS asset record does not ask for it.

Access and authentication. DORA requires policies that limit physical or logical access to ICT assets to what is required for legitimate and approved functions, and policies for strong authentication and protection of cryptographic keys. (Article 9(4), points c and d.) NIS2’s baseline bundles access control policy with human-resources security and asset management (Article 21(2), point i), and separately lists, where appropriate, the use of multi-factor or continuous authentication solutions (point j). Applied to an agent, these duties ask what this agent is allowed to touch, how that is limited, and how it proves it is the agent it claims to be, on the delegated authority of the human or system it acts for. NIS2 does not name non-human actors, but applying its control model to an agent is the natural risk-based reading, and the three platforms reviewed below still answer it at the credential above the agent.

Evidence. DORA requires mechanisms to promptly detect anomalous activity, requires the entity to record all ICT-related incidents and identify root causes, and requires staged reports on major incidents to the supervisor, the first within four hours of classifying an incident as major and no later than twenty-four hours after becoming aware of it. (Articles 10, 17 and 19, and Delegated Regulation (EU) 2025/301, Article 5(1).) For financial entities outside the simplified framework of DORA Article 16, the RTS makes the record duty explicit: logging procedures that set a retention period, protect logs against tampering, deletion and unauthorised access, and synchronise system clocks to a documented reliable time source (Article 12(2)), unique identification and authentication of natural persons and systems (Article 20(1)), and limits on generic and shared accounts so that users stay identifiable for the actions they perform (Article 21, point c). It does not ask for a record that binds an action to the authority it was delegated under, or one whose integrity can be checked without relying on the entity’s own controls, and that narrower gap is the one this paper names. NIS2 requires a three-stage cascade for significant incidents, an early warning within twenty-four hours of awareness, a fuller notification within seventy-two hours, and a final report, and gives supervisors of essential and important entities the power to demand evidence of implementation of the security policies. (Articles 23(1), (3) and (4), 32(2), point g, and 33(2), point f.) Each of these duties depends on records sufficient to detect, investigate and explain the incident, and where an agent materially caused or shaped the event, identifying the execution and the authority it acted under may be exactly what root cause requires. For a human actor, identity and access management has built that record over many years, around named accounts. For an agent, the record on the platforms reviewed below does not by itself carry it.

Where the evidence isn’t, from the public record

The gap does not require anyone’s confidential roadmap to establish. It is visible in the vendors’ own public documentation. The review covers three agent platforms run by model providers, OpenAI, Anthropic and Mistral, chosen as a small sample of providers whose agent products a regulated entity can contract for directly, two based in the United States and one in Europe. Microsoft, Google, Amazon Web Services and others were not reviewed. Cloud identity services that document per-agent identities, such as Microsoft Entra Agent ID and Amazon Bedrock AgentCore Identity, were read only to confirm that description and are outside the sample.

As documented on 12 July 2026, OpenAI’s workspace product gives agents first-class identifiers, an admin surface showing each agent’s configuration, activity and runs, and a compliance log stream described as immutable and append-only; on the same vendor’s API platform, the Audit Logs API records administrative events and credential lifecycles, the documentation for one agent surface, ChatGPT agent, since retired, states that individual agent actions do not appear in compliance logs even where the conversation does, the agent-trigger API returns no run identifier by default (one is returned under an opt-in beta header, see the update), and the Agents SDK ships tracing as client-emitted developer observability, keyed by a free-text workflow name, that the operator can disable or redirect. Anthropic’s managed-agents beta documents persistent per-instance sessions with chronological tool-call event streams, and vaults that hold an end user’s credentials and are referenced per session, so the operator can track which end user an agent acted for; every endpoint authenticates with an organisation-held credential, a workspace API key or, since May 2026, a short-lived token bound to a service account in the organisation, and neither is documented as bound to the agent or the session. The sessions and their event records are deletable by the operator, which is an ordinary retention control, and nothing in the documentation describes a signed or tamper-evident record of what remains. Mistral’s Agents API gives an agent a first-class identifier with versions and aliases, the identifier naming the agent’s configuration rather than a running instance, and In July its enterprise observability pages described per-event agent identifiers, invoked tools and correlation identifiers, with export into editable datasets, and its audit-log page described administrative events only, without export. The pages read in September no longer describe the per-event identifiers or the dataset export, and the audit log now lists API usage and Vibe interactions among logged events, so those July details are kept here as history only (see the September update). A dated re-check of the same documentation, made on 21 and 22 September 2026, is recorded in the appendix.

Read together, the documentation shows a consistent pattern. The platforms are adding agent-level features, and agent-granular telemetry is arriving: identifiers, sessions, event streams, activity views, most of it beta or enterprise-gated and months old. What is not arriving is the evidence property. Identity still authenticates at the organisation and its credentials, the API key or at most a named workload-level service account, and the agent identifier names a configuration, not an authenticated principal. The agent-level records do not carry consistent evidence properties: some surfaces are described as immutable, others are deletable at the operator’s discretion, which bears on what survives rather than on integrity (and in July one exported into editable datasets), coverage differs by product surface, and none of the reviewed documentation describes an independently verifiable cryptographic seal over the complete record of an action and the authority it was taken under. The platforms do provide controls, and they are adding more. The observation concerns the kind of record those controls produce. The platform can attribute a request to a credential the organisation holds. It cannot, on its own, hand a supervisor a tamper-evident record that this agent took this action on the delegated authority of that principal. Issuing one key or service account per agent helps, since requests can then be traced to an agent configuration. It still does not show which running instance acted, which principal delegated the task, or whether the record has been altered since.

The supervisor asks about the agent and the authority. The three platforms reviewed answer about the organisation and the key.

Logs are not automatically evidence. Telemetry keyed by a workflow name a developer chose, and deletable with its session, is not yet an attributable, tamper-evident record of a regulated action. The criteria that follow are the author’s, since no single legal text sets them out. A log becomes evidence when it has a set of properties: a stable identifier for the agent configuration and for the running instance; the initiating principal, human or service, and the scope it delegated; the consequential actions and their results; trusted time; integrity protection that survives the operator; retention aligned to the supervisory horizon; and exportability, so the record leaves the platform without losing its provenance. Vendor telemetry supplies raw material for some of these. Assembling the evidence package is the regulated entity’s job, and the documentation of the three platforms reviewed leaves it there. The enterprise toolchain already offers the parts, such as workload identity, external signing and immutable log pipelines. Several of the properties on the list, integrity, trusted time, durable attribution, depend materially on cryptographic mechanisms, alongside governance and chain-of-custody controls.

The part underneath: agent evidence is a cryptographic artifact

Under the compliance question sits a cryptographic one. The record an agent leaves, the receipt an auditor will read after the fact, draws its integrity and its attribution from signatures, timestamps and hash chains. In eIDAS terms an electronic signature belongs to a natural person, and a legal person uses an electronic seal to ensure the origin and integrity of data, so where a record of an agent’s action is protected under eIDAS, the instrument would be the electronic seal of the entity or its provider (Regulation (EU) No 910/2014, Article 3, points 9, 24 and 25). Nothing in eIDAS requires such a seal. Where a signature is what establishes that a record is authentic and attributable, the evidence depends on that signature remaining valid. If it is a fixed classical scheme, inherited from a framework or a library rather than chosen by the entity, then the evidence a regulator will read years from now is being written today on cryptography with a published deprecation horizon. NIST’s draft transition plan would deprecate quantum-vulnerable signatures at the 112-bit level after 2030 and disallow all of them after 2035, and the EU’s coordinated roadmap recommends completing the transition for high-risk uses by the end of 2030 and for medium-risk ones by the end of 2035. A signed record can keep its technical evidential value past that horizon if it is renewed in time: evidence-record schemes such as RFC 4998 add fresh time-stamps over the data and its earlier evidence, under stronger mechanisms, before the old ones weaken. Scheduling that renewal belongs inside the same agility programme.

Policy has begun to say this out loud. In Europe, the coordinated roadmap published through the NIS Cooperation Group in June 2025 already counts authenticity among the properties quantum computers will put at risk, and recommends that quantum-safe software and firmware upgrades be enabled by default by the end of 2030. The United States executive order of 22 June 2026 on advanced cryptographic attacks split the federal deadline in two for designated high value assets and high impact systems, National Security Systems excluded: post-quantum key establishment by the end of 2030, and post-quantum digital signatures by the end of 2031. Signatures, which make a record attributable, are treated as a distinct migration from channel key establishment, on a later clock. Agent identity and agent receipts live in the signature half. A regulated entity migrating its channels and leaving its agent receipts on a fixed classical signature has completed the key-establishment half of the programme and left the signature half open.

The binding language in regulated finance already frames this as agility rather than a one-time move. The RTS on ICT risk management requires the policy on encryption and cryptographic controls to include provisions “for updating or changing, where necessary, the cryptographic technology on the basis of developments in cryptanalysis”, and an entity that cannot update or change it must adopt mitigation and monitoring measures and record a reasoned explanation. (Commission Delegated Regulation (EU) 2024/1774, Article 6(4) and (5).) That is an agility duty in substance, though the text does not use the word. Recital 9 points to the reason, naming “threats from quantum advancements”. Where an entity relies on signatures to protect its agents’ records, that receipt cryptography sits inside that duty, and it is the part of the estate least likely to be inventoried.

The ECB has now raised both subjects in one letter, without drawing the link this paper draws. On 7 July 2026 the chair of the ECB’s supervisory board wrote to the chief executive of every significant institution about AI-enabled cybersecurity threats. The letter asks for an action plan, with roles, resources and timelines, submitted to each bank’s joint supervisory team by 31 October 2026. Its annex lists continuous verification of users, devices, applications, APIs and service accounts, accurate asset inventories and comprehensive logging among the measures to consider. It ends on post-quantum adoption, which “may involve a longer time frame, but must start now”, with a separate letter on quantum risk to encryption announced for due course.

A crowded policy layer over a thin substrate

It would be wrong to claim a standards void. The layer above the cryptography is busy. The IETF’s workload identity work (WIMSE) is active, though it has published no RFC. On 15 September 2026 its working group adopted an informational draft, AI Identity Management System (draft-ietf-wimse-aims-00). Its audit section says records MUST be tamper-evident and must name the authenticated agent and, where present, the delegated subject. It leaves the sealing mechanism open and says nothing on cryptographic agility. The OAuth identity-chaining specification has been approved for publication and sits in the RFC Editor queue, and the transaction-tokens draft has passed working-group last call and awaits its write-up for the IESG. The Model Context Protocol defines an authorization pattern, though it is optional. Beyond one SHOULD-level line, that clients log tool usage for audit purposes, the specification sets no requirements for what such logs contain, how they are protected or how long they are kept, and none for cryptographic agility. Its current revision, published on 28 July 2026, makes the protocol stateless, deprecates its logging utility in favour of OpenTelemetry and tightens parts of the OAuth flow, and adds none of these requirements. Guidance has arrived in volume: OWASP’s agentic top ten and the Cloud Security Alliance’s agentic identity work from the community, and from NIST a National Cybersecurity Center of Excellence (NCCoE) concept paper on software and AI agent identity and authorization, published for comment on 5 February 2026.

The European AI Act’s own cybersecurity standard makes the pattern concrete. prEN 18282, the enquiry draft written to carry the presumption of conformity for Article 15’s cybersecurity requirement once adopted and cited in the Official Journal, went to public enquiry in May 2026, with the French national enquiry closing on 14 July 2026 and the European enquiry at the end of July 2026. The enquiry draft is deliberate about its perimeter. Conventional ICT cybersecurity is out of scope, threats related to generative AI models are addressed in a single subclause, and agents appear only in passing. Cryptography appears only as examples or single actions: signatures and cryptographic methods named as options for integrity checks on data and models, “cryptographic protection” listed among example measures for confidential assets, and the replacement of compromised keys after an incident. No key management lifecycle, no algorithm lifecycle, no agility duty. As circulated for enquiry, the standard meant to ground that presumption does not reach the cryptography high-risk AI systems run on, so if it is adopted and cited, the presumption, which Article 40(1) grants only “to the extent that those standards cover those requirements”, will not cover this layer. The drafters made the same perimeter decision as the other efforts above, which leaves the cryptography with the operator.

The policy layer, who the agent is, what it may do, how delegation is expressed, is crowded and maturing. The cryptography underneath it, the agility of the credentials and receipts that give agent evidence its weight, is where little of this work reaches: the WIMSE draft asks for tamper-evident records but leaves the mechanism and its lifetime open. The gap can be inventoried: for each agent, the signature scheme its records rely on and whether it can be changed. Where an entity relies on signatures for its agents’ records, the policy on cryptographic controls required under DORA already covers those signatures.

A note on the third instrument, the EU AI Act, which moves slowest of the three on the duties this paper tracks. It does not define an AI agent, and the Commission’s AI Act Service Desk FAQ states that AI agents are not a separate category of AI under the Act. Its high-risk obligations, including its logging and log-retention duties, have been deferred by the Digital Omnibus on AI, Regulation (EU) 2026/1744, in force since 27 July 2026. They now apply from 2 December 2027 for the stand-alone systems listed in Annex III and from 2 August 2028 for systems covered by the product legislation listed in Annex I. DORA, which does not name AI agents, applies now.

Five things to do Monday

First steps, in the order of the obligations above.

1. Put your agents in the ICT inventory. As assets, with the cryptography they carry. If an agent is not a line in the inventory DORA already requires, neither is its identity or its receipt signature. For a hosted agent, the platform contract also belongs in the register of information (DORA Article 28(3)).

2. Map each agent to the access and authentication obligations you already meet for humans and services. What is it allowed to touch, how is that limited, and how does it prove which agent it is and whose authority it carries. Continuous authentication is already listed in the NIS2 baseline where appropriate, and the DORA RTS requires unique identification and authentication of systems as well as persons; the question is whether you can produce it at the agent instance.

3. Make agent action-evidence supervisor-legible, not just developer-visible. A trace keyed by a workflow name is observability. What an inspection needs is an attributable, tamper-evident record of which agent did what on whose delegated authority. Decide which of your agents produce evidence and which produce only telemetry, and know the difference before someone asks. Where a provider holds the record, write the evidence terms into the contract DORA Article 30 already governs, beside the data-integrity and incident-assistance provisions it requires: what is logged, in what export format, for how long, and who can delete it.

4. Put agent credentials and receipts on the crypto-agility programme. The RTS duty to provide for updating or changing cryptography reaches the signatures under your agents’ records, where you rely on them. Inventory them, know whether they are fixed at a framework layer, and know what it would take to change them.

5. Read the calendar correctly. DORA applies now and is moving to inspection. NIS2 applies as each Member State transposes it; some, including France, have not yet. The AI Act’s high-risk obligations now start on 2 December 2027 and 2 August 2028, under the Digital Omnibus on AI. The ECB’s July 2026 letter to the chief executives of significant institutions sets 31 October 2026 as the deadline for their action plans and announces a separate letter on quantum risk.

The third and last paper in Series II, PQC for AI Agents, which opened with The Channel Question . The audit question itself was opened in Series I’s Auditing Agents Under NIS2, DORA, and the EU AI Act in May 2026. This paper re-reads it against the platforms and supervisors of July 2026, with the platform findings re-checked in September 2026.

Appendix, for compliance and cryptographic reviewers

On what the instruments do and do not say. DORA is Regulation (EU) 2022/2554, applying from 17 January 2025; the ICT-asset definition is Article 3(7), the inventory duty Article 8 (inventories updated periodically and on every major change per Article 8(6); the yearly cycle attaches to the classification review of Article 8(1)), access and authentication Article 9(4)(c) and (d), anomaly detection Article 10, incident recording and reporting Articles 17 to 19 (time limits in Delegated Regulation (EU) 2025/301, Article 5(1): the initial notification within four hours of classifying the incident as major and no later than twenty-four hours after becoming aware of it, or within four hours of a later classification (Article 5(2)), the intermediate report within seventy-two hours of that notification, the final report within one month of the latest intermediate report), contract terms Article 30(2)(c) and (f), and for services supporting critical or important functions Article 30(3)(e)(i), and the competent authority’s access to any document or data Article 50(2)(a). The agility duty, in the text’s words updating or changing the cryptographic technology where necessary, is Article 6(4) of the RTS on ICT risk management, Commission Delegated Regulation (EU) 2024/1774, with the mitigation record in Article 6(5). The same RTS requires a register of certificates and certificate-storing devices for at least the ICT assets supporting critical or important functions (Article 7(4)), logging procedures with a set retention period, protection against tampering and deletion, and synchronised clocks (Article 12(2)), unique identification and authentication of natural persons and systems (Article 20(1)), and limits on generic and shared accounts (Article 21(c)), and its recital 9 names “threats from quantum advancements”. These provisions sit in its Title II, which covers financial entities outside the simplified framework of DORA Article 16. NIS2 is Directive (EU) 2022/2555, which Member States were to transpose by 17 October 2024 and apply from 18 October 2024 (Article 41(1)); the system definition is Article 6(1), the minimum measures Article 21(2), management accountability Article 20, the incident cascade for significant incidents Article 23(1), (3) and (4) (a twenty-four-hour early warning, a seventy-two-hour notification, and a final report within one month of the notification, or, for an incident still ongoing, a progress report then and a final report within one month of its handling), and the evidence-of-implementation power Articles 32(2)(g) and 33(2)(f). For financial entities identified as essential or important entities under NIS2, DORA is the sector-specific act under NIS2 Article 4 (DORA Article 1(2)), so NIS2’s Articles 21 and 23 and its supervision and enforcement chapter do not apply to them (NIS2 Article 4(1) and recital 28), and DORA borrows NIS2’s definition of a network and information system (DORA Article 3, point 2). Neither instrument names AI agents, autonomous AI systems, or post-quantum cryptography; coverage of agents is by technology-neutral interpretation of the asset and system definitions, and the cryptographic obligations are policy and agility duties, not algorithm mandates. A Commission proposal amending NIS2 (COM(2026) 13 final of 20 January 2026, procedure 2026/0012(COD)) would add Article 7(2), point (k), requiring each national cybersecurity strategy to include a policy “for the transition to post-quantum cryptography”, with recital 8 naming “the future risks induced by quantum attacks on forging signatures”. It does not amend the list in Article 21(2), though it changes how implementing acts under Article 21(5) specify those measures, and as of September 2026 the European Parliament’s procedure file showed it awaiting committee decision. Commission Implementing Regulation (EU) 2024/2690, which specifies the NIS2 measures for certain digital providers, among them cloud computing, managed and managed security service providers, already asks for cryptographic choices made “following, where appropriate, a cryptographic agility approach” (Annex, point 9.2(b)).

On transposition. NIS2 obligations bind through national law. On 8 July 2026 the Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice for failing to notify full transposition (IP/26/1499). France’s transposing bill (résilience des infrastructures critiques et renforcement de la cybersécurité) was adopted by the Sénat in March 2025, passed the Assemblée nationale’s special committee in September 2025 and was still awaiting a plenary vote in the Assemblée as of 22 September 2026. NIS2 therefore applies where transposed, and not yet uniformly across the Union.

On the DORA supervision scene. Each anchor of the scene is on the public record: the ESAs designated the first critical ICT third-party providers on 18 November 2025, which starts their oversight under DORA, and financial entities identified for testing are running their first DORA threat-led penetration tests, on the at-least-every-three-years cycle the regulation sets, under timetables applied by their competent authorities.

On the ECB supervisory letter. The letter on addressing AI-enabled cybersecurity threats is SSM-2026-0301 of 7 July 2026, signed by the chair of the ECB’s supervisory board and addressed to the CEOs of significant institutions. It asks for an action plan to be submitted to the joint supervisory teams by 31 October 2026, announces a horizontal analysis of the submitted plans, extends the annual IT risk questionnaire collection to February 2027, and states that post-quantum adoption must start now, with a separate letter on quantum-computing risk to traditional encryption announced for due course. The European Systemic Risk Board’s warning on systemic cyber risks stemming from frontier artificial intelligence models was published alongside it. The letter’s Annex 1 lists, among the actions offered for consideration, “continuous verification of users, devices, applications, application programming interfaces (APIs) and service accounts”, accurate asset inventories and comprehensive logging. The letter does not mention AI agents or agent records. As of 22 September 2026 the announced quantum letter had not been published on the ECB’s letters-to-banks page.

On the deprecation horizon. NIST IR 8547, Transition to Post-Quantum Cryptography Standards, was published as an initial public draft on 12 November 2024 and was still a draft as of 22 September 2026. Its Table 2 marks quantum-vulnerable digital signature algorithms at 112 bits of security as deprecated after 2030 and all of them as disallowed after 2035. The NIS Cooperation Group’s coordinated implementation roadmap for the transition to post-quantum cryptography (Part 1, version 1.1, dated 11 June 2025, published 23 June 2025) recommends completing the transition for high-risk use cases by 31 December 2030 and for medium-risk ones by 31 December 2035. Both set migration deadlines, and neither forecasts when classical signatures could be forged. RFC 4998, Evidence Record Syntax (August 2007, Standards Track), specifies time-stamp and hash-tree renewal so that archived data keeps its evidential value as algorithms weaken.

On the US executive order. Executive Order 14412 of 22 June 2026, Securing the Nation Against Advanced Cryptographic Attacks (91 FR 38483), directs agencies to transition high value assets and high impact systems, excluding National Security Systems, to post-quantum cryptography for key establishment by 31 December 2030 and for digital signatures by 31 December 2031; a companion order on quantum innovation was issued the same day. Checked against the Federal Register text (FR Doc. 2026-12909, 25 June 2026), last re-read on 22 September 2026. The paper relies on the policy-level separation of signatures from key establishment, not on any US compliance obligation for European entities.

On the AI Act dates. Under the base text of Regulation (EU) 2024/1689, the Act applies generally from 2 August 2026, the date that would have carried the stand-alone (Annex III) high-risk obligations, while Article 6(1), the product-embedded (Annex I) route, and its corresponding obligations were set for 2 August 2027 (Article 113). Regulation (EU) 2026/1744 of 8 July 2026, the Digital Omnibus on AI, endorsed by the European Parliament on 16 June 2026 and approved by the Council on 29 June 2026, was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. It amended Article 113 so that Chapter III, Sections 1 to 3, now apply from 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and from 2 August 2028 for those classified under Article 6(1) and Annex I. Article 12 logging and the Article 26(6) deployer duty to keep logs for at least six months sit in Sections 2 and 3 and move with that regime. The Commission’s AI Act Service Desk FAQ states that AI agents are not a separate category of AI under the Act.

On the platform evidence gap. The observation is drawn from public vendor documentation on product and API surfaces, accessed 12 July 2026. The sample is three agent platforms run by model providers. Microsoft, Google, Amazon Web Services and others were not reviewed, and outside the sample Google’s Agent Payments Protocol (announced 16 September 2025) describes mandates as “tamper-proof, cryptographically-signed digital contracts that serve as verifiable proof of a user’s instructions”. OpenAI: workspace agents carry first-class agent identifiers with agent-level compliance visibility and a compliance log stream described as immutable and append-only, while the documentation for ChatGPT agent (agent mode), a product OpenAI has since retired, states that conversations involving agent tasks appear in Compliance API logs but individual agent actions, such as virtual computer usage and app requests, do not; the agent-trigger API returns no run identifier by default (one is returned under an opt-in beta header, see the update), and the API platform’s Audit Logs API records administrative and credential events, with SDK tracing as client-side observability. Anthropic: the managed-agents beta documents per-instance sessions with tool-call event streams and end-user vaults, operator-deletable and not described as signed or tamper-evident, alongside the Admin API and Compliance API. Requests authenticate with a workspace API key or, through workload identity federation (launched 4 May 2026, per Anthropic’s release notes), a short-lived token bound to a service account in the organisation. Mistral: the Agents API assigns first-class agent identifiers with versions and aliases. In July the enterprise observability surface was described as recording per-event agent identifiers and invoked tools and as exporting into editable datasets, and the organisation audit log as covering administrative events without export support. The September re-check found neither observability description and found the audit-log scope widened (see the update). The claim as stated: agent-level identifiers and telemetry exist and are expanding; identity authenticates at the organisation and its credentials; the records’ evidence properties are inconsistent across surfaces; and none of the reviewed documentation describes a portable, independently verifiable, delegation-bound record positioned as evidence. Feature sets change often, so any single detail may have changed since the access date.

Sources for the platform observations (all accessed 12 July 2026): OpenAI, “ChatGPT Workspace Agents for Enterprise and Business” (help.openai.com, article 20001143); OpenAI, “ChatGPT agent” (help.openai.com, article 11752874, the agent-action compliance-log exclusion); OpenAI, “Compliance Platform for Enterprise and Edu” (help.openai.com, article 9261474); OpenAI, “Admin and Audit Logs API” (help.openai.com, article 9687866); OpenAI, “Trigger runs” (developers.openai.com/workspace-agents); OpenAI Agents SDK tracing (openai.github.io/openai-agents-python/tracing); Anthropic, “Claude Managed Agents overview” and “Session operations” (platform.claude.com/docs/en/managed-agents, beta header managed-agents-2026-04-01); Mistral, “Explorer” and observability datasets (docs.mistral.ai/studio-api/observability); Mistral Agents API (docs.mistral.ai). The archived copies of record are held by the author.

Update, 22 September 2026. The platform observations above were re-checked against the same vendors’ public documentation on 21 and 22 September 2026. The re-check reads documentation and does not test products, so its findings are bounded to the pages listed below. It asked three questions. (a) Does a page describe a credential issued to an agent, meaning an identity created for a specific agent definition or instance, distinct from the user, workspace, project or service account that set it up? (b) Does a page describe records of agent activity that the operator can edit or delete? (c) Does a page describe a record carrying an independently verifiable seal that binds an agent’s action to the authority it was taken under? A seal here is any signature a third party can check without relying on the vendor, with its verification material retained. It is wider than the eIDAS electronic seal discussed in the body, which is one way to meet it.

On (a), all three vendors document or announce service accounts that a customer could dedicate to one agent (at OpenAI, a ChatGPT workspace feature for Codex automation, “available only on pay-as-you-go plans”), and none of the pages read describes an identity created for a specific agent. One OpenAI page uses the term. Its Codex access-token page says tokens “act as agent identities for programmatic local workflows” and that the command-line login “stores an agent identity credential”, while stating that “Each token belongs to its creator and that user’s ChatGPT workspace”. The documented subject is therefore a user, or a service account for tokens created from one. For workspace agents, OpenAI describes an agent-owned account in these words: “the agent uses a shared connection, so people running the agent do not need to authenticate during the run”, and advises “use a service account when possible”. This paper reads that as a connection a builder sets up and attaches to the agent, which does not meet the test in (a).

On (b), the observation has narrowed to deletion. None of the pages read describes editing a record of agent activity, or the customer deleting audit or compliance logs. Deletion by the customer is an ordinary data-protection control, and the observation concerns what the remaining records can prove.

On (c), none of the pages read describes such a record. The cloud browser in ChatGPT Work signs outbound HTTP requests under RFC 9421 so that website operators can “verify that requests genuinely originate from ChatGPT”. The signature identifies the platform and names neither an agent nor a delegation. Mistral’s audit-log page also states “Log export is not supported”, while its Admin API overview, in preview for Enterprise plans, lists audit logs among the resources it manages.

Five July details have changed. Mistral’s observability pages no longer describe exporting traces to the editable datasets cited in July. OpenAI has retired ChatGPT agent (“ChatGPT agent is no longer available”), although its page still carries the compliance-log exclusion cited above. The July text also described Mistral’s trace retention as operator-configurable. The current page states that traces are “kept for 30 days”, the July wording could not be re-verified, and this version drops that clause. Mistral’s audit-log page now records actions “across Studio and Vibe” and lists “Vibe interactions (conversation creation, deletion)” and API usage among logged events, and the current observability pages read do not describe per-event agent identifiers, so this version keeps both as July observations and does not carry them into the current findings.

OpenAI’s two pages on the agent-trigger API disagree. The developer reference documents a run identifier returned under an opt-in beta header, while the help page says the API “does not return a run ID”.

Sources for the update. OpenAI: learn.chatgpt.com/docs/enterprise (access-tokens, service-accounts), developers.openai.com (api/docs/changelog, the Agents API overview, quickstart and session-management guides, workspace-agents authentication and trigger-runs), help.openai.com articles 20001143, 11845367 and 11752874, and “Workspace agents security overview” (cdn.openai.com, current as of 29 April 2026). Anthropic: platform.claude.com/docs/en (manage-claude authentication, workload-identity-federation, compliance-activity-feed and inference-hooks, build-with-claude compaction-on-demand, managed-agents overview, session-operations and vaults, release-notes/overview, including the entry of 4 May 2026 on workload identity federation). Mistral: docs.mistral.ai (studio/observability, api/endpoint/beta/conversations, admin/monitor-comply/audit-logs/overview, admin/admin-api/overview, resources/changelogs) and mistral.ai/news/more-control-over-connectors. Outside the sample, read only to confirm the descriptions cited: learn.microsoft.com/en-us/entra/agent-id/what-are-agent-identities, docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity-terminology.html and cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol.

On the standards landscape. The layer above the cryptography is active and maturing: IETF WIMSE (no RFC yet, and since 15 September 2026 a working-group draft, AI Identity Management System, draft-ietf-wimse-aims-00, informational, which replaced the individual draft draft-klrc-aiagent-auth-00 of 2 March 2026), OAuth identity-chaining (approved, in the RFC Editor queue) and transaction-tokens (past working-group last call, awaiting write-up), MCP authorization (optional; beyond one SHOULD-level line that clients log tool usage for audit purposes, no requirements on log content, integrity or retention, and none on crypto-agility; the current revision, 2026-07-28, deprecates the logging utility and adds none), OWASP agentic guidance, CSA agentic IAM, and NIST’s NCCoE concept paper (5 February 2026, comments closed 2 April 2026). As of 22 September 2026 none addresses agent-credential crypto-agility. The WIMSE draft now requires tamper-evident agent audit records (section 11), as informational guidance that specifies neither the sealing mechanism nor how long its cryptography must hold. The gap this paper names is that specific layer, not agent security in general.

On prEN 18282. The statements about the AI Act’s cybersecurity standard describe the enquiry draft as circulated to national committees in May 2026 (prEN 18282:2026, CEN-CENELEC JTC 21, developed under the Commission’s AI standardisation request, first issued as M/593 (Implementing Decision C(2023) 3215) and reissued as M/613 by Implementing Decision C(2025) 3871 final of 23 June 2025, which repealed and replaced it): scope and introduction place conventional ICT cybersecurity out of scope, threats related to generative AI models are one subclause of the measures clause (10.6), and agents appear only as an example interface in the scope definition (6.2). Cryptography appears only as examples or single actions: signatures among example integrity mechanisms for datasets (10.1.1), cryptographic or equivalent methods for verifying model integrity (10.2.1.2), “cryptographic protection” among example measures for confidential assets (10.4.1.1) and replacement of compromised credentials or keys after a confidentiality incident (10.4.4). No clause addresses key management as a lifecycle, algorithm lifecycle, or cryptographic agility. The European enquiry closed on 30 July 2026, per standards trackers, which listed the draft at the close-of-enquiry stage (CEN stage 40.60) in September 2026. The observation describes the enquiry draft and may not hold for the published EN. The author filed comments in the French national enquiry on this draft.

What changed in version 2 (September 2026). Version 1 was published on 15 July 2026. This version corrects how DORA and NIS2 apply to financial entities, fixes article wordings, dates and references, and adds the logging, identification and certificate provisions of the RTS on ICT risk management. It updates statuses that moved after July, including the publication of the Digital Omnibus on AI as Regulation (EU) 2026/1744, the July 2026 MCP revision, IETF work and French transposition. It limits the platform finding to the three platforms reviewed and adds a dated September 2026 update on them. It defines its two main terms, removes an unused appendix note on demand and tightens the prose. The central argument is unchanged.

About the author

Amin Hasbini is an AI and cybersecurity executive and former director of Kaspersky’s Global Research and Analysis Team for the META region. He works on post-quantum maturity and AI agent security. This is the third paper in Series II, PQC for AI Agents, following The Channel Question and The Agility Question . mahasbini.org