Threat Assessment (TA)

Vendors Domain - HAIAMM v3.5

Generated from the canonical cell records in cells/. Do not edit by hand; edit cells/TA-Vendors-L*.cell.json and re-run tools/render.py.

---

Practice Overview

Business Function: Building

Objective: Publish an archetype-level threat library for the Vendors domain, tagged to the HAI TTPs and MITRE ATLAS, so threat modelling starts from a reusable baseline rather than a blank page.

Description: A program at this level has written down what can go wrong with each vendors archetype, once, so that no team has to rediscover it. The library covers consumer generative AI, AI-embedded SaaS, AI coding assistant, AI API and foundation-model vendor, and AI agent or automation platform, and every entry carries a HAI TTP tag, an ATLAS technique where one applies, an OWASP LLM reference and the practice expected to address it. This is what makes threat modelling tractable at scale: a team adopting a known archetype inherits its threat model and spends its effort on what is genuinely novel about their case, rather than re-deriving prompt injection from first principles every time.

---

Maturity Level 1, Foundational

Objective: Publish an archetype-level threat library for the Vendors domain, tagged to the HAI TTPs and MITRE ATLAS, so threat modelling starts from a reusable baseline rather than a blank page.

A program at this level has written down what can go wrong with each vendors archetype, once, so that no team has to rediscover it. The library covers consumer generative AI, AI-embedded SaaS, AI coding assistant, AI API and foundation-model vendor, and AI agent or automation platform, and every entry carries a HAI TTP tag, an ATLAS technique where one applies, an OWASP LLM reference and the practice expected to address it. This is what makes threat modelling tractable at scale: a team adopting a known archetype inherits its threat model and spends its effort on what is genuinely novel about their case, rather than re-deriving prompt injection from first principles every time.

Dependencies

• Required: SM-Vendors-L1, PC-Vendors-L1
• Alignment (not blocking): Existing enterprise threat modelling practice, so AI threats extend the established method rather than introducing a second one
• Supports / unblocks: SR-Vendors-L1; SA-Vendors-L1; DR-Vendors-L1; ST-Vendors-L1; ML-Vendors-L1; IM-Vendors-L1; Required by: SM-Vendors-L2, TA-Vendors-L2

Desired Outcomes

• Every vendors archetype in the inventory has a published threat snapshot a team can adopt rather than author.
• Every threat entry carries a HAI TTP tag, an ATLAS technique where applicable, an OWASP reference and the practice expected to address it.
• The trust boundaries and entities of each archetype are drawn once and reused, rather than redrawn per team.
• A threat with no downstream treatment is visible as a gap rather than resting in a document.
• New archetypes entering the inventory get a threat snapshot within a defined window rather than when someone has time.

Activities

A) Build the archetype threat library

Author one threat snapshot per archetype covering consumer generative AI, AI-embedded SaaS, AI coding assistant, AI API and foundation-model vendor, and AI agent or automation platform. For each archetype, identify the entities and trust boundaries first, being the data the organisation sends, the vendor's processing, the sub-processor chain behind it, and the outputs returned into organisational workflows, because a threat list without a boundary model is a list of worries rather than an analysis. Then enumerate the threats that follow from those boundaries, which in this domain centre on AI features silently enabled inside an approved product, training-data terms changing at renewal, sub-processor chains extending past contractual reach, and a vendor model change altering behaviour the organisation had tested. Keep each snapshot to a length a team will actually read, targeting two pages, and write each threat as a concrete failure with a named precondition rather than as a risk category. Derive the snapshots from contracts, data processing agreements, vendor documentation and the vendor inventory and validate each with one practitioner who works on that archetype daily, because a threat library authored entirely by security will describe the system security imagines rather than the one that exists.

B) Tag every threat to the shared vocabulary

Tag each threat entry with the HAI TTP it expresses, being excessive agency, agent goal hijack, tool misuse or rogue agents; the MITRE ATLAS technique where a real one applies; the OWASP LLM 2025 reference; and the compliance obligation it bears on where relevant. Use only technique identifiers that genuinely exist, because a plausible but invented identifier is worse than none, it survives review and misleads everyone downstream. Where no ATLAS technique fits, record that explicitly rather than forcing the nearest match, and treat the gap as a candidate contribution at L3. The tagging is what makes the library composable with everything else: it lets monitoring ask which threats have detections, testing ask which have tests, and requirements ask which have controls, without any of them re-reading the prose.

C) Trace every threat to a treating practice and publish the gaps

For every threat in the library, name the practice expected to address it and the specific control, requirement, pattern, test or detection that does so. Then publish the gaps, which is the activity teams most often skip and the one that gives the library its value: a threat with no named treatment is an accepted risk whether or not anyone decided to accept it, and making that visible is the point of the exercise. Report the treatment-coverage rate to the sponsor quarterly and treat an untreated threat at a high-risk archetype as an open finding with an owner rather than as a line in a register. Establish a 30-day service level for producing a threat snapshot when a new archetype enters the inventory, and review the whole library at least quarterly against external threat intelligence.

Outcome Metrics (L1)

Metric	Baseline	L1 Target	Source
Vendors archetypes with a current published threat snapshot	first library build	≥90% of inventoried archetypes within 6 months	Threat library register joined to the asset inventory
Threat entries carrying a HAI TTP tag and, where applicable, a real ATLAS technique	first tagging pass	100%, with no invented technique identifiers	Threat library tag audit against the published ATLAS catalogue
Threats traced to a named treating practice and a specific control	first traceability pass	≥85%, with the untreated remainder published as gaps	Threat-to-treatment traceability matrix
Untreated threats at high-risk archetypes carrying an owner and a remediation date	first gap review	100%	Issue tracker joined to the threat library
New archetypes receiving a threat snapshot within 30 days of entering the inventory	first quarter of intake	≥90%	Threat library creation dates joined to inventory first-seen dates

Process Metrics (leading)

• Threat library reviewed quarterly against external intelligence, with the review date published.
• Each snapshot validated with a practitioner who works on that archetype, recorded per snapshot.
• New-archetype trigger fires from the inventory rather than relying on someone noticing.
• Treatment-coverage gaps reviewed monthly with the practices expected to close them.

Effectiveness Metrics (business value)

• Time to produce a usable threat model for a new asset falls, because the archetype snapshot is inherited rather than authored.
• Downstream practices cite threat identifiers directly, which indicates the library is being used rather than filed.
• Incidents traceable to a threat already in the library but untreated fall, which is the honest measure of whether gap publication changes behaviour.

Level of Effort (incremental over the level below)

• Stand-up: 150 hours · Ongoing: 70 hours/quarter
• Security Architect — primary, 26 days/year
• AppSec / SecEng — regular, 14 days/year
• AI/ML Engineer — regular, 10 days/year
• Program Manager / Practice Lead — low, 6 days/year

Success Criteria

• A threat snapshot exists for at least 90% of inventoried vendors archetypes, each opening with entities and trust boundaries rather than a threat list.
• Every threat entry carries a HAI TTP tag and, where applicable, a genuine ATLAS technique identifier, with no invented references.
• At least 85% of threats trace to a named treating practice and specific control, with the untreated remainder published as gaps rather than omitted.
• Untreated threats at high-risk archetypes carry an owner and a remediation date.
• A 30-day snapshot service level operates for new archetypes, triggered from the inventory.

---

Maturity Level 2, Comprehensive

Objective: Model threats per asset at a depth calibrated to its risk tier, refresh models on material change, and keep the Vendors threat picture current against real adversary behaviour.

At this level threat modelling moves from archetype to asset, at a depth that matches the tier. Critical-tier assets get a per-asset model with an adversarial overlay walking the relevant ATLAS tactics; Low-tier assets inherit the archetype snapshot unchanged. Models are refreshed on material change rather than annually, because an agent that gains a tool or a corpus that gains a data class has changed its threat picture whatever the calendar says. External intelligence feeds the library on a defined cadence, so the models track adversary behaviour rather than the authors' imagination at the time of writing.

Dependencies

• Required: TA-Vendors-L1, SM-Vendors-L2
• Alignment (not blocking): Enterprise threat intelligence function, so AI-specific intelligence is consumed through an existing channel
• Supports / unblocks: SR-Vendors-L2; SA-Vendors-L2; DR-Vendors-L2; ST-Vendors-L2; ML-Vendors-L2; IM-Vendors-L2; Required by: TA-Vendors-L3

Desired Outcomes

• Threat-model depth is proportionate to asset tier, and the difference is published rather than decided per engagement.
• Every Critical-tier asset has a per-asset threat model with an adversarial overlay rather than an inherited archetype snapshot.
• Models refresh on material change, so a capability added between reviews does not sit unmodelled until the next cycle.
• External threat intelligence reaches the library on a defined cadence and changes it demonstrably.
• Threat-model output drives what gets tested and what gets detected, rather than terminating in a document.

Activities

A) Calibrate threat-model depth to asset tier

Publish what each tier receives. Critical: a per-asset threat model, an adversarial overlay walking the relevant ATLAS tactics end to end, an explicit abuse-case set, and a named architect reviewer. High: the archetype model plus documented per-asset deltas and an ATLAS tactic walk. Medium: the archetype model with deltas recorded. Low: the archetype model unchanged. Publishing this is what stops the two failure modes of uniform depth, namely modelling everything shallowly so the Critical assets are under-analysed, or modelling everything deeply so the practice becomes a bottleneck and teams route around it. Set turnaround service levels per tier and report adherence, because a threat-modelling practice that cannot say how long it takes will be worked around by teams under delivery pressure whatever its analytical quality. Per-asset modelling in this domain means walking the data path into the vendor and the sub-processor chain behind it, because the organisation's threat surface extends to parties it has no relationship with and often cannot name, which is the specific thing an archetype model cannot capture.

B) Refresh on material change rather than on the calendar

Define material change per domain and wire the trigger to the signals that already exist. In this domain a material change includes a new capability or interface on the asset, a change to the data classes it handles, a model or provider change, a change in exposure or the population reached, and a tier increase from the SM rubric. Each triggers a re-model inside the tier's window, being 14 days at Critical and 30 at High. Annual review remains as a floor, not as the mechanism; the calendar is the least informative trigger available and relying on it means an asset that changed materially in month two carries a stale model for ten months. Record every refresh with what changed and what it changed in the model, so that a reviewer can see whether the re-model was substantive or a date stamp. In this domain the material change that most often invalidates a model is a vendor model change or a sub-processor addition, which arrive as a notification email if the contract requires one and as nothing at all if it does not.

C) Feed external intelligence in and push threat output downstream

Consume external threat intelligence on a defined cadence, drawing from MITRE ATLAS updates, OWASP LLM and Agentic project output, vendor and provider advisories, sector information-sharing bodies and published incident analyses. Assess each item for applicability to the archetypes in the library within 30 days, and record the assessment even when the answer is not applicable, because the record is what demonstrates the cadence is real. Push threat-model output downstream mechanically rather than by expectation: each Critical- and High-tier threat generates a requirement in the SR pack, a test case in the ST battery and a detection candidate in the ML set, tracked to closure. A threat model whose output is not visible in what gets tested and detected has produced a document, and the practice is then measured on documents. Vendor threat output lands most usefully in the contract clause set and the gateway filtering rules, since those are the only two places where an organisation can actually act on a threat it does not control.

Outcome Metrics (L2)

Metric	Baseline	L2 Target	Source
Critical-tier assets with a current per-asset threat model and adversarial overlay	first tier-calibrated pass	100% of Critical, ≥90% of High	Threat model register joined to the asset inventory tier
Material changes triggering a re-model inside the tier window	first quarter of change telemetry	≥95% within 14 days at Critical, 30 days at High	Change events joined to threat model revision dates
External intelligence items assessed for applicability within 30 days	first quarter of intelligence intake	100%, including items assessed as not applicable	Threat intelligence assessment log
Critical- and High-tier threats generating a tracked requirement, test case and detection candidate	first downstream push	≥90% traced to all three	Traceability matrix across SR, ST and ML registers
Per-tier threat-modelling turnaround against the published service level	first quarter of telemetry	≥90% per tier	Threat modelling request log with timestamps

Process Metrics (leading)

• Material-change triggers wired to inventory, deployment and tier-change events rather than to a review calendar.
• External intelligence reviewed on the published cadence, with assessments recorded including negative ones.
• Downstream push to SR, ST and ML tracked to closure rather than handed off.
• Refresh records state what changed in the model, so date-stamp refreshes are visible.

Effectiveness Metrics (business value)

• Incidents traceable to an unmodelled capability fall, which is the outcome per-asset modelling exists to produce.
• Time from threat identification to a live detection or test falls, reported per tier.
• Teams request threat modelling proactively rather than being chased, which indicates the turnaround is tolerable.
• Effort concentrates on Critical and High tiers relative to L1.

Level of Effort (incremental over the level below)

• Stand-up: 180 hours · Ongoing: 140 hours/quarter
• Security Architect — primary, 30 days/year
• AppSec / SecEng — regular, 18 days/year
• AI/ML Engineer — regular, 12 days/year
• Security Analyst / SOC — low, 8 days/year
• Material new tooling: Threat model register linked to the asset inventory and change events

Success Criteria

• Threat-model depth per tier is published with turnaround service levels, and adherence is at or above 90% per tier.
• Every Critical-tier asset has a per-asset model with an adversarial ATLAS overlay and a named architect reviewer.
• Material change triggers a re-model inside the tier window, with refresh records stating what actually changed.
• External intelligence is assessed for applicability within 30 days, with negative assessments recorded.
• At least 90% of Critical- and High-tier threats generate a tracked requirement, test case and detection candidate.

---

Maturity Level 3, Industry-Leading

Objective: Drive Vendors threat modelling from live signal and adversary emulation, validate models against what actually happens, and contribute observed techniques back to ATLAS and the community.

At this level the threat picture is validated rather than asserted. Adversary emulation exercises the models against the real environment, and the gap between what the model predicted and what the exercise found is the practice's primary quality signal. Models update from detection telemetry, incident root causes and test results continuously. The organisation contributes techniques it has observed back to ATLAS and the community, which matters disproportionately in AI security because the public technique catalogue is young and most real observations never reach it.

Dependencies

• Required: TA-Vendors-L2, ST-Vendors-L2, ML-Vendors-L2, IM-Vendors-L2
• Alignment (not blocking): Red team or offensive security function, internal or contracted
• Supports / unblocks: Every other Vendors practice at L3, which inherits a validated rather than asserted threat picture; Required by: ML-Vendors-L3, ST-Vendors-L3

Desired Outcomes

• Threat models are validated against adversary emulation rather than accepted as authored.
• The gap between predicted and observed adversary behaviour is measured and used to improve the models.
• Models update continuously from detection telemetry, incident root causes and test results.
• Techniques observed in this environment reach ATLAS and the community rather than staying internal.
• The practice can state which of its threats have ever been demonstrated, and which remain theoretical.

Activities

A) Validate models through adversary emulation

Run adversary emulation against Critical-tier assets at least semi-annually, scoped from the threat model and executed by a team that did not author it. Measure the two directions of error explicitly: threats the model predicted that emulation could not demonstrate, and behaviours emulation found that the model did not anticipate. The second is the more valuable and the more uncomfortable, and a practice that only reports confirmations is not learning. Record for every threat in the library whether it has been demonstrated in this environment, demonstrated elsewhere, or remains theoretical, and report the distribution, since a library where most entries are theoretical is a library built from reading rather than from testing. Feed every unanticipated finding into the archetype library, not only into the asset's model, so that one exercise improves every asset sharing that archetype. Per-asset modelling in this domain means walking the data path into the vendor and the sub-processor chain behind it, because the organisation's threat surface extends to parties it has no relationship with and often cannot name, which is the specific thing an archetype model cannot capture.

B) Update models from live signal continuously

Close the loop from operations back to the models. Feed detection telemetry, incident root causes, security test failures and near-misses into the library continuously rather than at review time, and treat any observed technique not represented in the library as a defect in the library with an owner and a date. Publish a service level covering the interval from an observed technique to an updated model, targeting 30 days. Track the share of incidents whose root cause was already present in the library as an untreated threat, which is the single most informative metric this practice produces: it separates a failure to foresee, which is hard, from a failure to act on what was already written down, which is not, and the second is far more common than most programmes admit. In this domain the material change that most often invalidates a model is a vendor model change or a sub-processor addition, which arrive as a notification email if the contract requires one and as nothing at all if it does not.

C) Contribute observed techniques back

Submit techniques observed in this environment to MITRE ATLAS, and contribute to OWASP LLM and Agentic project revisions, sector information-sharing bodies and published incident analyses. This matters more in AI security than in most fields because the public technique catalogue is young, and the gap between what practitioners observe and what is publicly documented is wide, which means a single well-documented submission can be genuinely novel rather than incremental. Target at least four substantive submissions per year, count only those accepted, anonymise and legally review every one, and coordinate disclosure with affected model providers or vendors where a technique touches their systems. Where the L1 activity recorded threats for which no ATLAS technique fit, revisit that list first: it is the highest-yield source of contribution candidates the programme has. Vendor threat output lands most usefully in the contract clause set and the gateway filtering rules, since those are the only two places where an organisation can actually act on a threat it does not control.

Outcome Metrics (L3)

Metric	Baseline	L3 Target	Source
Critical-tier assets exercised by adversary emulation in the last 12 months	first emulation cycle	100%	Emulation exercise register joined to the asset inventory
Threats in the library classified as demonstrated here, demonstrated elsewhere or theoretical	first classification pass	100% classified, with the theoretical share reported and falling	Threat library validation status field
Emulation findings not anticipated by the model, fed back into the archetype library	first emulation cycle	100% fed back within 30 days	Emulation findings joined to library change log
Observed techniques reaching an updated model within the service level	first quarter of loop telemetry	≥90% within 30 days	Library change log joined to detection and incident records
Incidents whose root cause was an untreated threat already in the library	first quarter of root-cause analysis	falling year over year, reported openly	Incident root-cause analysis joined to the threat library
Accepted external technique contributions per year	0	≥4 accepted, anonymised and legally reviewed	Contribution log with acceptance references

Process Metrics (leading)

• Adversary emulation scheduled semi-annually for Critical tier and executed by a team that did not author the model.
• Detection, incident and test signal reviewed against the library continuously rather than at review time.
• Unmapped-technique candidate list reviewed quarterly as the contribution pipeline.
• Disclosure coordinated with affected providers before any submission touching their systems.

Effectiveness Metrics (business value)

• The share of library threats that are purely theoretical falls, which indicates the library is built from testing rather than reading.
• Incidents attributable to an already-documented untreated threat fall, separating failure to foresee from failure to act.
• External citations of contributed techniques, and their appearance in the public catalogue.
• Emulation surprise rate falls over time, which is the honest measure that the models are converging on reality.

Level of Effort (incremental over the level below)

• Stand-up: 220 hours · Ongoing: 160 hours/quarter
• Security Architect — primary, 26 days/year
• AppSec / SecEng — regular, 24 days/year
• Security Analyst / SOC — regular, 14 days/year
• AI/ML Engineer — low, 8 days/year
• Material new tooling: Adversary emulation tooling and an isolated exercise environment

Success Criteria

• Every Critical-tier asset is exercised by adversary emulation at least annually, by a team that did not author the model.
• Every threat in the library is classified as demonstrated here, demonstrated elsewhere or theoretical, with the theoretical share reported and falling.
• Emulation findings the model did not anticipate are fed back into the archetype library within 30 days, improving every asset sharing that archetype.
• Incidents whose root cause was an already-documented untreated threat are reported openly and falling year over year.
• At least four accepted external technique contributions per year, anonymised, legally reviewed and disclosure-coordinated.

---

Key Success Indicators

Level 1:

• A threat snapshot exists for at least 90% of inventoried vendors archetypes, each opening with entities and trust boundaries rather than a threat list.
• Every threat entry carries a HAI TTP tag and, where applicable, a genuine ATLAS technique identifier, with no invented references.
• At least 85% of threats trace to a named treating practice and specific control, with the untreated remainder published as gaps rather than omitted.
• Untreated threats at high-risk archetypes carry an owner and a remediation date.
• A 30-day snapshot service level operates for new archetypes, triggered from the inventory.

Level 2:

• Threat-model depth per tier is published with turnaround service levels, and adherence is at or above 90% per tier.
• Every Critical-tier asset has a per-asset model with an adversarial ATLAS overlay and a named architect reviewer.
• Material change triggers a re-model inside the tier window, with refresh records stating what actually changed.
• External intelligence is assessed for applicability within 30 days, with negative assessments recorded.
• At least 90% of Critical- and High-tier threats generate a tracked requirement, test case and detection candidate.

Level 3:

• Every Critical-tier asset is exercised by adversary emulation at least annually, by a team that did not author the model.
• Every threat in the library is classified as demonstrated here, demonstrated elsewhere or theoretical, with the theoretical share reported and falling.
• Emulation findings the model did not anticipate are fed back into the archetype library within 30 days, improving every asset sharing that archetype.
• Incidents whose root cause was an already-documented untreated threat are reported openly and falling year over year.
• At least four accepted external technique contributions per year, anonymised, legally reviewed and disclosure-coordinated.

---

Common Pitfalls

Level 1:

• ❌ Writing a threat list without first drawing entities and trust boundaries, which produces a list of worries rather than an analysis anyone can act on.
• ❌ Inventing plausible ATLAS technique identifiers where none fit, which survives review and misleads every downstream practice that trusts the tag.
• ❌ Authoring the library entirely within security, which describes the system security imagines rather than the one practitioners operate.
• ❌ Producing the library and never publishing the treatment gaps, which leaves threats accepted by default without anyone deciding to accept them.
• ❌ Writing snapshots so long that teams do not read them, after which the library is maintained for an audience of nobody.

Level 2:

• ❌ Relying on annual review as the refresh mechanism, which leaves an asset that changed in month two carrying a stale model for ten months.
• ❌ Modelling every asset at the same depth, which either under-analyses the Critical assets or turns the practice into a bottleneck teams route around.
• ❌ Recording refreshes as date stamps without stating what changed, which makes it impossible to tell a substantive re-model from a compliance gesture.
• ❌ Consuming threat intelligence without recording negative assessments, so there is no evidence the cadence is actually operating.
• ❌ Ending the threat model at the document, so nothing in testing or detection changes and the practice is judged on paperwork.

Level 3:

• ❌ Reporting only the threats emulation confirmed, which converts a learning exercise into a validation ritual.
• ❌ Feeding emulation findings into the single asset's model rather than the archetype library, so one exercise improves one asset instead of all of them.
• ❌ Not tracking incidents whose root cause was already in the library untreated, which conceals the difference between failing to foresee and failing to act.
• ❌ Leaving the unmapped-technique list from L1 unrevisited, discarding the best contribution candidates the programme has.
• ❌ Submitting techniques that touch a provider's systems without coordinating disclosure, which damages the relationships the programme depends on.

---

Practice Maturity Questions

Level 1:

1. Does a published threat snapshot exist for at least 90% of inventoried vendors archetypes, each establishing entities and trust boundaries before enumerating threats, validated with a practitioner who works on that archetype?
2. Does every threat entry carry a HAI TTP tag, a genuine MITRE ATLAS technique where one applies with gaps recorded rather than forced, an OWASP LLM reference and the relevant compliance obligation? For Vendors, the assessor should be shown the threat snapshot for the AI API vendor archetype, with its sub-processor chain.
3. Are at least 85% of threats traced to a named treating practice and specific control, with untreated threats published as gaps and those at high-risk archetypes carrying an owner and remediation date? In Vendors, ask to see the threat snapshot for the AI API vendor archetype, with its sub-processor chain.

Level 2:

1. Is threat-model depth calibrated by asset tier with published turnaround service levels, such that Critical-tier assets receive a per-asset model with an adversarial ATLAS overlay and a named architect reviewer while Low-tier assets inherit the archetype snapshot? Evidence this in the Vendors domain against the threat snapshot for the AI API vendor archetype, with its sub-processor chain.
2. Does material change, including a new capability, a data-class change, a model or provider change, an exposure change or a tier increase, trigger a re-model within 14 days at Critical and 30 at High, with refresh records stating what actually changed rather than only a date? For Vendors, the assessor should be shown the threat snapshot for the AI API vendor archetype, with its sub-processor chain.
3. Is external threat intelligence assessed for applicability within 30 days with negative assessments recorded, and do at least 90% of Critical- and High-tier threats generate a tracked requirement, test case and detection candidate? In Vendors, ask to see the threat snapshot for the AI API vendor archetype, with its sub-processor chain.

Level 3:

1. Is every Critical-tier asset exercised by adversary emulation at least annually by a team that did not author the model, with both error directions measured, including behaviours the model failed to anticipate? Evidence this in the Vendors domain against the threat snapshot for the AI API vendor archetype, with its sub-processor chain.
2. Is every library threat classified as demonstrated here, demonstrated elsewhere or theoretical, and is the share of incidents whose root cause was an already-documented untreated threat reported openly and falling? For Vendors, the assessor should be shown the threat snapshot for the AI API vendor archetype, with its sub-processor chain.
3. Does the organisation contribute at least four accepted techniques per year to ATLAS and the community, anonymised, legally reviewed and disclosure-coordinated, drawing first on the threats for which no existing technique fitted? In Vendors, ask to see the threat snapshot for the AI API vendor archetype, with its sub-processor chain.

---

Lightweight Questions (E0 rung)

Answerable yes/no by one person in under 30 seconds, with nothing open.

Level 1:

• Is there a written threat model for each kind of AI vendors asset you run?
• Can you name one threat you have accepted without a control?
• Would a new AI asset get a threat model before it ships?

Level 2:

• Does your highest-risk AI asset have its own threat model?
• Would adding a capability to an AI asset trigger a threat model refresh?
• Does anything from your threat models end up as a test?

Level 3:

• Has anyone tried to break your highest-risk AI asset this year?
• Do you know which of your documented threats have ever actually been demonstrated?
• Have you submitted a technique you observed to ATLAS?

---

Tracking

Level 1 — Jira Epic, labels haiamm-ta-vendors-l1, haiamm-building

• Done when: Archetype threat snapshot coverage at or above 90% with full HAI TTP and ATLAS tagging and at least 85% of threats traced to a treating practice, sustained two consecutive quarters.
• Git artifacts: security/threat-models/, security/threat-traceability.json
• Git signal: Every threat model file carries a commit within its quarterly review interval, and threat-traceability.json is regenerated from the library rather than maintained separately.
• CI check: threat-library-freshness

Level 2 — Jira Epic, labels haiamm-ta-vendors-l2, haiamm-building

• Done when: Every Critical-tier asset carrying a current per-asset threat model with material-change re-modelling at or above 95% inside the tier window, sustained across two consecutive quarters.
• Git artifacts: security/threat-models/, security/threat-traceability.json, security/intel-assessment-log.json
• Git signal: threat-traceability.json links each Critical and High tier threat to a requirement, test case and detection identifier, and refresh commits record what changed rather than only bumping a date.
• CI check: threat-model-currency

Level 3 — Jira Epic, labels haiamm-ta-vendors-l3, haiamm-building

• Done when: Every Critical-tier asset emulated within the trailing year with all unanticipated findings fed back to the archetype library within 30 days, sustained across two consecutive quarters.
• Git artifacts: security/emulation-register.json, security/threat-models/, governance/contribution-log.json
• Git signal: emulation-register.json records the executing team separately from the model author for every exercise, and threat model files carry a validation-status field per threat.
• CI check: emulation-coverage-check

---

Mappings

Level	HAI TTP	ATLAS	OWASP LLM 2025	Compliance
L1	EA	AML.T0010	LLM02, LLM03	EU AI Act Art. 9; EU AI Act Art. 15; NIST AI RMF MAP 5.1; NIST AI RMF MEASURE 2.7; ISO/IEC 42001 6.1
L2	EA	AML.T0010	LLM02, LLM03	EU AI Act Art. 9; EU AI Act Art. 15; NIST AI RMF MAP 5.1; NIST AI RMF MEASURE 2.7; ISO/IEC 42001 6.1; ISO/IEC 27001 A.5.7
L3	EA	AML.T0010	LLM02, LLM03	EU AI Act Art. 9; EU AI Act Art. 15; EU AI Act Art. 72; NIST AI RMF MEASURE 2.7; ISO/IEC 42001 9.1

---

Document Version: HAIAMM v3.5 (generated) / Practice: Threat Assessment (TA) / Domain: Vendors