Research · regulatory crosswalk · machine-readable evidence

A crosswalk you can execute.

Prose crosswalks between the OWASP Agentic Top 10 and the EU AI Act exist, and several still quote a deadline that was moved. This one ships as a SARIF file: the mapping lives in taxonomies and relationships, so an auditor filters on it rather than reading it.

Published 30.08.2026 · ~11 min · class: crosswalk · status: reference artifact

Download reference SARIF 57 KB · SARIF 2.1.0 · validated against the OASIS schema

TL;DR

Article 13 and Article 15 are not enforceable today. Regulation (EU) 2026/1744 moved Annex III high-risk duties to 2 December 2027 and Annex I to 2 August 2028.
Three obligations cannot be met by a document: Art. 12 (logs), Art. 15(4)–(5) (resilience) and Art. 13(3)(b)(ii) (the declared tested level). Everything else is satisfiable on paper.
Art. 13(3)(b)(ii) is the one nobody maps. It asks what you tested and where the tested level stops holding — a coverage statement, not a security claim.
SARIF 2.1.0 has native taxonomies support and almost nobody uses it. Two taxonomies, bound per rule, put the crosswalk inside the report.
A probe that could not run is emitted as notApplicable with a reason, never dropped. The schema enforces this: when kind is not fail, level must be none.

What applies, and when.

The Digital Omnibus on AI was signed on 8 July 2026, published in the Official Journal on 24 July and entered into force on 27 July — three days after publication rather than the usual twenty, because 2 August was too close to leave the text hanging.

2 Aug 2026 Art. 50 transparency, AI Office enforcement over GPAI, penalty regime in force

2 Dec 2026 Art. 50(2) machine-readable marking for systems already on the market pending

2 Dec 2027 Annex III standalone high-risk: Art. 9-15, Art. 26 deferred

2 Aug 2028 Annex I high-risk embedded in regulated products deferred

The deferral is narrow. Article 50, the AI Office's enforcement powers over general-purpose AI, and the penalty regime were not postponed. A vendor telling you the high-risk deadline passed this month is reading a page written before May.

Obligations that need an execution record.

These four cannot be satisfied by design documentation. Something has to have run, and the run has to have left a record. Cells marked with a rule are the bindings the reference SARIF actually declares in relationships[]; the rest are readings this page argues for but the file does not assert.

Category Art. 12Art. 13(3)(b)Art. 13(3)(b)(ii)Art. 15(4)Art. 15(5)

ASI01 Agent Goal Hijack plan trace per step—injection classes tested—payload, altered plan, tool reached

ASI02 Tool Misuse call log with policy id—tool scope tested—args outside granted scope

ASI03 Identity & Privilege Abuse identity at each hop—delegation depth tested—exercised scope exceeds grant

ASI04 Agentic Supply Chain resolution record at run timecomponent inventorypinned vs unpinned tested—unpinned resolution

ASI05 Unexpected Code Execution exec and egress events—sandbox profile testedfail-safe on breachegress under deny-default

ASI06 Memory & Context Poisoning writes with provenance—retention window testedfeedback-loop controluntrusted write, later read

ASI07 Insecure Inter-Agent Comms per-message verify outcome—transports tested—payload unbound from sender

ASI08 Cascading Failures propagation path—topology testedcontainment depth—

ASI09 Human-Agent Trust Exploitation approval with render digest—surfaces tested——

ASI10 Rogue Agents observed vs registered identities—inventory scope tested——

The two Article 13 columns are different obligations, not one split for width. Art. 13(3)(b) is the disclosure of what the system is and what it cannot do. Art. 13(3)(b)(ii) is narrower and harder: the level of accuracy, robustness and cybersecurity the system was actually tested against, plus the circumstances that degrade it. Only the second is a coverage statement, and only the second is falsifiable from a report file.

declared in the reference SARIF · — no meaningful binding

Obligations satisfied by programme.

Risk management, oversight design, deployer duties and post-market monitoring. Existing crosswalks lean almost entirely on this half, which is why they read as governance checklists. It matters, and none of it is falsifiable from a report file alone.

Category Art. 9Art. 13(1)Art. 14(4)Art. 26(5)Art. 72

ASI01 goal deviation in register—interrupt before tool call—recurrence after model change

ASI02 tool inventory risk—gate on irreversible actionsdeployer allowlistnew tools after update

ASI03 privilege model documented——credential scoping—

ASI04 third-party component riskcomponent list to deployer——drift after deployment

ASI05 execution surface——runtime isolation in scope—

ASI06 durable-state riskmemory behaviour disclosed——cross-session persistence

ASI07 trust boundary between agents————

ASI08 blast radius—kill switch reachable—serious incident, Art. 73

ASI09 —output interpretableautomation biasoperator instructedapproval defects

ASI10 ———monitoring per instructionsobserved vs registered over time

One binding in the file has no column here. ASI09 also relates to Article 50(1), the duty to inform a person that they are interacting with an AI system. It sits outside both tables because it is a transparency duty owed by every provider, not a high-risk obligation under Chapter III — and it is the only article in this entire crosswalk that is enforceable today.

The mapping belongs in the file.

SARIF 2.1.0 carries taxonomy support that almost no tool uses. runs[].taxonomies[] holds tool components, each with a taxa[] array; rules and results point back at them through relationships[] and taxa[], with kinds drawn from superset, subset, equal, relevant and incomparable.

That is enough for two taxonomies in one file — OWASP ASI 2026 and the Act as amended — bound per rule. The reader does not take the tool author's word for which obligation a finding serves. It sits next to the result and survives ingestion into whatever platform consumes it.

"relationships": [
  { "target": { "id": "ASI01", "index": 0,
                "toolComponent": { "index": 0 } },
    "kinds": ["subset"] },
  { "target": { "id": "Art.15(5)", "index": 7,
                "toolComponent": { "index": 1 } },
    "kinds": ["relevant"] }
]

The kinds are chosen, not decorative. A single probe is a subset of an ASI category, never equal to it — claiming otherwise would assert that one check covers a whole risk class. The article binding is relevant, the weakest kind available, because evidence serving an obligation is not the same as meeting it.

The Article taxonomy is marked isComprehensive: false. Eleven provisions are referenced; the Act has many more. The ASI taxonomy is marked comprehensive, because all ten categories are present.

A probe that could not run is reported.

The default behaviour of a scanner whose probe fails to execute is to emit nothing. The report comes back clean, and it is clean because that area was never tested. Nothing in the output distinguishes the two states.

Article 13(3)(b)(ii) is written against exactly this. You must declare the level you tested to and the circumstances that affect it. A silently skipped probe makes the declaration false without anyone noticing, including you.

{
  "ruleId": "MST.ASI07.a2a.signature-verify",
  "kind": "notApplicable",
  "level": "none",
  "message": { "text": "Probe did not execute: no A2A transport
    reachable after 3 attempts. ASI07 coverage is zero." },
  "properties": { "gap": {
    "reason": "transport-unreachable",
    "coverage": "none",
    "affectedObligations": ["Art.15(5)", "Art.12"] } }
}

The "level": "none" is not stylistic. SARIF requires that when kind is anything other than fail, a present level must be none. A gap cannot be dressed up as a passing check — honesty enforced by a schema rather than by discipline.

The reference file carries two gaps, and they are not the same kind of thing. ASI07 is transport-unreachable: the probe was applicable and failed to run, so coverage is unknown. ASI08 is topology-out-of-scope: a single-agent deployment has no downstream boundary to test, so the absence of a finding is a property of the architecture, not evidence about the controls. Collapsing these two into one "skipped" state is how a coverage claim quietly becomes untrue.

What this is not.

A SARIF relationship expresses one reading of the mapping. Conformity is determined by notified bodies against harmonised standards, and a scanner is not one. The file says so in runs[].properties.disclaimer, because a document that can be mistaken for a conformity assessment eventually will be.

The Article 15(2) benchmarks do not exist for agentic systems. CEN-CENELEC JTC 21 is still working. Until that lands, a declared tested level is self-declared, and worth precisely the evidence attached to it — which is the whole argument for making the evidence machine-readable now rather than in December 2027.

The mapping is many-to-many in both directions. Article 15(5) is implicated by eight of the ten categories; ASI08 touches Articles 15(4) and 9 at once. Any crosswalk claiming one-to-one is lying by simplification, and the tables above collapse detail to stay readable.

Finally, the direction of inference. The ASI list is a security taxonomy, not a compliance taxonomy. A clean run does not establish conformity and a failing one does not establish a breach. Confusing the two is the most common error in this space, and it is usually made by whoever is selling the scanner.

Blog · the argument in short Approved, Not Shown · ASI09 Signed, Not Safe · ASI07 ASI01–ASI10 coverage