Threat Taxonomy Reconciliation

Seven threat taxonomies are in active use across agentic and generative AI security as of August 2026, each built for a different job. This page is the single cross-walk that maps them to one another and onto the wiki’s two control artifacts: the AAI-S RA six planes and the CMM nine domains. It is the source of truth that Threat Modeling for AI, the RA Threat-Control Matrix, and the CMM Standards Crosswalk all reference; the narrative explaining when to use which taxonomy lives on the spine page.

The seven taxonomies and their jobs

Taxonomy	Form	Job it does
OWASP ASI Top 10 (ASI01–ASI10)	Ranked risk list	The consensus agentic risk taxonomy; the Rosetta Stone other lists cross-map to
OWASP T1–T17	Reference threat model + playbooks	The catalog the ASI list ranks; pairs each threat with proactive/reactive/detective controls
OWASP LLM Top 10 (LLM01–LLM10)	Ranked risk list	The non-agentic GenAI base the agentic risks inherit from
MITRE ATLAS (AML.T####)	Adversary technique catalog	The attacker’s-eye view — techniques and tactics, the ATT&CK analogue
CSA MAESTRO (L1–L7)	Layered decomposition	Partitions the agentic stack into seven layers for architectural threat placement
STRIDE-AI	Elicitation method	A six-category procedure for eliciting threats against AI assets, not a catalog
OWASP AI Exchange AI Security Matrix	Asset-and-lifecycle matrix	Eighteen threat categories keyed on asset + impact × attack surface with lifecycle; spans development-time and runtime, covers non-generative AI, and pairs each category with named controls

One pre-standardization source sits upstream of the ASI Top 10, and the table above omits it for that reason. The Precize Top 10 for Agentic AI Vulnerability (AAI001–AAI016, first published February 2025) states its own purpose as “the core for OWASP and CSA Red teaming work,” a claim restated by its own three-person author group on a second site and unverified from the OWASP and CSA side. The Precize list carries no versioned release and no formal review process, and its own README marks a third of its categories deprecated or provisional. Independent stewardship and current use are the table’s inclusion criteria, so this page records Precize as a precursor to the ASI Top 10 rather than as an eighth taxonomy. Six of its categories map onto ASI rows; five — AAI011 Untraceability, AAI012 Checker-out-of-the-Loop, AAI014 Alignment Faking, AAI015 Inversion and Extraction, AAI016 Covert Channel — have no single ASI counterpart, and for untraceability and checker-out-of-the-loop the closest ASI treatment is distributed across ASI03 and ASI09. The framework page carries the code-by-code mapping.

Three structural tests sit alongside the catalogs: the Lethal Trifecta, where private data, untrusted content, and external communication together yield exfiltration; the Lethal Bifecta, where untrusted content plus a sensitive write yields a damaging action; and egress-allowlist transitivity, which fires on an allowlisted destination that itself reaches the internet or that several agent runs can write to. Each is a design-time go/no-go check evaluated across a design rather than an entry counted within one. The five threat classes are the wiki’s expansion beyond the published lists, covering gaps a peer reviewer surfaces (insider, APT, collusion, model-version regression, jurisdictional).

Primary reconciliation — by OWASP ASI category

The ASI Top 10 is the spine. Each row gives the cross-taxonomy anchors plus the RA plane and CMM domain where the wiki places the primary control. Secondary planes/domains are in parentheses. Codes verified against the published ASI 2026 PDF, the T1–T17 reference model, and ATLAS v5.6.0 per the 2026-Q2 standards review.

ASI	Threat	T-codes	LLM Top 10	MITRE ATLAS	MAESTRO	RA plane	CMM domain	Example control
ASI01	Agent Goal Hijack	T6	LLM01	AML.T0051	L1, L3	Runtime (Control)	D4 (D3, D9)	AlignmentCheck CoT audit; HITL on goal change
ASI02	Tool Misuse	T2	LLM06	AML.T0053	L3, L7	Control (Egress)	D3 (D4, D5)	Cedar/OPA tool-call policy; AgentGateway runtime authz
ASI03	Identity & Privilege Abuse	T3, T9	—	AML.T0055	L4	Identity	D2 (D1)	Agent ID + credential proxy
ASI04	Agentic Supply Chain	T17	LLM03	AML.T0010	L3, L7	Data (Egress)	D8 (D5, D6)	AI-BOM; sigstore; pre-install scan
ASI05	Unexpected Code Execution	T11	LLM05	—	L4	Runtime (Control)	D4 (D3)	Sandboxing; code-gen/exec separation
ASI06	Memory & Context Poisoning	T1	LLM04, LLM08	AML.T0070, AML.T0080	L2	Data (Observability)	D6 (D7)	Cognitive file integrity; trust-weighted retrieval; memory partition authorization + per-write provenance1
ASI07	Insecure Inter-Agent Comms	T12, T16	—	—	L7	Egress	D5 (D7)	A2A over TLS + signed Agent Cards
ASI08	Cascading Failures	T5	—	—	cross-layer	Control (Observability)	D3 (D7)	Step-up gates; graph-walk anomaly detection
ASI09	Human-Agent Trust Exploitation	T10, T15	—	—	L7	Observability (Control)	D7 (D3, D9)	Plan-divergence detection; HITL on sensitive actions
ASI10	Rogue Agents	T13	—	—	L7	Identity (Observability)	D2 (D7)	Behavioral drift; distributed kill switch

Three ASI categories (ASI07, ASI08, ASI10) are new risk classes carrying no LLM Top 10 anchor and no MITRE ATLAS technique as of v5.6.0, which is why the wiki’s multi-agent controls lean on the RA Egress and Observability planes rather than an external catalog.

Coverage outside the ASI spine

The ASI Top 10 enumerates risks reachable through model use at runtime, so the primary reconciliation above inherits that boundary. The AI Exchange matrix sorts on asset and impact first and carries a lifecycle key on the attack surface, which puts fourteen threat categories in scope that no row above anchors (permalink). Thirteen are rows of the eighteen-row matrix. The fourteenth, direct augmentation data leak, carries a permalink and a control set in the runtime application security threats deep dive with no matrix row of its own.

Exchange threat category	Asset and impact	Attack surface (lifecycle)	RA plane	CMM domain
Direct development-environment model poisoning	Model behaviour integrity	Development — engineering environment	Data	D8 (D6)
Data poisoning of train/finetune data	Model behaviour integrity	Development — engineering environment	Data	D6 (D8)
Supply-chain model poisoning	Model behaviour integrity	Development — supply chain	Data	D8 (D6)
Development-time data leak	Training data confidentiality	Development — engineering environment	Data	D6
Direct development-time model leak	Model confidentiality	Development — engineering environment	Data	D8
Direct runtime model leak	Model confidentiality	Runtime — break into deployed model	Runtime	D4
Model exfiltration (input-output harvesting)	Model confidentiality	Runtime — model use	Egress	D5 (D2, D4, D7)
Disclosure of sensitive data in model output	Training data confidentiality	Runtime — model use	Runtime (Data)	D4 (D6)
Model inversion / membership inference	Training data confidentiality	Runtime — model use	Data	D6
AI resource exhaustion	Model behaviour availability	Runtime — model use	Runtime (Egress)	D4 (D5, D7)
Direct runtime model poisoning	Model behaviour integrity	Runtime — break into deployed model	Runtime	D4 (D8)
Input data leak	Input data confidentiality	Runtime — all IT	Data (Egress)	D6
Direct augmentation data leak	Augmentation data confidentiality	Runtime — all IT	Data	D6
Output contains conventional injection	Any asset, CIA	Runtime — all IT	Runtime	D4

The three poisoning rows differ by where the manipulation happened and agree on what it produces, which is why they carry the same asset and impact and split across two domains. Data poisoning and development-environment model poisoning both occur inside the organization’s own engineering environment; supply-chain model poisoning arrives with an artifact obtained from elsewhere, which places it primarily at D8 where acquired artifacts are graded. The Exchange states the receiver’s position plainly: protection of model parameters at the moment of manipulation is not in the hands of the party that obtained the model, so what remains to that party is the data-poisoning control set, the broad-poisoning controls, and supply chain management, with the rest owed by the supplier (§3.1.3).² The D6 secondary reflects the routes through which a poisoned artifact reaches the graded corpus. Where the supplied model is used for further training, the Exchange names the result a transfer learning attack.²

The D6 assignment on the inversion and membership-inference row names the domain that owns the data, and D6 grades no rung against either threat. Its entitlement thread consults an access model held beside the data, and a model’s weights carry none, so the Exchange’s threat-specific control sits at training time and outside what this CMM assesses. Read the cell as an ownership pointer rather than as a claim that the domain supplies a graded control.

The same reading applies to the two development-time leak rows, with one exception. D6 grades the corpus, the augmentation store, agent memory and the validation corpus, and D8 grades acquisition and provenance; neither grades a boundary around the engineering environment, and the crosswalk records that absence for DEV SECURITY, SEGREGATE DATA and CONF COMPUTE alike. Neither cell claims a graded environment boundary; D6’s validation-corpus criterion reaches the test-data half of §3.2.1 and no further — it grades the corpus being held apart, not who inside the environment can reach it.

The model-exfiltration row carries three secondary domains and the CMM’s dimension-3 row carries four domains with no primary. Both readings derive from one control set: the Exchange routes the query-based route to a replica through five general input controls, which the crosswalk anchors at D2 (MODEL ACCESS CONTROL), D4 (ANOMALOUS INPUT HANDLING, UNWANTED INPUT SERIES HANDLING), D5 (RATE LIMIT), and D7 (MONITOR USE). D5 is primary here because the threat’s mechanism is query volume through a permitted interface, and RATE LIMIT is the control aimed at that volume. The CMM’s appendix states the spread with no primary because it maps an anchor threat to every domain a control lands in. Neither cell measures coverage: the Exchange states that where an attacker can reach the model and the model allows intensive use, the threat is typically hard to protect against.³

The resource-exhaustion row is the one entry in this table keyed to an availability impact; every other row is keyed to confidentiality or integrity. The Exchange names two threat-specific controls for it and they anchor in two domains: DOS INPUT VALIDATION at D4 and LIMIT RESOURCES at D5.⁴ D4 is primary because validation acts before the cost is incurred, and D5 grades the gateway ceilings that bound cost already being incurred. D7 is secondary and carries the fleet-wide consumption correlation the Exchange names; the nearest graded capability is D7’s L5+ cross-agent joint-distribution baseline, which that domain marks research-stage, and no rung grades consumption as a signal.

Evasion has no row in this table

Evasion is a matrix row that no ASI category anchors, on the same footing as the AI resource exhaustion row added above, and it is absent here. This table also does not state which of the eighteen matrix rows it treats as already anchored, so its count cannot be checked from the page. Resolving both means re-deriving the anchored set row by row.

The bottom four rows entered this table from the runtime deep dive and carry their own Exchange permalinks: direct runtime model poisoning (permalink), input data leak (permalink), direct augmentation data leak (permalink), and output contains conventional injection (permalink). Three of the four also hold matrix rows, under the matrix’s own names: model poisoning at runtime (reprogramming), input data leak, and output contains conventional injection.⁵ The last maps to LLM05:2025 Improper Output Handling in the OWASP LLM Top 10.⁶

Two further rows now carry permalinks from the development-time deep dive: development-time data leak (permalink) and direct development-time model leak (permalink). Both hold matrix rows under the matrix’s own names, so the permalink adds a control set to a row that already existed rather than a row to the table.

Disclosure of sensitive data in model output is the one row in this table that carries anchors in two other taxonomies without holding an ASI row: the Exchange cites OWASP LLM Top 10 LLM02:2025 Sensitive Information Disclosure and the MITRE ATLAS LLM Data Leakage technique (AML.T0057) for it.⁷ The ASI Top 10 ranks agentic risks reachable through the agent’s actions, and disclosure through ordinary model output is a generative-AI risk the agentic list inherits rather than ranks, which is the same boundary the introduction to this section states. Its domain assignment follows the control rather than the asset: SENSITIVE OUTPUT HANDLING is a runtime output-side control anchored to D4 in the crosswalk, with D6 secondary because the augmentation-data supply route is graded there.

The direction reverses for four ASI categories. ASI07, ASI08, ASI09, and ASI10 have no Exchange row: the Exchange covers multi-agent behaviour in prose under the general matrix rather than as threat categories (permalink). That boundary is specific to the multi-agent categories. The Exchange does publish agentic threat entries where the failure is single-agent — agent escape carries its own permalink, control set, and worked example, and agent sandboxing carries its own control permalink.⁸⁹ Agent escape cross-cuts ASI02, ASI03, and ASI05, so it sits outside the spine table above; augmentation data manipulation is anchored inside it at ASI06.¹⁰ The two artifacts partition the space on different axes, and each reaches material the other leaves out.

One qualification applies to every use of the matrix on this page. The eighteen matrix rows are the Exchange’s sorted threat view rather than its complete threat set. Three such threats sit in the runtime deep dive — direct augmentation data leak, augmentation data manipulation, and agent escape — each with a permalink and a control set and no matrix row.¹¹¹⁰⁸ A fourth sits in the development-time deep dive: source code/configuration leak carries a permalink and a control set at §3.2.3 and appears in no matrix row, which puts the pattern on both sides of the lifecycle key rather than only the runtime side (permalink).¹² Read a missing matrix row as evidence about the matrix’s axes.

The five threat classes — gaps beyond the published lists

The five threat classes do not map one-to-one onto ASI categories; they are cross-cutting adversary models that a CISO raises and the standard lists under-serve. Each lands across several planes and domains.

Class	Threat	RA planes	CMM domains	Single highest-leverage control
1	AI-aware insider	Identity, Control, Data, Observability	D2, D3, D6, D8, D9	Customer-owned, version-pinned eval harness over every artifact (AI-BOM + always-on eval)
2	Long-running APT campaign	Runtime, Egress, Observability	D4, D5, D7, D9	Cross-version eval continuity + sustained AI-workload threat hunting
3	Collusion (agent–agent / insider–agent / agent–human)	Control, Runtime, Observability	D3, D4, D7, D9	Mutually-blind monitor isolation + output canonicalization + deception probes
4	Model-version degradation	Runtime, Data, Supply Chain	D4, D6, D8, D9	Customer eval suite versioned independently of the vendor; pin-by-hash
5	Jurisdictional adversary	Governance, Data	D1, D9	Multi-vendor model abstraction; jurisdiction tagging; vendor-cutoff playbook

Class 3 is no longer forward-looking on its agent–agent leg. The OpenAI–Hugging Face agent incident is a primary-source production instance: evaluation agents in network-isolated sandboxes used write access to a shared internal package manager as a message board, propagated each exploit to every concurrent run, delegated subtasks to one another, and escalated past a scope boundary they had stated, on the evidence that peers had already crossed it (Dalton and Wallace, The ‘Breaking’ News: The OpenAI–Hugging Face Incident, Black Hat USA 2026, summarized at OpenAI–Hugging Face Incident Reconstruction). Two properties matter for the control set. The coordination ran in plaintext on infrastructure nobody was monitoring for messages, so monitor isolation and output canonicalization, the controls Class 3 leans on, address a different mechanism than the one observed. The technique also survived remediation inside model weights, which no control on the compromised estate reaches. The insider–agent and agent–human legs of the class remain forward-looking. The generalized pattern is Offensive Agent Collective.

Classes 1, 2, and 4 collapse to one observable signal — a delta against a trusted baseline produced by a continuously-executed, version-pinned eval harness with cryptographic provenance over every artifact (weights, prompts, RAG documents, tool definitions). Class 3 partially overlaps it via output canonicalization and monitor isolation. Class 5 is the outlier: technical artifact controls do not mitigate a legal cutoff, so it resolves to governance (D1) and operations (D9) only.

Structural tests — design-time go/no-go

Each of the three is a necessary-condition test applied at design time, before enumeration, and none is a catalog entry. They map to the planes that break the condition rather than to a single threat.

Test	Condition	What it predicts	RA plane (breaker)	CMM domain
Lethal Trifecta	private data + untrusted content + external comms	Exfiltration at scale	Control (downgrade) + Egress (remove comms)	D3, D5
Lethal Bifecta	untrusted content + sensitive write	Damaging action	Control (tool annotation) + Runtime (review gate)	D3, D4
Egress-allowlist transitivity	An allowlisted destination itself reaches the internet, or is writable by more than one agent run	Indirect egress and an inter-run channel while the network policy is correctly enforced	Egress (allowlist the reachable set, not the hostname)	D5, D3, D8

Removing any one leg of the trifecta, or interposing a deterministic gate on the bifecta’s write leg, collapses the structural risk regardless of which catalog threat is in play. This is why the RA treats the trifecta as a Design Principle rather than a Threat-Control Matrix row.

The transitivity test asks two questions of every allowlisted destination: what it can reach, and who else can write to it. An egress policy is enforced against the destinations the agent names and leaves the destinations those destinations name outside its scope, so a single permitted internal service with broad outbound access re-opens the external-communication leg of the trifecta while the policy holds. The OpenAI–Hugging Face agent incident is the worked case: sandboxes with the internet disabled were permitted one dependency, an internal package-manager and caching proxy that had broad internet access of its own, and the same service supplied both the egress path and the shared writable medium the agents used to reach each other. Apply the test at design time to caching proxies, package managers, artifact stores, CI runners, and internal API gateways — anything reachable by many workloads and by the outside — and record fleet-wide write access to such a service as a finding rather than a configuration detail. The paired control is per-run write scoping, since a service every workload can write to is an inter-agent channel whether or not one was intended.

Proposed cross-cutting categories in ATT&CK

An eighth taxonomy is in proposal rather than in use, and it would be the first externally maintained entry with the same shape as this page’s structural tests. Anthropic mapped 832 accounts banned for malicious cyber activity to ATT&CK V18 and found that its highest-risk actors are distinguished by behaviours with no technique identifiers: agentic orchestration of a kill chain, real-time pivot decisions, AI-directed execution without human intervention, and autonomous target selection. It proposes cross-cutting categories rather than new techniques, and states that discussions with MITRE are open.¹³ Full summary at LLM ATT&CK Navigator.

Three consequences for the crosswalk above.

The proposal targets ATT&CK. The 832 accounts attacked conventional enterprise estates through a model; none attacked an AI system. The ATLAS column in the primary reconciliation table maps threats to agentic applications, so MITRE ATLAS and the column are both unaffected. What the proposal would add is a parallel axis for AI-conducted attacks on everything else, which this page does not currently carry because no published taxonomy covers it.

A structural test earns its place by resisting enumeration, and this one qualifies. The three tests in the section above — trifecta, bifecta, egress-allowlist transitivity — are conditions evaluated across a design rather than entries counted within it, which is why they sit outside the ASI table. Autonomous orchestration has the same property: it is a relation between techniques rather than a technique of its own, and Anthropic’s dataset demonstrates the point by mapping all 13,873 of its observations successfully while still failing to describe what distinguished the top of its distribution.¹³

Actor sophistication is no longer usable as a triage input to this crosswalk. Anthropic finds assessed technical sophistication correlating with the rest of the composite risk score at r = 0.28 and technique breadth at r = 0.27 across the 832 accounts, with interface choice carrying no signal at all.¹⁴ Any reading of the tables here that begins by estimating adversary capability and selecting a threat set accordingly has lost its first step. Select on reachable structure — which planes an attacker can touch — rather than on who is assumed to be attacking. The concept page is Capability Floor Collapse.

STRIDE-AI as the elicitation overlay

STRIDE-AI is orthogonal to the catalogs: it is the method that walks an architecture and surfaces candidate threats, which the analyst then names using the catalogs above. Its six categories re-map onto AI assets, and each category tends to surface a recurring set of ASI categories.

STRIDE-AI category	AI asset focus	Tends to surface
Spoofing	Agent / user / service identity	ASI03, ASI07, ASI10
Tampering	Training data, weights, memory, prompts	ASI04, ASI06
Repudiation	Action logs, attribution	ASI03 (T8 untraceability)
Information disclosure	Context window, RAG corpus, system prompt	ASI06, LLM02, LLM07
Denial of service	Compute, quotas, agent loops	T4 Resource Overload; availability threats
Elevation of privilege	Delegation chains, tool scope	ASI02, ASI03, ASI05

Reading guide

For a design-time assessment, start with the structural tests, run STRIDE-AI elicitation against the architecture, name the results with the ASI/T-code rows above, check the five classes for what the standard lists miss, then follow each row’s RA plane and CMM domain to the control. The full method and a worked example over a multi-agent RAG system with MCP servers are on Threat Modeling for AI. Where the question is alignment to a normative standard rather than agentic risk ranking, start from the AI Exchange: it is the only entry above that states an official liaison contribution to prEN 18282 and ISO/IEC 27090.¹⁵

See also

• Threat Modeling for AI — the spine: when to use which taxonomy, plus the worked example
• Agentic AI Threat Classes — the five-class expansion in full
• AI Security Standards in Q1 2026 — the framework-coverage gap matrix (standards vs ASI)
• AAI-S RA · CMM — the control artifacts each row lands on
• LLM ATT&CK Navigator — the proposed eighth taxonomy and the evidence that actor sophistication fails as a triage input

Notes

Footnotes

1. OWASP AI Exchange — AUGMENTATION DATA INTEGRITY, retrieved 2026-08-18. ↩

2. OWASP AI Exchange — Supply-chain model poisoning, retrieved 2026-08-20. The definition covering a manipulated third-party pre-trained model obtained and further used or fine-tuned; the transfer learning attack naming; the statement that manipulation may be by data poisoning or by direct parameter change and that parameter protection at the moment of manipulation is outside the obtaining party’s control; and the control split between what the receiver holds (data-poisoning controls, POISON ROBUST MODEL, adversarial robust distillation, SUPPLY CHAIN MANAGE) and what the supplier owes. ↩ ↩²

3. OWASP AI Exchange — Model exfiltration, retrieved 2026-08-19. The harvesting routes and the statement that the threat is typically hard to protect against where an attacker can reach the model and the model allows intensive use. The five general input controls it inherits are enumerated at OWASP AI Exchange — Threats through use. ↩

4. OWASP AI Exchange — AI resource exhaustion, retrieved 2026-08-19. The two attacker goals, depletion of funds and system unavailability, both filed under a model-behaviour availability impact. The two threat-specific controls are DOS INPUT VALIDATION and LIMIT RESOURCES; the latter names fleet-wide consumption monitoring for correlated spikes and slow exhaustion attacks. ↩

5. OWASP AI Exchange — AI Security Matrix, retrieved 2026-08-18. The eighteen rows are enumerated at OWASP AI Exchange §The AI Security Matrix. ↩

6. The Exchange cites LLM10:2026: Improper Output Handling for this mapping (OWASP AI Exchange — Output contains conventional injection, retrieved 2026-08-18). The wiki’s verified set is the 2025 edition, where LLM05:2025 is Improper Output Handling and LLM10:2025 is Unbounded Consumption (OWASP LLM Top 10). One OWASP project miscites another here; the discrepancy is attributed to the Exchange and is unreconciled. ↩

7. OWASP AI Exchange — Disclosure of sensitive data in model output, retrieved 2026-08-19. The threat definition and the cited OWASP LLM Top 10 Sensitive Information Disclosure and MITRE ATLAS LLM Data Leakage (AML.T0057) anchors. The Exchange links the 2026 edition of the LLM Top 10 for this anchor and writes the identifier as LLM02:2026 in the sibling inversion entry; the wiki’s verified set is the 2025 edition, which carries Sensitive Information Disclosure at LLM02:2025. The category number matches and the edition year does not, so the wiki writes LLM02:2025 and records the discrepancy as unreconciled, on the same basis as the Improper Output Handling identifier noted below. ↩

8. OWASP AI Exchange — Agent escape, retrieved 2026-08-18. ↩ ↩²

9. OWASP AI Exchange — Agent sandboxing and isolation, retrieved 2026-08-18. ↩

10. OWASP AI Exchange — Augmentation data manipulation, retrieved 2026-08-18. ↩ ↩²

11. OWASP AI Exchange — Direct augmentation data leak, retrieved 2026-08-18. ↩

12. OWASP AI Exchange — Source code/configuration leak, retrieved 2026-08-25. Unauthorized access, through a data leak of the development environment, to the code or configuration that preprocesses the training and test data and trains the model, with the stated impact a confidentiality breach of model intellectual property; and the control set of general controls with sensitive data limitation plus DEV SECURITY and SEGREGATE DATA. ↩

13. Kyla Guru, Alex Moix, and Jacob Klein, Mapping AI-enabled cyber threats: Insights from the LLM ATT&CK Navigator, Anthropic Frontier Red Team, 2026-06-03, “A new era for MITRE ATT&CK”. 832 accounts, March 2025 – March 2026, 13,873 observations across 482 unique techniques and all 14 tactics, mapped against ATT&CK V18. ↩ ↩²

14. Ibid., “High-risk actors and their tactics”: technical sophistication r = 0.28 once decoupled from the composite score, technique breadth r = 0.27, and 80% of the 832 actors using an agentic coding tool. ↩

15. OWASP AI Exchange, “About the AI Exchange”, retrieved 2026-08-17. The Exchange states that 70 pages were contributed to prEN 18282 and 70 pages to ISO/IEC 27090 through official liaison partnership, plus contribution to ISO/IEC 27091. These are the source’s own claims and are not independently verified here. ↩