The Evidence Question

TL;DR

• The obligations already reach agents. DORA and NIS2 never use the word agent, but both are technology-neutral. An AI agent a bank runs is an ICT asset under DORA and part of a network and information system under NIS2: the entity’s existing duties absorb it the moment it goes live, no future agent-specific rule required.

• 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. These are not future asks. DORA has applied since 17 January 2025.

• Where the answer isn’t. Across the three publicly documented platforms, OpenAI, Anthropic, and Mistral, agent-level identifiers and traces have started to arrive, most of it beta or enterprise-gated, shipped in the last few months. 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 immutable, others deletable or editable, and none is documented as carrying an independently verifiable seal over the action and the authority it was taken under. The org can prove who holds the key. It cannot, from the platform alone, prove 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, the signature’s continued validity is a load-bearing dependency of that evidence. 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 the standards bodies have already sketched. That is the crypto-agility question, arriving through the compliance door.

• The instruments do not name it, and that is the point. Neither DORA nor NIS2 requires agent identity, agent audit trails, or post-quantum cryptography by name. They require outcomes, and they leave the mechanism to the operator. The mechanism, for agents, does not yet exist at the layer the obligation lands on.

An inspection, 2027

A supervisor sits across from the CISO of a regulated financial entity. Not a hypothetical one: the DORA oversight framework for critical ICT third-party providers has begun operating, financial entities are running their first threat-led penetration tests, and NIS2 gives national authorities the power to demand evidence of implementation from essential entities. The supervisor has read that the entity runs AI agents in its operations. The questions are ordinary supervision, translated to a new kind of actor. The scene is a composite: 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. The questions, though, are each drawn from a duty already in force.

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. What the platform running the agents provides, though, attaches one level up from the actor in question: to the API credential the organisation holds, and to the organisation itself. The supervisor asked about the agent. The evidence is about the key.

This is the evidence question. The duties and supervisory powers that carry these questions are already in force, exercised where relevant and proportionate. The layer that would answer them at the granularity of the agent, and keep the answer durable, is the layer the migration never reached.

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. It is, or forms part of, an ICT asset. Nothing about the definition waits for the word agent. And the duties that attach to ICT assets are not aspirational: 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 devices processing digital data. (Directive (EU) 2022/2555, Article 6, point 1.) An agentic system processing data inside an essential 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).) The obligation attaches to the entity’s systems, and the agent runs inside them.

Neither instrument says agent. Both reach the agent through definitions written to be neutral.

Precision is the whole argument here. 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 says nothing about the quantum transition. (Article 21(2), point h.) A claim that these instruments require post-quantum cryptography for agents is an overclaim and does not survive contact with the text. The honest and stronger argument runs the other way. The instruments require outcomes, technology-neutral and risk-proportionate, and they leave the mechanism to the operator. For agents, that mechanism is not yet a consistent platform primitive; 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 today 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, even though DORA prescribes no such per-asset cryptographic fields by name. Paper II.2 named this instrument: an inventory that has no concept of the agent cannot list the agent’s cryptography, so the agent’s crypto is never a line anyone can miss. The obligation to inventory is old. The agent is the asset the inventory tools cannot yet see.

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 requires multi-factor or, where appropriate, continuous authentication (point j). Applied to an agent, these are exact questions. What is this agent allowed to touch, how is that limited, and how does it prove 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 it lists continuous authentication among the solutions to be used where appropriate; applying that control model to an agent is the natural risk-based reading, and the platforms still answer it at the credential above the agent.

Evidence. This is the load-bearing family. 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. (Articles 10, 17 and 19.) NIS2 requires a three-stage incident cascade, 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 entities the power to demand evidence of implementation of the security policies. (Articles 23 and 32.) Those duties presuppose 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, the enterprise has spent thirty years building that record. For an agent, the platform record does not by itself carry it.

Where the evidence isn’t, from the public record

The gap is not a matter of opinion, and it does not require anyone’s confidential roadmap to establish. It is visible in the vendors’ own public documentation.

The picture is moving, and being exact about it strengthens the point rather than weakening it. OpenAI’s workspace product now 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 states that individual agent actions do not appear in compliance logs even where the conversation does, the agent-trigger API returns no run identifier, 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 record which end user an agent acted for; every endpoint still authenticates with the organisation’s workspace key, the sessions and their event records are deletable by the operator, and nothing in the documentation describes a signed or tamper-evident record. 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 its enterprise observability surface records per-event agent identifiers, invoked tools and correlation identifiers; those records export into editable datasets, the organisation audit log covers administrative events, not agent invocations, and does not support export, and retention is operator-configurable down to deletion.

Read together, the pattern is consistent and precisely stateable. The platforms are racing toward the agent layer, 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; the agent identifier names a configuration, not an authenticated principal, and no reviewed surface documents an independently verifiable binding between the complete action record, the agent execution and the authority under which it acted. And the agent-level records do not carry consistent evidence properties: some surfaces are described as immutable, others are editable or deletable at the operator’s discretion, 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. This is not an accusation that the platforms provide no controls; the controls are real and improving by the quarter. It is a structural observation about what kind of object they produce. The organisation can prove it holds the key. It cannot, from the platform alone, hand a supervisor a tamper-evident record that this agent took this action on the delegated authority of that principal, in a form that reads as evidence rather than as telemetry the operator can edit.

The supervisor asks about the agent and the authority. The platform answers about the organisation and the key.

Logs are not automatically evidence. Telemetry keyed by a workflow name a developer chose, editable in a dataset or deletable with its session, is not yet an attributable, tamper-evident record of a regulated action. What turns a log into evidence is a set of properties, not a format: 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 platforms’ shared-responsibility line leaves it there; the enterprise toolchain for it exists, workload identity, external signing, immutable log pipelines, and mature entities already run it. That distinction is the point, and it is one a supervisor knows how to draw. And several of the properties on the list, integrity, trusted time, durable attribution, depend materially on cryptographic mechanisms, alongside governance and chain-of-custody controls. What those mechanisms sign with, and how their signatures age, is where this goes next.

The part underneath: agent evidence is a cryptographic artifact

Push one layer further and the compliance question becomes a cryptographic one. The record an agent leaves, the receipt of what it did that an auditor will read after the fact, draws its integrity and its attribution from cryptographic mechanisms: signatures, timestamps, hash chains. Where a signature is what establishes that a record is authentic and attributable, the continued validity of that signature becomes a load-bearing dependency of the evidence. If it is a fixed classical scheme, chosen not by the entity but inherited from a framework or a library, then the evidence a regulator will read years from now is being written today on cryptography with a published deprecation horizon.

Policy has begun to say this out loud, and from an unexpected direction. 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. The separation is the substance. Signature cryptography, what makes a record attributable, is treated as a distinct migration from the key establishment that protects a channel, and given a later, separate 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 done the first half of a program and called it finished.

The binding language in regulated finance already frames this as agility rather than a one-time move. The DORA technical standard requires the policy on cryptographic controls to provide for updating the cryptographic technology on the basis of developments in cryptanalysis. (Commission Delegated Regulation (EU) 2024/1774, Article 6(4).) The duty is to keep the capability to change, not to deploy a named algorithm. 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, because the inventory tool has no concept of the agent.

The supervisor has now said it to the banks directly. 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 reads the compressed path from vulnerability discovery to exploitation as a long-term shift in the landscape, places responsibility with the management body, and requires a concrete action plan, with roles, resources and timelines, submitted to each bank’s supervisory team by 31 October 2026. It closes on the other clock: post-quantum adoption “may involve a longer time frame, but must start now,” with a dedicated supervisory letter on quantum risk announced for due course. One supervisory document, addressed to the executive who signs the evidence, carrying both the operational present of AI and the cryptographic horizon under it.

A crowded policy layer over an empty substrate

It would be wrong to claim a standards void. The layer above the cryptography is busy. The IETF’s workload identity work is active, though it has published no RFC and its object is workloads rather than agents. The OAuth identity-chaining specification has been approved for publication and sits in the RFC Editor queue, and the transaction-tokens draft is in working-group last call. The Model Context Protocol defines an authorization pattern, though it is optional, and the specification sets no requirements for audit logging, evidence retention, or cryptographic agility; the release candidate for its next revision, issued in May 2026 ahead of final publication in late July, refines the OAuth mechanics and, in the release candidate at least, adds nothing on any of the three. Community and industry guidance has arrived in volume: OWASP’s agentic top ten, the Cloud Security Alliance’s agentic identity work, and a NIST NCCoE project on software and AI agent identity and authorization opened for comment in early 2026.

The European AI Act’s own cybersecurity standard makes the pattern concrete, and it is worth being exact because the text is being settled now. 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 period running into late July. The enquiry draft is deliberate about its perimeter: conventional ICT cybersecurity is out of scope, generative and agentic behaviour is addressed in a single subclause, and cryptography surfaces exactly once, as “cryptographic protection” listed among example measures for confidential assets. No key management requirement, no algorithm lifecycle, no agility duty. The standard drafted to ground the presumption of cybersecurity conformity for high-risk AI in Europe, as circulated for enquiry, does not reach the cryptographic substrate its systems run on; if adopted and cited in the Official Journal, the presumption will cover the provisions the standard contains, and this layer is not among them. That is not a criticism of the drafters; it is the same perimeter decision every layer of this stack has made, and it leaves the substrate where the other layers left it: to the operator.

The map is consistent. The policy layer, who the agent is, what it may do, how delegation is expressed, is crowded and maturing. The cryptographic substrate underneath it, the agility of the credentials and receipts that keep any of that policy durable and give any of that evidence its weight, is where the work is not. That is not a void. It is a specific, locatable gap, and unlike most gaps in this field it is measurable, because it is an inventory problem with a regulatory clock attached.

A note on the third instrument, because commentary keeps getting it wrong. The EU AI Act is the slow edge here, not the fast one. It does not define an AI agent; the Commission’s own guidance states that agents are not a separate category under the Act. And its high-risk obligations, including its logging and log-retention duties, are being deferred by the Digital Omnibus on AI, approved by the Council on 29 June 2026 and awaiting publication in the Official Journal as of this paper’s date; once in force, it moves the bulk of the high-risk regime to December 2027 and August 2028. The instrument that names AI most directly is the one whose hard obligations are furthest away. DORA, which never says agent, is the one applying now. Lead with the edge that is live.

Five things to do Monday

The five-step starting point, for the week the supervisor could walk in.

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.

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; 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.

4. Put agent credentials and receipts on the crypto-agility program, not off to the side. The DORA technical standard’s duty to keep cryptography changeable 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 are further out than the headlines say, at the end of 2027 and beyond. The live edges are DORA and, where transposed, NIS2. The ECB’s July 2026 letter to bank CEOs, action plans due by the end of October and a quantum letter announced, is what the running clock looks like. Plan against the clock that is running, not the one that just slipped.

Paper 3 of the PQC for AI Agents series, and the one where the model meets the supervisor. It reads DORA and NIS2 against how agents are actually run and finds the gap in one place: agent telemetry is arriving, but identity still authenticates at the credential, and no platform hands the entity durable evidence of what an agent did under whose authority. The audit question itself was opened in Series I’s Auditing Agents Under NIS2, DORA, and the EU AI Act in May; this paper is that question re-read against the platforms and the supervisors of July 2026. That closes the arc the series opened at the channel .

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. The crypto-agility duty is Article 6(4) of the technical standard, Commission Delegated Regulation (EU) 2024/1774. NIS2 is Directive (EU) 2022/2555, transposed by Member States from 18 October 2024; the system definition is Article 6(1), the minimum measures Article 21(2), management accountability Article 20, the incident cascade Article 23 (a twenty-four-hour early warning, a seventy-two-hour notification, and a final report within one month of the notification, not a single twenty-four-hour report), and the evidence-of-implementation power Article 32(2)(g). Neither instrument names AI agents, autonomous 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.

On transposition. NIS2 obligations bind through national law. Several Member States, France among them, had not transposed as of mid-2026; France’s transposing bill (résilience des infrastructures critiques et renforcement de la cybersécurité) was adopted by the Sénat in March 2025 and was still before the Assemblée nationale as of July 2026. Do not describe NIS2 as applying uniformly across the Union today; describe it as applying where transposed.

On the DORA supervision scene. The scene’s anchors are verified: the ESAs designated the first critical ICT third-party providers on 18 November 2025 and have begun oversight engagement, 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 requires an action plan 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. As of this paper’s date the announced quantum letter had not been issued; do not cite it as existing until it is.

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. Verified against the Federal Register text, July 2026. The deadlines are scoped to those system classes and the 2031 clause covers digital signatures; the point the paper rests on is the policy-level separation of signatures from key establishment, not a US compliance obligation on European entities.

On the AI Act dates. The general application date of 2 August 2026 for Regulation (EU) 2024/1689 does not carry the high-risk regime. The Digital Omnibus on AI, endorsed by the European Parliament on 16 June 2026 and given final approval by the Council on 29 June 2026, will move, once published in the Official Journal and in force, stand-alone (Annex III) high-risk obligations to 2 December 2027 and product-embedded (Annex I) ones to 2 August 2028; as of this paper’s date it awaited publication, expected before 2 August 2026. Article 12 logging and the Article 26(6) six-month deployer log-retention duty move with that regime. The Commission’s AI Act Service Desk confirms agents are not a separate category under the Act. Cite the Omnibus for the deferred dates, not the base regulation.

On the platform evidence gap. The observation is drawn from public vendor documentation, accessed 12 July 2026, across both product and API surfaces, and it is scoped precisely because the surfaces differ. 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 agent-mode documentation 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, 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, workload identity federation (generally available June 2026) and Compliance API. Mistral: the Agents API assigns first-class agent identifiers with versions and aliases, and the enterprise observability surface records per-event agent identifiers and invoked tools, exporting into editable datasets, with the organisation audit log covering administrative events without export support. 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. It is not a claim that the platforms provide no controls or no agent-level features, and it should not be restated as one. Feature sets are moving quarterly; re-verify against the live documentation before relying on any single detail.

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). Product surfaces and wording change frequently; the archived copies of record are held by the author.

On the demand signal. Independent sources point the same way without being merged into a single number. IBM’s Cost of a Data Breach 2025 found that organisations with high levels of shadow AI saw an average of 670,000 dollars in higher breach costs than those with low or none, and that one in five organisations reported a breach attributable to shadow AI. A SailPoint vendor survey and a Gartner prediction (November 2025: by 2030, more than forty percent of global organisations will suffer security and compliance incidents due to the use of unauthorised AI tools) indicate the same direction of travel; label each as what it is, a vendor survey and a prediction, not a measurement.

On the standards landscape. The layer above the cryptography is active and maturing, not empty: IETF WIMSE (no RFC yet), OAuth identity-chaining (approved, in the RFC Editor queue) and transaction-tokens (working-group last call), MCP authorization (optional; no audit, retention or crypto-agility requirements; the release candidate for the 2026-07-28 revision, issued 21 May 2026 with final publication scheduled after this paper’s date, refines OAuth mechanics and adds no identified evidence or agility requirements; re-verify against the final text once published), OWASP agentic guidance, CSA agentic IAM, and NIST’s NCCoE concept project. None as of mid-2026 addresses agent-credential crypto-agility or audit-grade, tamper-evident agent evidence. 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 standardization request M/C(2023)3215): scope and introduction place conventional ICT cybersecurity out of scope, threats related to generative AI models are one subclause of the measures clause, and beyond a single listing of “cryptographic protection” among example measures for confidential assets (10.4.1.1), no clause addresses key management, algorithm lifecycle, or cryptographic agility. The text is under enquiry and can change at comment resolution; check the standard’s status before relying on this observation, and do not restate it against the published EN without re-reading that text. The author filed comments in the French national enquiry on this draft.

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, following The Channel Question and The Agility Question . mahasbini.org