AI Security Lifecycle — AI Shared Responsibility

The signal

Accountability is scoping vocabulary

LLMs referencing this site began using the SRF's structure to scope AI red team engagements. Nobody designed that. It works because the framework supplies what engagement scoping lacks: a layer model that bounds what is testable, an operating-model matrix that says whose systems those layers run on, and a persona list that names who must authorize testing and who owns each finding.

The lesson generalizes. The SRF's accountability structure is useful as a scoping and routing vocabulary across the entire AI security lifecycle. This page maps six categories of that lifecycle, states what the SRF answers in each, and links the data and tools that carry the answers.

Who authorizes

The operating model decides which layers a party may touch at all. Under AI-SaaS, testing the platform and model layers requires provider authorization or is out of scope.

Who owns the result

Every finding, attestation, and control lands on one named persona per operating model. Pre-assigned before the first probe, not negotiated after.

Who signs residual

One accountable party signs the risk that will not be fixed. "Shared" is not a valid final answer at any stage of the lifecycle.

Lane discipline

What the SRF does not do

The framework stays in its lane as an accountability model. It does not define attack techniques, threats, or test methodology; BIML, the OWASP AI Exchange, OWASP GenAI, MITRE ATLAS, and NIST AI 100-2 own that. It does not define control content or benchmarks; CIS, the CSA AI Controls Matrix, and the AI Exchange controls own that. It does not score severity; AIVSS owns that. It creates no new regulation. What it contributes to every category below is the same three answers, sourced from published catalogs it does not try to replace.

MOSAIC context. MOSAIC (Multi-Organization Secure AI Coordination) launched April 28, 2026 with eight founding initiatives: BIML, CIS, CSA, CoSAI, NIST, OWASP AI Exchange, OWASP GenAI Security Project, and SANS. Its highest-leverage output so far is a shared taxonomy built on OpenCRE that links terms, controls, and concepts across the participating standards. None of the linked nodes carry who is accountable. That is the seat the SRF fills. See the MOSAIC member mapping and the taxonomy binding below.

Six categories

Where the SRF plugs into the lifecycle

Each category names the SRF contribution, the MOSAIC work it serves, what this site already publishes, and the gap still open.

01

Threat modeling and risk analysis

Contribution

Bounds the analysis. Which layers are yours to model under your operating model, and which persona owns each identified risk. A threat model without an owner per risk is a reading list.

Serves

BIML OWASP AI Exchange NIST

Site has

Threat-to-accountability crosswalk (data), the layer model, the comparison page, and the glossary with canonical IDs.

Gap

The crosswalk covers the sixteen threats in the AI Exchange security matrix. Extending it to the full BIML risk set and ATLAS technique catalog remains open.

02

Adversarial testing and red teaming

Contribution

Engagement scoping and rules of engagement. The operating model determines which layers the customer may test at all; personas pre-assign finding ownership before the first probe. This is the proven category. LLMs already do it with the site unprompted.

Serves

OWASP GenAI Security Project SANS NIST

Site has

The Red Team Scoping Tool, which reads the crosswalk and returns testable, authorization- required, and out-of-scope layers per operating model, plus Framework Stress Test for scenario probing and the Accountability Decision Record pattern the scoping record reuses.

Gap

None open. The scoping tool cites the OWASP GenAI Red Teaming Guide for methodology and NIST AI 100-2 for attack taxonomy; it supplies only the accountability overlay.

03

Secure development and AI supply chain

Contribution

Names who attests at each handoff in the model and data supply chain. Provenance schemes establish that an attestation exists; the SRF says which persona must produce it and which persona must verify it, per operating model.

Serves

CoSAI CIS OWASP AI Exchange

Site has

The Vendor Risk Assessment with supplier categories and attestation baselines, plus the supply-chain poisoning and provenance threats in the crosswalk.

Gap

No attestation handoff map (producer persona, verifier persona, evidence object) published as data.

04

Control implementation and benchmarking

Contribution

Control ownership. Every catalog answers what good looks like; none answer who at your company owns this control under your deployment model. The vertical schemas already prove the pattern with 258 controls carrying an accountable persona.

Serves

CIS CSA OWASP AI Exchange NIST

Site has

Controls Assessment (AICM), Security Controls, six vertical control schemas, the OSCAL catalog, and a CIS Controls card with thirty-four controls across the six vertical schemas carrying a cis mapping key.

Gap

None open at the control level mapped. CIS Controls v8.1 has 153 safeguards; only a control-level (not safeguard-level) mapping is published, and only where a defensible correspondence exists.

05

Vulnerability management and finding remediation

Contribution

Routing. Severity scoring says how bad; the SRF says whose queue a finding goes in and who signs acceptance if it will not be fixed. This closes the loop opened by red teaming: a scored finding routes by layer and operating model to a named persona.

Serves

OWASP GenAI Security Project CISA-style disclosure

Site has

The finding routing reference (data) and Incident Response Playbooks with the who-leads-per-operating-model pattern, already machine-readable at /export/playbooks.json.

Gap

None open. The routing reference resolves persona and breach action by layer and operating model; AIVSS still owns the severity score itself.

06

Detection, monitoring, and incident response

Contribution

Who leads when a boundary fails, what to demand from the party on the other side of that boundary, and which evidence obligations survive the incident. Largely built.

Serves

SANS CIS CoSAI

Site has

Incident Response Playbooks (seven scenarios) and the thresholds SLI/SLO schema with an OCSF evidence plane.

Gap

None open. The playbooks now cite the finding routing reference and red team findings as upstream inputs.

Workforce readiness (SANS training, the CoSAI defender workstream) is already served by the existing NICE mapping and needs no new build.

Live data

Threat-to-accountability crosswalk

Each threat definition belongs to its external source. The crosswalk adds the SRF layer where the threat lands and the accountable persona per operating model. A sample of the sixteen entries follows; the full set is at /data/threats.json.

Threat	SRF layer	Owner under AI-SaaS	Owner under AI-PaaS	External ID
Loading crosswalk…

Live data

Finding routing reference

Severity scoring says how bad a finding is; this table adds whose queue it goes in and what happens at each severity band. AIVSS (the OWASP AI Vulnerability Scoring System) or CVSS supplies the score; the SRF supplies the persona and the breach action. The full twenty layer-by-operating-model set is at /data/finding-routing.json.

Layer	Operating model	Accountable persona	Critical breach action
Loading routing reference…

AIVSS v0.8 (released March 2026) extends CVSS v4.0 with agentic risk-amplification factors and produces a contextual 0-10 severity score. Its own published severity-band cut points are TBD pending the full scoring calculator documentation; this table routes on the qualitative band (Critical/High/Medium/Low), not a specific numeric cutoff. See aivss.owasp.org.

MOSAIC

Member mapping

Each MOSAIC founding initiative answers a different question. The SRF answers the accountability question the others leave open. Workstreams below reflect the April 2026 announcements; verify each against a member's current published artifacts before relying on it.

Member	AI security workstream	Categories	Concrete hook
BIML	Architectural risk analysis of ML and LLM systems	01	BIML risk IDs in the threat crosswalk
CIS	Controls, Benchmarks, and AI guidance for the Controls	04, 06	CIS mapping on the compare page and in control schemas
CSA	AI Controls Matrix, AI Safety Initiative	04	The existing AICM assessment tool; keep AICM IDs current
CoSAI	Supply chain, defender preparation, risk governance, agentic workstreams	03, 06	The SRF is CoSAI's own artifact; this site is the operationalization case
NIST	AI RMF, AI 100-2, GenAI profile, 800-53 AI overlay	01, 04	Existing OSCAL work; overlay and RMF profile participation is the direct channel
OWASP AI Exchange	Threat and control matrix, OpenCRE shared taxonomy, EU AI Act standardization	01, 04, taxonomy	SRF canonical IDs as OpenCRE resources (top priority)
OWASP GenAI	LLM Top 10, GenAI Red Teaming Guide, Agentic Security Initiative, AIVSS	02, 05	Scoping tool cites the Guide; routing reference consumes AIVSS
SANS	SEC536 and AI curriculum, summits, Critical AI Security Guidelines	02, 06	Scoping tool as an instructor-usable artifact; NICE mapping serves workforce

Taxonomy binding

The accountability axis of the shared taxonomy

The MOSAIC shared taxonomy links what the standards say. The SRF's canonical IDs, already minted in ids.json and the knowledge layer, can become linkable OpenCRE resources. Then any threat or control node in the taxonomy resolves to an accountable persona under a stated operating model, without the SRF joining a committee or writing a new standard.

Worked example: an engineer lands on the AI Exchange direct prompt injection page through the taxonomy. Today it can route her to controls and related standards. With the binding it also resolves that this threat lands at layer L3, that under AI-PaaS the accountable persona is the customer's application developer, and that under AI-SaaS it is provider-managed, so customer testing requires provider authorization. The crosswalk publishes exactly that resolution for all sixteen matrix threats today.

The binding is a data deliverable plus a contribution proposal through CoSAI into the MOSAIC GitHub. It composes existing identifiers and mints none. Machine-readable set: ids.json (canonical IDs) and the knowledge pack.