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. No one built the site for that purpose. Engagement scoping needs a layer model that bounds what is testable, an operating-model matrix that shows whose systems those layers run on, and a persona list that names who must authorize testing and who owns each finding. The framework already contains all three.

The same structure works beyond red teaming. It serves 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. Ownership is assigned during scoping, before any testing starts.

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.

Scope

What the SRF does not do

The framework limits itself to accountability. Attack techniques, threats, and test methodology belong to BIML, the OWASP AI Exchange, OWASP GenAI, MITRE ATLAS, and NIST AI 100-2. Control content and benchmarks belong to CIS, the CSA AI Controls Matrix, and the AI Exchange controls. Severity scoring belongs to AIVSS. The SRF creates no new regulation. In every category below it adds the same three accountability answers on top of those published catalogs.

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 concrete integration point so far is a shared taxonomy built on OpenCRE that links terms, controls, and concepts across the participating standards. The linked nodes do not record who is accountable. The SRF supplies that missing data. 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. The SRF shows which layers are yours to model under your operating model and names the persona who owns each identified risk, so the threat model produces assignments instead of an unowned list.

Serves

BIML OWASP AI Exchange NIST

Site has

Threat-to-accountability crosswalk (data), the layer model, the comparison page, the glossary with canonical IDs, and the diagram threat-modeling prompts (Shostack's Four Questions; Track B writes one persona per threat).

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, and personas pre-assign finding ownership before testing starts. LLMs already use the site this way without being asked to.

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 names 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. Control catalogs describe what good looks like. They do not name who at your company owns each 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 rates how bad a finding is. The SRF adds whose queue it goes in and who signs acceptance if it will not be fixed. A scored finding from a red team engagement 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

Says 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. Most of this category was already 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

AIVSS (the OWASP AI Vulnerability Scoring System) or CVSS supplies the severity score. This table adds the accountable persona and the breach action for each severity band. 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) rather than a numeric cutoff. See aivss.owasp.org.

MOSAIC

Member mapping

Each MOSAIC founding initiative covers different ground. The SRF covers accountability, which none of the other members publish. 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 the content of the participating standards. The SRF's canonical IDs, already minted in ids.json and the knowledge layer, can become linkable OpenCRE resources. Any threat or control node in the taxonomy then resolves to an accountable persona under a stated operating model. This requires no new standard and no new committee.

Example: the AI Exchange page for direct prompt injection already links to controls and related standards through the taxonomy. The binding adds the accountability data. The threat lands at layer L3. Under AI-PaaS the accountable persona is the customer's application developer. Under AI-SaaS the layer is provider-managed, so customer testing requires provider authorization. The crosswalk publishes this 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: opencre-srf.json (OpenCRE document objects with proposed CRE anchors), opencre-srf.csv (MyOpenCRE import format), ids.json (canonical IDs), and the knowledge pack.