{
 "schema_version": "1.0.0",
 "published": "2026-06-29",
 "source": {
  "id": "owasp_aisvs",
  "title": "OWASP AI Security Verification Standard 1.0",
  "version": "1.0",
  "canonical_url": "https://github.com/OWASP/AISVS/tree/main/1.0/en",
  "normative_force": "voluntary-standard"
 },
 "total_requirements": 191,
 "coverage_summary": {
  "direct": 93,
  "partial": 98,
  "none": 0,
  "out_of_scope": 0
 },
 "mappings": [
  {
   "aisvs_id": "C1.1.1",
   "aisvs_chapter": "C01 \u2014 Training Data Integrity & Traceability",
   "aisvs_text": "Verify that training data includes only features, attributes, and fields required for the model's stated purpose.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://model/controls/TG-06",
    "apeiris://data/controls/DA-02",
    "apeiris://privacy/controls/DP-03"
   ],
   "primary_domains": [
    "model",
    "data",
    "privacy"
   ],
   "notes": "TG-06 (Sensitive-Data Necessity, Minimization and Controlled Use) directly requires limiting training data to strictly necessary fields, with de-identification or synthetic replacement where feasible. DA-02 (Data Minimization Implementation for AI) enforces minimization technically at the data platform layer \u2014 column-level access controls prevent ingestion of unnecessary attributes. DP-03 (Data Minimization Enforcement) applies technical controls that reject collection of personal data beyond the stated AI purpose and purge unnecessary personal data from training corpora at ingestion. Together these three controls provide overlapping direct coverage of the data minimization requirement."
  },
  {
   "aisvs_id": "C1.1.2",
   "aisvs_chapter": "C01 \u2014 Training Data Integrity & Traceability",
   "aisvs_text": "Verify that an up-to-date inventory is kept of every training-data source, including its origin, responsible party, license, collection method, intended use constraints, and processing history.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://model/controls/LI-05",
    "apeiris://model/controls/TG-03",
    "apeiris://model/controls/TG-07",
    "apeiris://model/controls/LI-08",
    "apeiris://data/controls/DM-01",
    "apeiris://data/controls/DL-02"
   ],
   "primary_domains": [
    "model",
    "data"
   ],
   "notes": "DL-02 (Training Data Lineage Documentation) is the closest direct match \u2014 it requires documented lineage covering source identity, collection date, collection method, consent or license basis, transformation history, and the dataset version used in each training run. DM-01 (AI Data Asset Inventory and Cataloging) provides the authoritative catalog entry per dataset with ownership, provenance lineage, and lifecycle status. LI-05 links the model registry to the training dataset record so model governance and data governance are connected. TG-03 covers the legal basis and permitted-use constraints dimension. TG-07 covers third-party data sources with due-diligence and version-pinning requirements. LI-08 records dataset licenses. Together these controls satisfy all sub-elements of C1.1.2 with direct and overlapping coverage."
  },
  {
   "aisvs_id": "C1.1.3",
   "aisvs_chapter": "C01 \u2014 Training Data Integrity & Traceability",
   "aisvs_text": "Verify that data integrity is provided when training data is stored and transferred.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://data/controls/DI-01",
    "apeiris://data/controls/DI-05",
    "apeiris://model/controls/TG-04",
    "apeiris://privacy/controls/DP-01"
   ],
   "primary_domains": [
    "data",
    "model"
   ],
   "notes": "DI-01 (Data Integrity Baseline and Checksum Monitoring) establishes cryptographic fingerprints at ingest and monitors continuously for unauthorized changes \u2014 directly addressing storage integrity. DI-05 (Database and Storage Integrity Monitoring) extends this to storage-layer monitoring for corruption, bit rot, and unauthorized writes. TG-04 (Data Poisoning Prevention) implements SHA-256/SHA-3-256 hash-pinning for every training shard and mandates hash verification before every training run, covering both storage and transfer integrity for training data. DP-01 (Encryption at Rest and in Transit) provides encryption coverage for personal data in training stores and transit. Transfer integrity (in-flight) is addressed by TG-04's supply-chain integrity checks and DI-01's continuous monitoring rather than a dedicated transfer-integrity control \u2014 a minor gap for non-personal data in transit not governed by DP-01."
  },
  {
   "aisvs_id": "C1.1.4",
   "aisvs_chapter": "C01 \u2014 Training Data Integrity & Traceability",
   "aisvs_text": "Verify that integrity monitoring is applied to guard against unauthorized modifications or corruption of training data.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://data/controls/DI-01",
    "apeiris://data/controls/DI-05",
    "apeiris://model/controls/TG-04"
   ],
   "primary_domains": [
    "data",
    "model"
   ],
   "notes": "DI-01 monitors continuously for unauthorized changes against cryptographic baselines established at ingest, alerting on any deviation. DI-05 monitors storage systems for unauthorized writes and structural degradation that could silently compromise training data. TG-04 requires hash verification before every training run, with any integrity chain break triggering automatic quarantine and a security incident \u2014 providing active blocking not just alerting. These controls collectively satisfy the monitoring requirement with detection, alerting, and pipeline-blocking enforcement."
  },
  {
   "aisvs_id": "C1.1.5",
   "aisvs_chapter": "C01 \u2014 Training Data Integrity & Traceability",
   "aisvs_text": "Verify that datasets are watermarked so their use can be attributed and any unauthorized use detected.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/LI-08"
   ],
   "primary_domains": [],
   "notes": "Confirmed gap. Apeiris has no control covering training dataset watermarking for attribution and unauthorized-use detection. BH-09 (Synthetic-Content Provenance) implements output watermarking for AI-generated content per NIST AI 100-4 approaches, but this is distinct \u2014 it marks what models produce, not the training datasets themselves. DI-01 and TG-04 provide cryptographic integrity via checksums, which detect tampering but do not embed persistent, steganographic, or statistical watermarks in dataset files that survive copying and enable out-of-band attribution. Dataset watermarking (radioactive data, canary records, steganographic embedding in image/text corpora) to detect unauthorized training use by third parties is not addressed. This is a gap at L3. [closed 2026-07-08 via LI-08]"
  },
  {
   "aisvs_id": "C1.2.1",
   "aisvs_chapter": "C01 \u2014 Training Data Integrity & Traceability",
   "aisvs_text": "Verify that labeling platforms enforce access controls that restrict who can create, modify, or approve annotations.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://data/controls/DA-01",
    "apeiris://model/controls/BH-10"
   ],
   "primary_domains": [
    "data",
    "model"
   ],
   "notes": "Partial coverage. DA-01 (AI Data Access Authorization Framework) establishes RBAC/ABAC for all AI data assets and enforces least-privilege access policies, which would apply to labeling data stores, but it is not scoped to labeling platform workflow controls (annotation creation, modification, approval roles). BH-10 (Feedback Loop Integrity and Online Learning Governance) governs RLHF/RLAIF labeler quality controls, including inter-rater reliability monitoring and coordinated-feedback detection, which implies some labeler identity governance, but the focus is on post-deployment feedback labeling rather than pre-training labeling platform access control. Apeiris does not have a dedicated control for labeling platform role-based workflow authorization (the annotator/reviewer/approver separation of duties pattern). This is a recognized partial gap, particularly for pre-training data annotation workflows."
  },
  {
   "aisvs_id": "C1.2.2",
   "aisvs_chapter": "C01 \u2014 Training Data Integrity & Traceability",
   "aisvs_text": "Verify that cryptographic integrity is applied to labeling artifacts.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://data/controls/DI-01",
    "apeiris://model/controls/TG-04"
   ],
   "primary_domains": [
    "data",
    "model"
   ],
   "notes": "Partial coverage. DI-01 establishes cryptographic fingerprints for all critical AI datasets and monitors for unauthorized changes \u2014 labeling artifacts (annotation manifests, label files) are AI data assets and fall within scope of DI-01's coverage. TG-04 requires SHA-256 or SHA-3-256 hash-pinning for every training shard including labeled datasets. However, neither control is explicitly scoped to labeling artifacts as a distinct artifact class; they apply to datasets generically. There is no dedicated control verifying that annotation export files, label manifests, or individual annotation records carry cryptographic integrity proofs (e.g., signed per-annotation records). Coverage is functional but not explicit \u2014 labeling-artifact-specific integrity assurance is a partial gap."
  },
  {
   "aisvs_id": "C1.2.3",
   "aisvs_chapter": "C01 \u2014 Training Data Integrity & Traceability",
   "aisvs_text": "Verify that sensitive information in labels is redacted, anonymized, or encrypted before being used in any labeling artifact.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/TG-06",
    "apeiris://privacy/controls/DP-02",
    "apeiris://privacy/controls/DP-03",
    "apeiris://privacy/controls/DP-01"
   ],
   "primary_domains": [
    "model",
    "privacy"
   ],
   "notes": "Partial coverage. TG-06 (Sensitive-Data Necessity, Minimization and Controlled Use) requires de-identification, anonymization, or synthetic replacement for PII and protected-class data in training pipelines. DP-02 (Pseudonymization Implementation) applies pseudonymization in AI training pipelines. DP-03 (Data Minimization Enforcement) technically rejects collection of personal data beyond strict necessity. DP-01 (Encryption at Rest and in Transit) covers encryption of personal data in training stores. Together these address the sensitive-data protection requirement at the training corpus level. The gap is that none of these controls are specifically scoped to label-text fields within annotation artifacts \u2014 annotator comments, free-text label descriptions, or entity names embedded in annotation records \u2014 where sensitive information can persist even when the underlying data is cleaned. The principle is covered but the labeling-artifact-specific scope is not explicit."
  },
  {
   "aisvs_id": "C1.3.1",
   "aisvs_chapter": "C01 \u2014 Training Data Integrity & Traceability",
   "aisvs_text": "Verify that training and fine-tuning pipelines implement poisoning detection techniques to identify potential data poisoning or unintentional corruption in training data.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://model/controls/TG-04",
    "apeiris://data/controls/DV-03",
    "apeiris://data/controls/DI-01",
    "apeiris://model/controls/TG-01"
   ],
   "primary_domains": [
    "model",
    "data"
   ],
   "notes": "TG-04 (Data Poisoning Prevention) is the primary control \u2014 it mandates adversarial input screening at ingestion including statistical anomaly detection for label flips, outlier injection, and distributional shifts in newly ingested data batches. Hash verification before every training run catches corruption. DV-03 (Statistical Distribution Validation) continuously monitors training data for distribution drift relative to established baselines and holds pipelines when drift exceeds thresholds \u2014 covering unintentional corruption detection. DI-01 detects unauthorized modification through hash mismatch. TG-01's quality gate framework blocks training runs when data fails validation checks. Coverage is direct across both adversarial poisoning and unintentional corruption scenarios."
  },
  {
   "aisvs_id": "C1.3.2",
   "aisvs_chapter": "C01 \u2014 Training Data Integrity & Traceability",
   "aisvs_text": "Verify that automatically generated labels are subject to confidence thresholds and consistency checks to detect misleading or low-confidence labels.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/BH-10",
    "apeiris://model/controls/TG-01"
   ],
   "primary_domains": [
    "model"
   ],
   "notes": "Partial coverage with a meaningful gap. BH-10 (Feedback Loop Integrity and Online Learning Governance) governs RLHF/RLAIF labeling quality controls including inter-rater reliability (Cohen's Kappa threshold 0.6), reward score distribution monitoring, and coordinated-feedback anomaly detection with PSI thresholds \u2014 this directly addresses confidence and consistency checking for human-in-the-loop labeling of feedback data. TG-01 provides pipeline-level quality gates that can incorporate label confidence checks. However, BH-10's scope is post-deployment feedback loops (RLHF, RLAIF) rather than pre-training weak supervision, programmatic labeling, or LLM-generated labels for initial training datasets. C1.3.2 specifically targets automatically generated labels (e.g., weak supervision outputs, programmatic labeling systems, model-assisted annotation), which is not explicitly addressed. This is a partial gap at the pre-training automated labeling pipeline level."
  },
  {
   "aisvs_id": "C1.3.3",
   "aisvs_chapter": "C01 \u2014 Training Data Integrity & Traceability",
   "aisvs_text": "Verify that models used in security-relevant decisions are evaluated for bias patterns.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://model/controls/TG-02",
    "apeiris://model/controls/EV-05"
   ],
   "primary_domains": [
    "model"
   ],
   "notes": "TG-02 (Bias and Representativeness Assessment) conducts subgroup and intersectional fairness analysis on training data to document population coverage, identify underrepresentation, and establish bias baselines \u2014 addressing bias at the data level before training. EV-05 (Fairness and Bias Evaluation) mandates pre-deployment evaluation for fairness and bias across documented population groups and harm types, with specific attention to security-relevant and high-stakes decision contexts in the high-impact-decision and eu-high-risk profiles. Together these provide direct, dual-layer coverage \u2014 bias detection in training data (TG-02) and bias evaluation in the trained model before deployment (EV-05). Both controls require documentation of the evaluation methodology, metrics chosen, and populations assessed."
  },
  {
   "aisvs_id": "C1.3.4",
   "aisvs_chapter": "C01 \u2014 Training Data Integrity & Traceability",
   "aisvs_text": "Verify that disallowed content is detected and removed before training.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/TG-01",
    "apeiris://model/controls/TG-04",
    "apeiris://knowledge/controls/KI-02",
    "apeiris://knowledge/controls/KI-06"
   ],
   "primary_domains": [
    "model",
    "knowledge"
   ],
   "notes": "Partial coverage. TG-01 (Training Data Quality Gates) enforces quality gates before any training run proceeds, which can include content validation rules. TG-04 (Data Poisoning Prevention) includes adversarial input screening at ingestion \u2014 detecting and blocking manipulated content. KI-02 (Knowledge Poisoning Detection and Prevention) and KI-06 (Pre-Ingestion Content Quality Gates) address disallowed content detection at the knowledge base ingestion boundary. However, Apeiris does not have a dedicated disallowed-content detection control with an explicit enumeration of prohibited content categories (CSAM, hate speech, copyright-infringing material, PII corpora, etc.) and mandatory category-specific screening tooling. TG-01 and TG-04 provide the pipeline mechanism; what content is disallowed and how it is specifically detected is left to implementation. This is a functional but not explicit partial gap."
  },
  {
   "aisvs_id": "C1.3.5",
   "aisvs_chapter": "C01 \u2014 Training Data Integrity & Traceability",
   "aisvs_text": "Verify that defenses against clean-label poisoning attacks are implemented.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/TG-04"
   ],
   "primary_domains": [
    "model"
   ],
   "notes": "Partial coverage with a material gap for this L3 requirement. TG-04 (Data Poisoning Prevention) includes statistical anomaly detection for label flips, outlier injection, and distributional shifts, which provides general poisoning detection. However, clean-label poisoning is a distinct and sophisticated attack class where labels remain correct but inputs are imperceptibly perturbed (adversarially crafted in feature space) so that the model learns to misclassify clean test examples after training. Clean-label attacks are specifically not detected by label-integrity checks or simple distributional anomaly detection \u2014 they require feature-space analysis techniques such as influence functions, spectral signatures (spectral signatures defense), activation clustering, or nearest-neighbor consistency checks. TG-04's implementation steps do not enumerate these clean-label-specific defenses. This is a recognized gap at L3 that would require dedicated controls specifying influence-function analysis or spectral signature detection for high-assurance deployments."
  },
  {
   "aisvs_id": "C2.1.1",
   "aisvs_chapter": "C02 \u2014 Input Validation",
   "aisvs_text": "Verify that input normalization is applied before tokenization or embedding.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AT-03",
    "apeiris://security/controls/PT-04"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AT-03 (Tool Input Validation and Schema Enforcement) requires length limits, character-set restrictions, and pattern matching on string parameters before they reach the tool executor. PT-04 requires all tool inputs be validated against strict schemas before influencing the agent's next step. Neither control explicitly specifies that normalization (Unicode NFC/NFKC canonicalization, control-character stripping) must occur as a distinct pre-tokenization phase. The ordering requirement \u2014 normalization before tokenization, not after \u2014 is a gap in Apeiris's control language."
  },
  {
   "aisvs_id": "C2.1.2",
   "aisvs_chapter": "C02 \u2014 Input Validation",
   "aisvs_text": "Verify that encoding and representation smuggling in inputs is detected and mitigated. Approved mitigations include canonicalization, strict schema validation, policy-based rejection, or explicit marking.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AT-03",
    "apeiris://agentic/controls/AT-04",
    "apeiris://security/controls/PT-04",
    "apeiris://security/controls/PT-06"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AT-03 enforces strict schema validation on tool inputs including type, format, and pattern constraints. AT-04 strips content matching injection pattern signatures from tool outputs before they re-enter agent context. PT-04 treats all tool results as untrusted and sanitizes them before re-entry. PT-06 parses and sanitizes free-text model-generated parameters for nested injection beyond schema conformance. Strict schema validation and policy-based rejection \u2014 two of the four AISVS-approved mitigations \u2014 are addressed. Canonicalization (Unicode normalization) and explicit marking are not explicitly required by any control, representing a partial gap against the full set of approved mitigations."
  },
  {
   "aisvs_id": "C2.1.3",
   "aisvs_chapter": "C02 \u2014 Input Validation",
   "aisvs_text": "Verify that all inputs that could steer model behavior are treated as untrusted and screened by a prompt injection detection ruleset or classifier, with flagged inputs blocked.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/RT-02",
    "apeiris://agentic/controls/AB-05",
    "apeiris://security/controls/PT-07",
    "apeiris://security/controls/EC-07"
   ],
   "primary_domains": [
    "security",
    "agentic"
   ],
   "notes": "RT-02 requires guardrails to inspect every input \u2014 including retrieved and tool-returned content \u2014 for injection patterns in real time, with blocking or quarantine of suspected hijack attempts. AB-05 mandates a multi-layer defense: an input classification model or rule engine scores each input for injection risk before context assembly; context isolation via structural markers (XML tags, delimiters) separates trusted system context from untrusted inputs; output monitoring detects behavioral indicators of successful injection. PT-07 extends coverage to description injection (hidden instructions in tool metadata). EC-07 requires trust-ranking of retrieved content before it enters agent context. Together these provide direct, layered coverage of this requirement across both design and runtime planes."
  },
  {
   "aisvs_id": "C2.1.4",
   "aisvs_chapter": "C02 \u2014 Input Validation",
   "aisvs_text": "Verify that input length controls prevent content from exceeding the context window. The controls must reject inputs that exceed token limits rather than truncating them.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-09"
   ],
   "primary_domains": [],
   "notes": "No Apeiris control addresses context-window-aware token length enforcement. AT-03 includes length limits on string parameters at the tool-call level, but this is scoped to individual tool parameter fields, not to the aggregate model context window. The specific requirement to reject (not silently truncate) inputs at the context window boundary is not captured in any domain. This is a structural gap: a control under the PT or AT prefix requiring pre-assembly token budgeting with hard rejection at the context limit would close it. [closed 2026-07-08 via AB-09]"
  },
  {
   "aisvs_id": "C2.1.5",
   "aisvs_chapter": "C02 \u2014 Input Validation",
   "aisvs_text": "Verify that the system implements a character set restriction for all inputs. The restriction must use an allow-list approach that permits only characters that are explicitly required.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AT-03"
   ],
   "primary_domains": [
    "agentic"
   ],
   "notes": "AT-03 step 3 explicitly requires character-set restrictions on string parameters that may carry attacker-influenced content. However, the control's scope is limited to tool-call parameters and does not extend to all system inputs (user prompts, retrieved content, system messages). Additionally, AT-03 does not mandate the allow-list approach specifically \u2014 a deny-list implementation would satisfy the AT-03 text. The AISVS requirement for an allow-list covering all inputs system-wide is only partially addressed."
  },
  {
   "aisvs_id": "C2.1.6",
   "aisvs_chapter": "C02 \u2014 Input Validation",
   "aisvs_text": "Verify that the system enforces an instruction hierarchy in which system and developer messages override user instructions and other untrusted inputs, even after user instructions have been processed.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/PT-08",
    "apeiris://agentic/controls/AB-05"
   ],
   "primary_domains": [
    "security",
    "agentic"
   ],
   "notes": "PT-08 directly requires enforcement of an instruction hierarchy: untrusted content (tool results, retrieved documents, web pages) is admitted to the model only under a lower-privilege role and clearly delimited so the model treats it as data rather than instructions. The orchestrator's system instructions are in the highest-privilege role and are not assembled from untrusted content. AB-05 reinforces this by using explicit structural markers (XML tags, system-level separators) to isolate system prompt context from user input and retrieved content, with re-authentication required for privilege-sensitive operations that cannot be satisfied by injected text."
  },
  {
   "aisvs_id": "C2.1.7",
   "aisvs_chapter": "C02 \u2014 Input Validation",
   "aisvs_text": "Verify that reserved special tokens are encoded as literal characters and cannot be injected into the model context.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-09"
   ],
   "primary_domains": [],
   "notes": "No Apeiris control specifically addresses the encoding of reserved model tokens (such as BOS/EOS delimiters, role boundary tokens, or model-family-specific special sequences like <|im_start|>). While AB-05 and RT-02 cover prompt injection detection broadly, the AISVS requirement is structural \u2014 reserved tokens must be encoded as literals before entering the context, not merely detected after. This is a tokenizer-layer concern that falls between the security and model domains and is not explicitly assigned to either. Gap: a control requiring tokenizer-layer escaping of reserved special tokens as a non-negotiable preprocessing step would close this. [closed 2026-07-08 via AB-09]"
  },
  {
   "aisvs_id": "C2.1.8",
   "aisvs_chapter": "C02 \u2014 Input Validation",
   "aisvs_text": "Verify that the system can detect many-shot jailbreaking patterns.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-05",
    "apeiris://security/controls/RT-02",
    "apeiris://security/controls/AS-01",
    "apeiris://model/controls/BH-06",
    "apeiris://model/controls/EV-04"
   ],
   "primary_domains": [
    "agentic",
    "security",
    "model"
   ],
   "notes": "AB-05's input classification layer scores inputs for injection risk and could be configured to detect many-shot accumulation patterns; RT-02 requires injection inspection on all inputs including multi-turn context. AS-01 mandates adversarial red-teaming covering multi-turn goal-hijack scenarios before launch; EV-04 requires structured red-team exercises with a documented threat model. BH-06 operates a continuous InjectionProbeLibrary against production endpoints. However, none of these controls explicitly name many-shot jailbreaking as a required detection capability or specify the structural signature (repeated exemplar pairs that shift behavior cumulatively across turns). At L3, explicit named coverage of this attack class is the gap."
  },
  {
   "aisvs_id": "C2.2.1",
   "aisvs_chapter": "C02 \u2014 Input Validation",
   "aisvs_text": "Verify that every prompt is scored by a content classifier for violence, self-harm, hate, and sexual content against configurable thresholds. Prompts that exceed those thresholds are rejected or sanitized before reaching the model context.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-05",
    "apeiris://agentic/controls/AB-04"
   ],
   "primary_domains": [
    "agentic"
   ],
   "notes": "AB-05 deploys an input classification layer that scores inputs before context assembly, and AB-04 includes content policy classification as a stage in its filter chain. However, AB-04 is explicitly an output interception pipeline applied before output delivery, not an input-side control. AB-05's classifier is described in terms of injection risk rather than harm-category scoring. Neither control specifies the four AISVS harm categories (violence, self-harm, hate, sexual content) or requires configurable thresholds per category. Input-side content scoring prior to model ingestion \u2014 as distinct from output filtering \u2014 is not explicitly required. This is a meaningful coverage gap for deployments with strict content policy requirements."
  },
  {
   "aisvs_id": "C2.2.2",
   "aisvs_chapter": "C02 \u2014 Input Validation",
   "aisvs_text": "Verify that prompt content classification is evaluated for unsupported languages.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-09"
   ],
   "primary_domains": [],
   "notes": "No Apeiris control addresses multilingual input handling, language detection, or the requirement to evaluate content classifier effectiveness against inputs in unsupported languages. This is an NLP operations concern \u2014 classifiers trained on English or a limited language set may fail open on inputs in out-of-distribution languages, bypassing safety controls. This gap is unaddressed across all 12 Apeiris domains. [closed 2026-07-08 via AB-09]"
  },
  {
   "aisvs_id": "C2.2.3",
   "aisvs_chapter": "C02 \u2014 Input Validation",
   "aisvs_text": "Verify that non-text inputs (image/video/audio) are checked for adversarial perturbations, steganographic payloads, hidden or embedded content, or known attack patterns.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-09"
   ],
   "primary_domains": [],
   "notes": "Apeiris controls are designed for agentic and text-centric AI systems. No control addresses multimodal input validation \u2014 adversarial perturbation detection in image/video/audio inputs, steganographic payload scanning, or embedded content extraction. EC-07 trust-ranks retrieved content by provenance but is not multimodal-aware and does not perform signal-level analysis. This is a structural coverage gap for multimodal AI deployments. A new domain or sub-domain addressing multimodal input integrity would be required to close this. [closed 2026-07-08 via AB-09]"
  },
  {
   "aisvs_id": "C2.2.4",
   "aisvs_chapter": "C02 \u2014 Input Validation",
   "aisvs_text": "Verify that coordinated attacks spanning multiple input types (e.g., steganographic payloads in images combined with prompt injection in text) are detected and blocked.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-09"
   ],
   "primary_domains": [],
   "notes": "No Apeiris control addresses cross-modal coordinated attack detection. The building blocks exist in isolation \u2014 AB-05 detects text-based injection, AM-02 monitors for anomalous actions, and RT-07 detects multi-agent collusion \u2014 but none of these controls are designed to correlate signals across input modalities to identify a coordinated attack spanning, for example, a steganographic image payload and a concurrent text injection. This L3 requirement addresses a sophisticated, high-sophistication attacker capability for which Apeiris currently has no explicit control. Closing this would require both the multimodal scanning gap (C2.2.3) and a cross-signal correlation control to be addressed first. [closed 2026-07-08 via AB-09]"
  },
  {
   "aisvs_id": "C3.1.1",
   "aisvs_chapter": "C03 \u2014 Model Lifecycle Management & Change Control",
   "aisvs_text": "Verify that a model registry maintains an inventory of all deployed model artifacts and their origin.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://model/controls/LI-01",
    "apeiris://model/controls/LI-02",
    "apeiris://model/controls/CR-02"
   ],
   "primary_domains": [
    "model"
   ],
   "notes": "LI-01 (Unique Model Identity and Content-Addressed Version Hash) directly mandates a registry entry with a unique ID and cryptographic fingerprint for every model version \u2014 this is a model registry inventory control. LI-02 (Model Provenance Chain) records origin: base model, fine-tune steps, merges, and adapter components. CR-02 (Model Evidence Archive and Audit Trail) maintains the immutable audit record of all deployed artifacts. Together these three controls fully satisfy the registry inventory and origin-tracking requirement."
  },
  {
   "aisvs_id": "C3.1.2",
   "aisvs_chapter": "C03 \u2014 Model Lifecycle Management & Change Control",
   "aisvs_text": "Verify that all model artifacts (weights, configurations, tokenizers, base models, fine-tunes, adapters, and safety/policy models) are cryptographically signed by authorized entities.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/LI-03",
    "apeiris://model/controls/LI-01",
    "apeiris://security/controls/AS-06"
   ],
   "primary_domains": [
    "model",
    "security"
   ],
   "notes": "LI-03 (Supply Chain Integrity) requires cryptographic verification via signed checksums and a model bill-of-materials for third-party models. LI-01 mandates a cryptographic fingerprint (content-addressed hash) for every version. AS-06 (Verify model-weights and training-data provenance before load) reinforces pre-load verification. However, none of these controls explicitly require that ALL artifact types \u2014 including internally produced weights, tokenizers, safety/policy models, and adapters \u2014 are actively SIGNED (as opposed to hashed) by an authorized PKI-backed entity at creation time. The signing-by-authorized-entities requirement goes beyond content-addressing and is only partially addressed for the third-party supply chain case."
  },
  {
   "aisvs_id": "C3.1.3",
   "aisvs_chapter": "C03 \u2014 Model Lifecycle Management & Change Control",
   "aisvs_text": "Verify that model cryptographic signatures are verified at deployment admission and on load.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/LI-03",
    "apeiris://security/controls/AS-06",
    "apeiris://model/controls/EV-01"
   ],
   "primary_domains": [
    "model",
    "security"
   ],
   "notes": "LI-03 requires cryptographic verification before external models are used. AS-06 explicitly names verification 'before load' for model weights and training data provenance. EV-01 (Pre-Deployment Evaluation Gate) enforces a blocking pipeline stage before any deployment decision. Coverage is partial because (a) the explicit requirement for signature verification at the deployment admission controller (e.g., a Kubernetes admission webhook or CI gate enforcing signature policy) is not named as a distinct control, and (b) verification 'on load' as a runtime check on every model load event is not separately addressed beyond the pre-deployment gate."
  },
  {
   "aisvs_id": "C3.2.1",
   "aisvs_chapter": "C03 \u2014 Model Lifecycle Management & Change Control",
   "aisvs_text": "Verify that models undergo automated input validation testing, safety evaluation testing, and output sanitization testing before deployment.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://model/controls/EV-01",
    "apeiris://model/controls/EV-02",
    "apeiris://model/controls/EV-10"
   ],
   "primary_domains": [
    "model"
   ],
   "notes": "EV-01 (Pre-Deployment Evaluation Gate) mandates a blocking, signed, and auditable evaluation run as a mandatory precondition for any deployment decision. EV-02 (Fitness, Safety, Reliability and Policy-Conformance Evaluation) requires evaluation against documented criteria for task fitness, safety, reliability, and policy conformance \u2014 directly covering safety evaluation testing. EV-10 (Evaluation Result Provenance) cryptographically links results to the exact artifact. The suite-based approach satisfies all three test types named in the requirement. Note that input validation and output sanitization testing overlap with C02 controls in the security domain for runtime enforcement; EV-01/EV-02 address the pre-deployment testing gate."
  },
  {
   "aisvs_id": "C3.2.2",
   "aisvs_chapter": "C03 \u2014 Model Lifecycle Management & Change Control",
   "aisvs_text": "Verify that models subjected to post-training quantization are re-evaluated against the same safety and alignment test suite on the compressed artifact before deployment.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/LI-09",
    "apeiris://model/controls/EV-07",
    "apeiris://model/controls/EV-01"
   ],
   "primary_domains": [
    "model"
   ],
   "notes": "LI-09 (Material-Change Determination and Authorization Gate) establishes a formal process to determine whether a planned change \u2014 including quantization \u2014 requires a new evaluation cycle before going live. EV-07 (Regression Testing on Updates) requires that every model update triggers a regression evaluation run against a versioned baseline. EV-01 enforces the evaluation gate. Coverage is partial because the controls address re-evaluation on model change generically but do not explicitly name post-training quantization as a triggering condition or specifically require that the same test suite is applied to the compressed artifact rather than a substitute benchmark. The quantization-specific safety risk (capability gaps introduced by compression) is not explicitly called out."
  },
  {
   "aisvs_id": "C3.2.3",
   "aisvs_chapter": "C03 \u2014 Model Lifecycle Management & Change Control",
   "aisvs_text": "Verify that provider model, version, or routing changes trigger security re-evaluation before continued use.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://model/controls/LI-09",
    "apeiris://model/controls/EV-07",
    "apeiris://model/controls/OA-06"
   ],
   "primary_domains": [
    "model"
   ],
   "notes": "LI-09 (Material-Change Determination and Authorization Gate) explicitly lists provider-version changes as a trigger category requiring a new evaluation and approval cycle. EV-07 (Regression Testing on Updates) ensures any update \u2014 including provider-side changes \u2014 triggers a regression evaluation run. OA-06 (Third-Party Model and Vendor Risk Oversight) requires ongoing risk monitoring for foundation model providers including contract terms covering model change notification and audit rights. These three controls together directly address the provider-change re-evaluation requirement."
  },
  {
   "aisvs_id": "C3.3.1",
   "aisvs_chapter": "C03 \u2014 Model Lifecycle Management & Change Control",
   "aisvs_text": "Verify that production deployments implement rollout mechanisms with automated rollback triggers.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://model/controls/BH-08",
    "apeiris://model/controls/LI-06",
    "apeiris://resilience/controls/RP-03"
   ],
   "primary_domains": [
    "model",
    "resilience"
   ],
   "notes": "BH-08 (Shadow and Canary Deployment Governance) directly requires formal authorization gates before routing production traffic to new model versions, defines canary rollout criteria, shadow scoring comparison requirements, and explicitly names 'rollback trigger conditions.' LI-06 (Immutable Version Control with Tested Rollback and Emergency Disable) ensures rollback to any prior approved version is tested and ready, and emergency disable is operable independently of normal deployment tooling. RP-03 (Model Rollback and Previous Version Recovery Planning) formalizes rollback planning with defined triggers and authority chains. This is strong direct coverage."
  },
  {
   "aisvs_id": "C3.3.2",
   "aisvs_chapter": "C03 \u2014 Model Lifecycle Management & Change Control",
   "aisvs_text": "Verify that rollback capabilities restore the complete model state.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://resilience/controls/RO-02",
    "apeiris://model/controls/LI-06",
    "apeiris://resilience/controls/RO-03"
   ],
   "primary_domains": [
    "resilience",
    "model"
   ],
   "notes": "RO-02 (Model Rollback Execution and Validation) requires executing a controlled rollback to a known-good prior version and validating success before restoring full production traffic \u2014 directly addressing both the rollback capability and the validation step. LI-06 requires that every version change is recorded and rollback to any prior approved version is tested and ready. RO-03 (Data Recovery and Integrity Verification Post-Incident) covers recovery of AI-specific data stores. A minor gap: 'complete model state' may include AI-specific ephemeral state (KV caches, adapter stacks) that is implied but not enumerated explicitly in any single control."
  },
  {
   "aisvs_id": "C3.3.3",
   "aisvs_chapter": "C03 \u2014 Model Lifecycle Management & Change Control",
   "aisvs_text": "Verify that model versions running in parallel use isolated runtime state so that AI-specific shared resources are not shared across deployments.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://resilience/controls/RE-05",
    "apeiris://security/controls/EC-01"
   ],
   "primary_domains": [
    "resilience",
    "security"
   ],
   "notes": "RE-05 (Dependency Isolation and Bulkhead Patterns) requires AI system components to be isolated from each other and from shared infrastructure using bulkhead patterns and resource quota enforcement. EC-01 (Run the agent in a sandbox, from process isolation up to micro-VMs) provides process-level isolation. Coverage is partial because neither control explicitly addresses the parallel model version scenario \u2014 where two versions of the same model (e.g., a canary and stable variant) must not share GPU memory, KV caches, model serving state, or other AI-specific runtime resources. The isolation requirement here is specific to multi-version co-deployment and is not named as a distinct control."
  },
  {
   "aisvs_id": "C3.4.1",
   "aisvs_chapter": "C03 \u2014 Model Lifecycle Management & Change Control",
   "aisvs_text": "Verify that AI-specific runtime components are not shared across environment boundaries (e.g., development, staging, production).",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://resilience/controls/RE-05",
    "apeiris://security/controls/EC-01"
   ],
   "primary_domains": [
    "resilience",
    "security"
   ],
   "notes": "RE-05 (Dependency Isolation and Bulkhead Patterns) and EC-01 (sandbox isolation) provide general isolation architecture that implies environment boundary separation. Coverage is partial because no Apeiris control explicitly targets environment-boundary isolation for AI-specific runtime components (inference engines, model servers, vector stores) across dev/staging/production. This is a DevOps/infrastructure concern that Apeiris addresses through general isolation controls and the model domain's LI-layer governance, but not with a named control specific to environment promotion boundaries."
  },
  {
   "aisvs_id": "C3.4.2",
   "aisvs_chapter": "C03 \u2014 Model Lifecycle Management & Change Control",
   "aisvs_text": "Verify that model training and fine-tuning environments are isolated from production environments.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/TG-05",
    "apeiris://resilience/controls/RE-05",
    "apeiris://security/controls/EC-01"
   ],
   "primary_domains": [
    "model",
    "resilience",
    "security"
   ],
   "notes": "TG-05 (Train/Evaluation/Test Separation and Contamination Prevention) requires strict separation between training, evaluation, and test splits, and prevents contamination across phases. This is primarily a data-layer separation control. RE-05 and EC-01 provide general infrastructure isolation. Coverage is partial because the specific requirement \u2014 that training and fine-tuning INFRASTRUCTURE is network-isolated and access-controlled from production infrastructure \u2014 is not a named Apeiris control. TG-05 addresses data contamination prevention rather than infrastructure/environment isolation. The gap is meaningful at L2."
  },
  {
   "aisvs_id": "C3.5.1",
   "aisvs_chapter": "C03 \u2014 Model Lifecycle Management & Change Control",
   "aisvs_text": "Verify that models used in RLHF fine-tuning are versioned and integrity-verified before use in a training run.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/LI-01",
    "apeiris://model/controls/LI-03",
    "apeiris://model/controls/TG-04"
   ],
   "primary_domains": [
    "model"
   ],
   "notes": "LI-01 (Unique Model Identity and Content-Addressed Version Hash) covers versioning of model artifacts. LI-03 (Supply Chain Integrity) requires cryptographic integrity verification before a model is used. TG-04 (Data Poisoning Prevention) includes cryptographic integrity verification of training inputs and chain-of-custody controls. Coverage is partial because these are general model lifecycle controls: no control explicitly targets the RLHF-specific scenario where the reward model, base policy model, and reference policy model used in a training run must themselves be versioned and verified. BH-10 addresses RLHF governance but from a post-deployment feedback loop angle."
  },
  {
   "aisvs_id": "C3.5.2",
   "aisvs_chapter": "C03 \u2014 Model Lifecycle Management & Change Control",
   "aisvs_text": "Verify that RLHF training stages include automated detection of reward hacking or reward model over-optimization.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/BH-10"
   ],
   "primary_domains": [
    "model"
   ],
   "notes": "BH-10 (Feedback Loop Integrity and Online Learning Governance) explicitly lists 'reward hacking prevention' and 'RLHF/RLAIF labeler quality controls' in its scope, making it the closest Apeiris control to this requirement. Coverage is partial because BH-10 is oriented toward production and post-deployment feedback loop governance \u2014 it governs 'feedback loops that influence model behavior after deployment.' The AISVS L3 requirement is specifically about automated detection DURING the training stage before deployment, which is a different operational context. There is no Apeiris control that explicitly requires training-time instrumentation for reward hacking signals (e.g., KL divergence monitoring, reward score distribution tracking)."
  },
  {
   "aisvs_id": "C3.5.3",
   "aisvs_chapter": "C03 \u2014 Model Lifecycle Management & Change Control",
   "aisvs_text": "Verify that in multi-stage fine-tuning pipelines, each stage's output is integrity-verified before it is consumed by the next stage.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/LI-01",
    "apeiris://model/controls/LI-03",
    "apeiris://model/controls/EV-10"
   ],
   "primary_domains": [
    "model"
   ],
   "notes": "LI-01 (Content-Addressed Version Hash) provides the hash-based integrity mechanism for any model artifact. LI-03 (Supply Chain Integrity) establishes the principle of cryptographic verification before a model artifact is used. EV-10 (Evaluation Result Provenance) cryptographically links evaluation results to specific artifact versions. Coverage is partial because no Apeiris control explicitly addresses multi-stage fine-tuning pipeline integrity as a distinct pattern \u2014 the stage-to-stage handoff verification requirement (consuming the output of stage N as a verified, registered artifact before it is used as input to stage N+1) is implied by LI-01 and LI-03 but is not explicitly named."
  },
  {
   "aisvs_id": "C3.5.4",
   "aisvs_chapter": "C03 \u2014 Model Lifecycle Management & Change Control",
   "aisvs_text": "Verify that fine-tuning checkpoints are registered as distinct artifacts.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/LI-01",
    "apeiris://model/controls/LI-02"
   ],
   "primary_domains": [
    "model"
   ],
   "notes": "LI-01 (Unique Model Identity and Content-Addressed Version Hash) requires every model version to receive a unique identifier and cryptographic fingerprint \u2014 if checkpoints are treated as model versions, this control applies. LI-02 (Model Provenance Chain) records fine-tuning steps in the lineage. Coverage is partial because the controls address the final fine-tuned model artifact and its lineage, but 'checkpoints' as intermediate training artifacts (saved periodically during a training run, not just the final output) are not explicitly required to be registered as distinct versioned artifacts in the model registry. This is an L3 gap where the granularity of artifact registration is not specified."
  },
  {
   "aisvs_id": "C4.1.1",
   "aisvs_chapter": "C04 \u2014 Infrastructure, Configuration & Deployment Security",
   "aisvs_text": "Verify that AI models execute in isolated sandboxes.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/EC-01",
    "apeiris://security/controls/EC-04"
   ],
   "primary_domains": [
    "security"
   ],
   "notes": "EC-01 directly mandates sandbox isolation tiered to threat level \u2014 process isolation as the floor, gVisor as an intermediate tier, hypervisor-backed micro-VMs for untrusted-code agents. EC-04 reinforces by restricting filesystem and tool access to the minimum required by the task, preventing sandbox escape via over-scoped mounts. Together these address the requirement completely at the software/container layer."
  },
  {
   "aisvs_id": "C4.1.2",
   "aisvs_chapter": "C04 \u2014 Infrastructure, Configuration & Deployment Security",
   "aisvs_text": "Verify that model artifact loading enforces an explicit allow-list of serialization formats that do not permit arbitrary code execution during deserialization.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://security/controls/AS-06",
    "apeiris://security/controls/PT-03",
    "apeiris://model/controls/LI-03"
   ],
   "primary_domains": [
    "security",
    "model"
   ],
   "notes": "AS-06 requires signature verification of model weights before load and lists 'treating a checkpoint file as equivalent to a verified model' as an explicit anti-pattern. PT-03 explicitly calls out 'unsafe deserialization of manifest content' as an anti-pattern and mandates SBOM tracking. LI-03 requires cryptographic checksum verification of every third-party model artifact. However, none of these controls mandate a positive serialization-format allow-list (e.g. only SafeTensors, not Pickle). The requirement to enumerate and restrict permitted formats \u2014 rather than simply verify a signature \u2014 is a gap. Coverage is partial: integrity verification before load is addressed; format-level deserialization restriction is not."
  },
  {
   "aisvs_id": "C4.1.3",
   "aisvs_chapter": "C04 \u2014 Infrastructure, Configuration & Deployment Security",
   "aisvs_text": "Verify that workload attestation is performed before model loading to provide proof that the execution environment has not been tampered with.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://security/controls/AS-06",
    "apeiris://security/controls/EC-09",
    "apeiris://model/controls/LI-01",
    "apeiris://model/controls/LI-03"
   ],
   "primary_domains": [
    "security",
    "model"
   ],
   "notes": "AS-06 and LI-01/LI-03 provide artifact-level attestation: model weights are hashed and signature-verified before load, establishing that the model artifact itself has not been tampered with. EC-09 requires treating the workspace and its configuration as untrusted, which partially addresses environment integrity. The gap is execution-environment attestation: proving that the compute environment (container, VM, TEE) has not been tampered with, independently of the model artifact \u2014 e.g. remote attestation reports from a TEE or measured boot chain. Apeiris has no control equivalent to RATS (Remote ATtestation procedureS) or TPM-based measured launch."
  },
  {
   "aisvs_id": "C4.1.4",
   "aisvs_chapter": "C04 \u2014 Infrastructure, Configuration & Deployment Security",
   "aisvs_text": "Verify that confidential inference services protect model weights during runtime through isolated execution environments.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://security/controls/EC-01"
   ],
   "primary_domains": [
    "security"
   ],
   "notes": "EC-01 addresses runtime isolation via process, gVisor, and micro-VM sandboxing, which provides some protection for model weights during execution. However, this requirement specifically targets confidential computing \u2014 TEEs (e.g. AMD SEV, Intel TDX, NVIDIA H100 Confidential Computing) that provide memory encryption and hardware-enforced isolation to prevent host-level extraction of model weights at inference time. Apeiris has no control addressing in-use memory encryption or confidential inference at the hardware layer. Coverage is partial at best: software-layer isolation is addressed; confidential computing as a specific protection mechanism is a gap."
  },
  {
   "aisvs_id": "C4.2.1",
   "aisvs_chapter": "C04 \u2014 Infrastructure, Configuration & Deployment Security",
   "aisvs_text": "Verify that AI accelerator (GPU) firmware is version-pinned, signed, and attested at boot.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/EC-11"
   ],
   "primary_domains": [],
   "notes": "No Apeiris control addresses GPU firmware management. This requirement operates at the hardware firmware layer \u2014 pinning GPU driver/firmware versions, verifying manufacturer signatures, and obtaining boot-time attestation reports (e.g. NVIDIA RIM attestation). Apeiris's 12 domains cover AI behavior, model provenance, agentic runtime controls, and governance. Hardware firmware lifecycle is outside the current scope of any domain. [closed 2026-07-08 via EC-11]"
  },
  {
   "aisvs_id": "C4.2.2",
   "aisvs_chapter": "C04 \u2014 Infrastructure, Configuration & Deployment Security",
   "aisvs_text": "Verify that execution within a trusted execution environment (TEE) provides hardware-enforced isolation, memory encryption, and integrity protection.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/EC-11"
   ],
   "primary_domains": [],
   "notes": "Apeiris has no TEE-specific controls. This requirement addresses hardware confidential computing primitives \u2014 AMD SEV, Intel TDX, ARM TrustZone, NVIDIA Hopper Confidential Computing \u2014 providing encrypted memory, hardware isolation, and integrity measurement rings. EC-01 covers software-layer sandboxing but is categorically different from hardware-enforced TEE attestation. This is a genuine gap across all 12 Apeiris domains. [closed 2026-07-08 via EC-11]"
  },
  {
   "aisvs_id": "C4.2.3",
   "aisvs_chapter": "C04 \u2014 Infrastructure, Configuration & Deployment Security",
   "aisvs_text": "Verify that AI accelerator (GPU) integrity is validated using hardware-based attestation mechanisms before each workload executes.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/EC-11"
   ],
   "primary_domains": [],
   "notes": "No Apeiris control addresses per-workload GPU hardware attestation. This requirement targets mechanisms such as NVIDIA OCSP-based RIM attestation or AMD SEV attestation reports that cryptographically verify the GPU's firmware and configuration before launching a compute workload. This is hardware attestation infrastructure, entirely outside the layer at which Apeiris controls operate. [closed 2026-07-08 via EC-11]"
  },
  {
   "aisvs_id": "C4.2.4",
   "aisvs_chapter": "C04 \u2014 Infrastructure, Configuration & Deployment Security",
   "aisvs_text": "Verify that accelerator (GPU) memory is isolated between workloads through partitioning mechanisms with memory sanitization between jobs.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/EC-11"
   ],
   "primary_domains": [],
   "notes": "No Apeiris control covers GPU memory partitioning or sanitization between inference jobs. This is a hardware and hypervisor-level requirement \u2014 GPU MIG (Multi-Instance GPU) partitioning, VRAM scrubbing between tenants \u2014 well below the application and AI governance layer that Apeiris addresses. [closed 2026-07-08 via EC-11]"
  },
  {
   "aisvs_id": "C4.2.5",
   "aisvs_chapter": "C04 \u2014 Infrastructure, Configuration & Deployment Security",
   "aisvs_text": "Verify that accelerator interconnects are restricted to approved topologies and authenticated endpoints.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/EC-11"
   ],
   "primary_domains": [],
   "notes": "This requirement addresses GPU fabric interconnect security \u2014 NVLink, NVSwitch, InfiniBand topology restrictions, and endpoint authentication. While EC-02 covers agent-level network egress filtering, that operates at the application network layer and is categorically different from controlling which GPUs or compute nodes are permitted to communicate over hardware interconnects. No Apeiris control is relevant here. [closed 2026-07-08 via EC-11]"
  },
  {
   "aisvs_id": "C4.3.1",
   "aisvs_chapter": "C04 \u2014 Infrastructure, Configuration & Deployment Security",
   "aisvs_text": "Verify that edge AI devices authenticate to central infrastructure using strong authentication mechanisms.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://security/controls/IA-01",
    "apeiris://security/controls/IA-02"
   ],
   "primary_domains": [
    "security"
   ],
   "notes": "IA-01 mandates that every agent instance receives its own distinct workload identity (SPIFFE SVID, W3C DID, or directory agent object) and never authenticates as a shared or human account. IA-02 requires short-lived, task-scoped credentials issued at the moment of action \u2014 no long-lived reusable secrets. These controls apply to edge-deployed AI agents and directly address 'strong authentication mechanisms' for agent-to-infrastructure communication. The partial rating reflects that the controls are framed around software workloads and agentic runtimes rather than hardware-level device attestation for embedded/IoT edge endpoints (e.g. TPM-backed device certificates, 802.1AR iDevID)."
  },
  {
   "aisvs_id": "C4.3.2",
   "aisvs_chapter": "C04 \u2014 Infrastructure, Configuration & Deployment Security",
   "aisvs_text": "Verify that models deployed to edge or mobile devices are cryptographically signed during packaging, and that the on-device runtime validates these signatures or checksums before loading or inference.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://model/controls/LI-01",
    "apeiris://model/controls/LI-03",
    "apeiris://security/controls/AS-06"
   ],
   "primary_domains": [
    "model",
    "security"
   ],
   "notes": "LI-01 requires that every model version receive a unique identifier and a SHA-256 content hash covering weights, tokenizer, and inference configuration, stored in an append-only registry. LI-03 mandates cryptographic verification against a publisher-signed checksum before any third-party model is registered or used, plus a model SBOM. AS-06 requires signature verification of model weights before load (using OpenSSF Model Signing / Sigstore model-transparency) and explicitly lists 'loading model weights with no signature check' as an anti-pattern. Together these directly address the requirement: signing at packaging time and signature/checksum validation before loading on-device."
  },
  {
   "aisvs_id": "C4.3.3",
   "aisvs_chapter": "C04 \u2014 Infrastructure, Configuration & Deployment Security",
   "aisvs_text": "Verify that inference runtimes enforce process, memory, and file access isolation.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/EC-01",
    "apeiris://security/controls/EC-03",
    "apeiris://security/controls/EC-04"
   ],
   "primary_domains": [
    "security"
   ],
   "notes": "EC-01 mandates process-level isolation tiered from OS process boundaries to hypervisor-backed micro-VMs, with seccomp and capability profiles required. EC-03 requires that agent memory be volatile and session-scoped by default, with write-authentication and validation before anything is committed to long-term memory. EC-04 mandates that filesystem mounts be restricted to only task-required paths, with secrets and home directories explicitly excluded, and a deny-all default for tool access. The three controls together directly and specifically address the process, memory, and file access isolation triplet in the requirement."
  },
  {
   "aisvs_id": "C4.3.4",
   "aisvs_chapter": "C04 \u2014 Infrastructure, Configuration & Deployment Security",
   "aisvs_text": "Verify that model weights and sensitive parameters stored locally are encrypted using hardware-backed key stores or secure enclaves.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/EC-11"
   ],
   "primary_domains": [],
   "notes": "No Apeiris control addresses encryption-at-rest for model weights using hardware-backed key management. EC-08 covers keeping secrets out of the agent prompt and context, but does not address local storage encryption. LI-01 and LI-03 cover artifact integrity via hashing and signing, but not encryption of the artifact at rest. Hardware-backed key stores (TPM, HSM, iOS Secure Enclave, Android Keystore, Apple T2/T3 chip) are not addressed by any of the 12 Apeiris domains. This is a genuine gap, particularly relevant for on-device model deployment. [closed 2026-07-08 via EC-11]"
  },
  {
   "aisvs_id": "C4.3.5",
   "aisvs_chapter": "C04 \u2014 Infrastructure, Configuration & Deployment Security",
   "aisvs_text": "Verify that models packaged within mobile, IoT, or embedded applications are encrypted at rest, and decrypted only inside a trusted runtime or secure enclave, preventing direct extraction from the app package or filesystem.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/LI-01",
    "apeiris://security/controls/EC-01"
   ],
   "primary_domains": [
    "model",
    "security"
   ],
   "notes": "LI-01 provides content-addressed integrity verification so any extraction or tampering with the packaged model artifact is detectable. EC-01 provides runtime isolation so that once loaded, the inference process executes in a sandboxed environment. However, neither control addresses the core of this requirement: encrypting model weights in the application package at rest, or binding decryption to a secure enclave so the plaintext weights are never accessible outside a trusted execution boundary. The prevent-direct-extraction objective \u2014 preventing someone from unpacking an .apk or .ipa and reading the model weights from disk \u2014 is not covered. Coverage is partial: post-load runtime isolation and artifact integrity are addressed; at-rest encryption with enclave-bound decryption is a gap."
  },
  {
   "aisvs_id": "C5.1.1",
   "aisvs_chapter": "C05 \u2014 Access Control & Identity for AI Components & Users",
   "aisvs_text": "Verify that high-risk AI operations (model deployment, weight export, training data access, production configuration changes) require step-up authentication.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://identity/controls/IC-04",
    "apeiris://identity/controls/NI-04",
    "apeiris://identity/controls/NI-08"
   ],
   "primary_domains": [
    "identity"
   ],
   "notes": "IC-04 (Privileged Identity Management for AI) requires JIT elevation and ephemeral credentials for AI agent access to sensitive resources, which covers the intent of step-up access. NI-04 (JIT Credential Issuance) eliminates standing credentials before high-risk tasks. NI-08 (Break-Glass Identity) requires dual authorization and strict time limits for emergency access. However, Apeiris has no control that explicitly names 'step-up authentication' as a distinct mechanism (e.g., MFA re-challenge, phishing-resistant assertion re-prompt) gating specific high-risk operations such as model weight export or production configuration push. The specific operations named in this requirement (weight export, production config changes) are not enumerated in any Apeiris control. Coverage is partial \u2014 the access-elevation intent is met; the step-up authentication mechanism is not explicitly required."
  },
  {
   "aisvs_id": "C5.1.2",
   "aisvs_chapter": "C05 \u2014 Access Control & Identity for AI Components & Users",
   "aisvs_text": "Verify that AI agents in federated or multi-system deployments authenticate using short-lived, minimal-scoped, cryptographically signed tokens.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://identity/controls/NI-02",
    "apeiris://identity/controls/NI-03",
    "apeiris://identity/controls/NI-04",
    "apeiris://identity/controls/IF-03",
    "apeiris://identity/controls/IF-04",
    "apeiris://identity/controls/IF-06",
    "apeiris://security/controls/IA-02",
    "apeiris://agentic/controls/AA-02",
    "apeiris://agentic/controls/AA-03",
    "apeiris://agentic/controls/AA-05",
    "apeiris://agentic/controls/AA-06"
   ],
   "primary_domains": [
    "identity",
    "security",
    "agentic"
   ],
   "notes": "All three components of this requirement are directly covered. Short-lived tokens: NI-03 (Credential Lifetime and Forced Rotation), NI-04 (JIT issuance revoked on task completion), IA-02 (task-scoped day-pass credentials), AA-02 (enforced short lifetimes with automatic rotation). Minimal scope: NI-02 (narrowest permissions for the declared task; no wildcards), AA-06 (scopes must be reduced, never expanded, as call chain propagates). Cryptographic signing: II-03 (cryptographic key pair binding, proof of possession at every auth event), IF-04 (DID-based cryptographic identity for cross-org agents), IF-06 (client-bound tokens with replay prevention), AA-05 (nonce-bound session tokens). Federated deployment: IF-03 (cross-org agent authentication against a verified trust anchor), AA-06 (cross-system authentication chaining with identity preservation). This is the most comprehensively covered requirement in the chapter."
  },
  {
   "aisvs_id": "C5.2.1",
   "aisvs_chapter": "C05 \u2014 Access Control & Identity for AI Components & Users",
   "aisvs_text": "Verify that every AI resource (datasets, endpoints, vector collections, embedding indices, compute instances) enforces access controls with explicit allow-lists and default-deny policies.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-01",
    "apeiris://agentic/controls/AT-02",
    "apeiris://identity/controls/DE-02",
    "apeiris://data/controls/DA-01",
    "apeiris://security/controls/IA-04"
   ],
   "primary_domains": [
    "agentic",
    "identity",
    "data"
   ],
   "notes": "Default-deny with explicit allow-lists is covered for tools and agent actions: AB-01 requires a machine-readable manifest where any action not listed is blocked at the enforcement layer; AT-02 requires permissions denied by default with minimum-scope explicit grants. DA-01 covers data assets with RBAC/ABAC and least-privilege policy-as-code. DE-02 enforces that delegated scope is always the intersection, never a union. The gap is that the resource types named in this requirement \u2014 vector collections, embedding indices, and compute instances \u2014 are not explicitly enumerated as resources requiring default-deny controls in any Apeiris control. Coverage spans the principle broadly but does not enumerate these AI-specific resource types."
  },
  {
   "aisvs_id": "C5.2.2",
   "aisvs_chapter": "C05 \u2014 Access Control & Identity for AI Components & Users",
   "aisvs_text": "Verify that retrieval pipelines (e.g., RAG queries, embedding lookups) enforce the end-user's authorization context at each retrieval and assembly stage, rather than relying solely on the service account's permissions.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://knowledge/controls/KR-05",
    "apeiris://knowledge/controls/KM-02",
    "apeiris://data/controls/DA-01"
   ],
   "primary_domains": [
    "knowledge",
    "data"
   ],
   "notes": "KR-05 (Retrieval Permission Verification) directly requires that 'every retrieval operation must verify that the requesting user or agent has authorization to access each candidate document or chunk,' enforcing 'the same access control rules that govern direct document access.' This covers the per-retrieval user context enforcement. KM-02 requires access control at the retrieval layer by knowledge segment. The gap is the multi-stage assembly dimension: the requirement specifically addresses each stage of a retrieval pipeline (not just the retrieval step but also chunking, reranking, and assembly). Apeiris controls verify permission at retrieval entry but do not explicitly require re-enforcement at each downstream assembly stage. The distinction between service-account permission and end-user authorization context propagation is also not explicitly named."
  },
  {
   "aisvs_id": "C5.2.3",
   "aisvs_chapter": "C05 \u2014 Access Control & Identity for AI Components & Users",
   "aisvs_text": "Verify that sensitive data is retrieved via retrieval pipelines (e.g., RAG queries, embedding lookups) to prevent permanent storage in models.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://data/controls/DI-06",
    "apeiris://data/controls/DA-02",
    "apeiris://knowledge/controls/KI-04"
   ],
   "primary_domains": [
    "data",
    "knowledge"
   ],
   "notes": "DI-06 (Model Memorization Risk Assessment and Output Leakage Prevention) addresses the consequence \u2014 assessing whether sensitive data has been memorized by a model and preventing extraction \u2014 but not the architectural prescription of this requirement. The AISVS requirement is an architectural control: mandate that sensitive data flows through RAG/retrieval at inference time rather than being baked into model weights at training time. No Apeiris control explicitly prescribes this design pattern as a requirement. DA-02 (Data Minimization) reduces data scope but does not distinguish training-time storage from runtime retrieval. KI-04 classifies sensitivity at ingestion but does not gate whether data goes into model weights vs. a retrieval index. This is a genuine gap in coverage of the 'retrieval over training' architectural control."
  },
  {
   "aisvs_id": "C5.2.4",
   "aisvs_chapter": "C05 \u2014 Access Control & Identity for AI Components & Users",
   "aisvs_text": "Verify that post-inference filtering mechanisms prevent responses from including data that the requester is not authorized to receive.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-04",
    "apeiris://security/controls/RT-05"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AB-04 (Output Policy Enforcement) directly addresses this requirement: 'All agent outputs \u2014 text responses, generated content, data extracts, and API payloads \u2014 must pass through a policy enforcement layer that applies content filtering, PII detection and scrubbing, sensitive data classification checks, and output sanitization before delivery to any downstream consumer.' This is a post-inference enforcement layer that prevents unauthorized data from reaching the requester. RT-05 (Apply DLP to agent egress and interactions) provides the complementary data-loss prevention layer at the output boundary. Together these controls directly satisfy the requirement."
  },
  {
   "aisvs_id": "C5.2.5",
   "aisvs_chapter": "C05 \u2014 Access Control & Identity for AI Components & Users",
   "aisvs_text": "Verify that the policy decision point for agent authorization is isolated from the agent's execution environment.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://security/controls/GV-04",
    "apeiris://agentic/controls/AB-02"
   ],
   "primary_domains": [
    "security",
    "agentic"
   ],
   "notes": "GV-04 (Enforce policy as code at run time, in the request path) implies that policy enforcement runs as a distinct enforcement point in the request path \u2014 external to the agent executing the action. AB-02 (Tool-Call Authorization Policy) requires each tool to have an explicit authorization policy, implying an external policy authority. However, neither control explicitly requires architectural isolation of the policy decision point (PDP) from the agent's execution environment. The specific threat this requirement guards against \u2014 an agent subverting its own authorization checks because the PDP runs inside the same process or container \u2014 is not named. Apeiris covers policy-as-code enforcement but not the structural separation that prevents a compromised agent from bypassing or influencing its own PDP."
  },
  {
   "aisvs_id": "C5.2.6",
   "aisvs_chapter": "C05 \u2014 Access Control & Identity for AI Components & Users",
   "aisvs_text": "Verify that privileged access to model weights, training pipelines, and production AI configuration is granted just in time, with a defined maximum session duration and automatic expiry. Zero Standing Privilege (ZSP) to these resources is encouraged.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://identity/controls/IC-04",
    "apeiris://identity/controls/NI-04",
    "apeiris://identity/controls/NI-03",
    "apeiris://security/controls/IA-02"
   ],
   "primary_domains": [
    "identity",
    "security"
   ],
   "notes": "IC-04 (Privileged Identity Management for AI) explicitly requires 'just-in-time elevation, ephemeral credentials, and enhanced monitoring for all AI agent access to sensitive resources.' NI-04 (JIT Credential Issuance) states credentials are 'issued at the moment a specific task is dispatched and revoked immediately on task completion or failure' with 'no standing credentials' between task executions \u2014 which is the operational definition of ZSP. NI-03 enforces bounded maximum lifetimes and automatic expiry. IA-02 requires short-lived task-scoped keys with no long-lived secrets. The specific resources named (model weights, training pipelines, production AI configuration) are not enumerated individually, but the controls apply generally to sensitive AI resources."
  },
  {
   "aisvs_id": "C5.2.7",
   "aisvs_chapter": "C05 \u2014 Access Control & Identity for AI Components & Users",
   "aisvs_text": "Verify that data classification labels propagate to downstream resources (embeddings, prompt caches, model outputs).",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://data/controls/DX-01",
    "apeiris://data/controls/DM-02",
    "apeiris://data/controls/DL-01",
    "apeiris://knowledge/controls/KI-04"
   ],
   "primary_domains": [
    "data",
    "knowledge"
   ],
   "notes": "DX-01 (Data Sensitivity Classification Framework for AI) covers classification of 'AI-derived outputs, model training artifacts, and inference results' within a unified taxonomy. DM-02 requires machine-readable sensitivity labels on data assets at rest. DL-01 tracks end-to-end lineage across transformations and pipelines. KI-04 assigns sensitivity classification at ingestion to govern downstream retrieval access. The gap is propagation specificity: no Apeiris control explicitly requires that a sensitivity label assigned to source data must automatically flow through to its derivative embeddings, prompt cache entries, and model outputs as those artifacts are created. DL-01 tracks lineage but does not require label inheritance. The AI-specific downstream artifacts (embedding indices, prompt caches) are not named in any control. This is a partial coverage \u2014 classification exists but automated downstream label propagation is not required."
  },
  {
   "aisvs_id": "C5.3.1",
   "aisvs_chapter": "C05 \u2014 Access Control & Identity for AI Components & Users",
   "aisvs_text": "Verify that shared model serving infrastructure prevents one tenant's fine-tuning, inference, or embedding operations from influencing or observing another tenant's operations.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://security/controls/EC-01"
   ],
   "primary_domains": [
    "security"
   ],
   "notes": "EC-01 (Run the agent in a sandbox, from process isolation up to micro-VMs) provides the general isolation principle \u2014 containing an agent in a sealed environment scaled to its risk level. This is the closest Apeiris control to multi-tenant isolation in compute. However, the requirement is specifically about shared model serving infrastructure: the scenario where one tenant's fine-tuning job influences another tenant's model weights, or one tenant's inference traffic can be observed by another tenant through side channels, shared caches, or KV cache leakage. Apeiris has no control that addresses multi-tenant model serving isolation specifically \u2014 the cross-contamination risks specific to GPU memory, KV cache sharing, or LoRA adapter isolation in shared inference infrastructure are not covered."
  },
  {
   "aisvs_id": "C5.3.2",
   "aisvs_chapter": "C05 \u2014 Access Control & Identity for AI Components & Users",
   "aisvs_text": "Verify that one tenant cannot influence or observe another tenant's operations through shared compute resources. Satisfying this requirement typically requires hardware partitioning, confidential computing, or dedicated per-tenant compute allocation.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://security/controls/EC-01"
   ],
   "primary_domains": [
    "security"
   ],
   "notes": "EC-01 references isolation 'from process isolation up to micro-VMs' as the spectrum of containment, which touches the lower end of the hardware partitioning spectrum. However, this requirement calls out specific technical countermeasures: hardware partitioning (GPU MIG partitioning, dedicated hardware), confidential computing (Trusted Execution Environments, AMD SEV, Intel TDX), or dedicated per-tenant compute allocation. Apeiris has no control that requires or evaluates any of these mechanisms. Confidential computing is a significant gap \u2014 it is not mentioned anywhere in the Apeiris control corpus. This is a deep infrastructure control that Apeiris currently leaves unaddressed beyond the general sandboxing principle in EC-01."
  },
  {
   "aisvs_id": "C6.1.1",
   "aisvs_chapter": "C06 \u2014 Supply Chain Security for Models",
   "aisvs_text": "Verify that models are scanned for malicious code before import.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://security/controls/AS-06",
    "apeiris://security/controls/AS-02",
    "apeiris://model/controls/LI-03"
   ],
   "primary_domains": [
    "security",
    "model"
   ],
   "notes": "AS-06 enforces cryptographic signature verification as a hard gate before model load and references MITRE AML.T0018 (Backdoor ML Model) as the primary threat. LI-03 rejects and quarantines artifacts where the locally-recomputed SHA-256 does not match the publisher-signed digest. AS-02 applies SAST to agent skill manifests in CI and explicitly cross-references AISVS C6.1.1. Coverage is partial because these controls detect post-signing artifact substitution via hash mismatch, not malicious code embedded in a legitimately-signed model file (e.g., exploitable pickle gadgets, embedded executables in weights shards). Dedicated pre-import malicious code scanning tooling (modelscan, safetensors format enforcement, AV scan of the artifact bundle) is not an explicitly named control step in either domain \u2014 this is a genuine gap for the malware-scanning dimension of C6.1.1."
  },
  {
   "aisvs_id": "C6.1.2",
   "aisvs_chapter": "C06 \u2014 Supply Chain Security for Models",
   "aisvs_text": "Verify that model weights, datasets, and fine-tuning adapters are downloaded only from approved sources.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://model/controls/LI-03",
    "apeiris://model/controls/TG-07",
    "apeiris://model/controls/LI-02",
    "apeiris://security/controls/AS-06"
   ],
   "primary_domains": [
    "model",
    "security"
   ],
   "notes": "All three artifact types are covered. LI-03 step 1 mandates obtaining publisher checksums only from authoritative sources (provider release pages, Sigstore entries) and explicitly prohibits community mirrors; any artifact that does not originate from a verified authoritative source fails the hash comparison gate. TG-07 requires a Third-Party Dataset Registry (TPDR) with mandatory security and legal due diligence before any external dataset is approved for training pipeline use; training pipelines are blocked from pulling 'latest' without a new TPDR review. LI-02 tracks LoRA adapter and PEFT component lineage \u2014 adapter source and version are required registry fields. AS-06 reinforces the gate by re-verifying on every provider, model version, or quantization change."
  },
  {
   "aisvs_id": "C6.1.3",
   "aisvs_chapter": "C06 \u2014 Supply Chain Security for Models",
   "aisvs_text": "Verify that every third-party model artifact can be integrity-verified.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://model/controls/LI-01",
    "apeiris://model/controls/LI-03",
    "apeiris://security/controls/AS-06"
   ],
   "primary_domains": [
    "model",
    "security"
   ],
   "notes": "LI-01 assigns every artifact a globally unique model ID plus a SHA-256 content hash covering weights, tokenizer, and inference configuration, stored in an append-only registry; hash verification is a blocking gate at every pipeline promotion stage. LI-03 requires cryptographic verification against a publisher-signed digest before registration and generates an mSBOM enumerating per-component hashes. AS-06 enforces OpenSSF Model Signing / Sigstore model-transparency verification as a hard gate before model load and re-verifies on any provider, version, or configuration drift. For API-hosted models where weights are inaccessible, LI-03 step 4 requires explicit documentation of the scope limitation with behavioral regression test results as the alternative verification evidence \u2014 this is an honest acknowledgment rather than a full gap."
  },
  {
   "aisvs_id": "C6.1.4",
   "aisvs_chapter": "C06 \u2014 Supply Chain Security for Models",
   "aisvs_text": "Verify that models pass a behavioral acceptance test suite before being promoted to any non-development environment.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://model/controls/EV-01",
    "apeiris://model/controls/EV-02"
   ],
   "primary_domains": [
    "model"
   ],
   "notes": "EV-01 is a direct and precise match: it mandates a blocking CI/CD or MLOps pipeline stage that cannot be bypassed, requiring a passing signed evaluation manifest that references the exact model artifact hash before any promotion decision. EV-02 defines the required evaluation dimensions (task fitness, safety, reliability, policy-conformance, and for generative AI profiles: refusal and alignment tests). The evaluation gate is explicitly environmental-boundary-aware \u2014 the signed manifest is a required precondition for production and any non-development environment promotion, not only the final release stage."
  },
  {
   "aisvs_id": "C6.2.1",
   "aisvs_chapter": "C06 \u2014 Supply Chain Security for Models",
   "aisvs_text": "Verify that every model artifact publishes a version-controlled, machine-readable AI BOM listing datasets, weights, licenses, and data-origin statements.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/AS-06",
    "apeiris://model/controls/LI-03",
    "apeiris://model/controls/LI-05",
    "apeiris://model/controls/LI-08",
    "apeiris://model/controls/LI-02"
   ],
   "primary_domains": [
    "model",
    "security"
   ],
   "notes": "AS-06 step 6 explicitly generates an AI-BOM/SBOM conforming to CISA's seven minimum element clusters \u2014 system-level properties, model components (hashes, architecture, fine-tuning state), dataset properties (lineage, sensitivities), security properties, infrastructure components, SBOM metadata, and KPIs. LI-03 generates an mSBOM per artifact enumerating all component files with individual hashes, license declarations, provenance, and verification timestamp. LI-08 maintains a full license chain record covering training data licenses (from TG records), base model license, and adapter licenses with automated compatibility analysis. LI-05 provides data-origin statements as a mandatory foreign-key link from the model registry entry to TG-layer dataset records. LI-02 provides the version-controlled provenance chain (base model, fine-tune steps, merge contributors, adapters). Together these controls deliver all four BOM components named in the requirement."
  },
  {
   "aisvs_id": "C6.2.2",
   "aisvs_chapter": "C06 \u2014 Supply Chain Security for Models",
   "aisvs_text": "Verify that AI BOMs are cryptographically signed before deployment.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/AS-06",
    "apeiris://model/controls/LI-03",
    "apeiris://model/controls/LI-01"
   ],
   "primary_domains": [
    "model",
    "security"
   ],
   "notes": "AS-06 explicitly requires an ML-BOM with signed provenance binding the weights to their training context, referencing OpenSSF Model Signing and Sigstore model-transparency as the signing mechanism; artifact load is refused if verification fails. LI-03 mandates publisher-signed checksums (from Sigstore or provider release) as the baseline and stores the mSBOM as an immutable registry attachment linked to the LI-01 registry entry \u2014 the immutable registry provides content-addressed integrity protection for the BOM record. LI-01 stores the artifact hash in a cryptographically-signed manifest and enforces hash verification as a blocking deployment gate; the BOM is anchored to this signed manifest. The combination satisfies the pre-deployment signing requirement."
  },
  {
   "aisvs_id": "C6.2.3",
   "aisvs_chapter": "C06 \u2014 Supply Chain Security for Models",
   "aisvs_text": "Verify that AI BOM completeness checks fail the build if any component metadata is missing.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://security/controls/AS-02",
    "apeiris://model/controls/LI-04",
    "apeiris://model/controls/LI-05",
    "apeiris://model/controls/LI-03"
   ],
   "primary_domains": [
    "model",
    "security"
   ],
   "notes": "LI-04 enforces programmatic completeness validation of model cards before registration (schema-based, section-level field validation; incomplete cards are rejected). LI-05 rejects model registration if any TG-layer dataset reference is invalid or flagged for deficiency \u2014 this is a hard gate on data-origin metadata completeness. LI-03 requires the mSBOM as a mandatory registry attachment, implying registration fails without it. AS-02 fails the CI build on high-severity manifest findings and cross-references AISVS C6.2.3 in its own coverage mapping. Coverage is partial rather than direct for two reasons: (1) AS-02's build-fail mechanism targets agent skill and tool manifests in CI, not model AI BOMs specifically; (2) there is no explicitly stated step that fails the MLOps pipeline build when individual AI BOM component metadata fields (e.g., a specific weights shard entry or dataset lineage field) are absent from the mSBOM \u2014 the blocking enforcement exists at registry registration gates and model card validation rather than as a dedicated AI BOM completeness linting step in CI."
  },
  {
   "aisvs_id": "C7.1.1",
   "aisvs_chapter": "C07 \u2014 Model Behavior, Output Control & Safety Assurance",
   "aisvs_text": "Verify that the application validates all model outputs against a defined schema and rejects any output that does not match.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-04",
    "apeiris://agentic/controls/AT-04",
    "apeiris://security/controls/PT-05"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AB-04 (Output Policy Enforcement) mandates that all agent outputs pass through a policy enforcement layer including output sanitization before delivery, but its emphasis is on content filtering and PII scrubbing rather than structural schema validation. AT-04 (Tool Output Sanitization) explicitly requires outputs to be verified against expected response schemas, but applies to tool return values rather than final model responses delivered to users. PT-05 (validate agent output before it reaches other systems) covers output integrity in transit. No Apeiris control is specifically scoped to validating final model response structure against a declared output schema with a reject gate \u2014 this is a gap for the L1 baseline."
  },
  {
   "aisvs_id": "C7.1.2",
   "aisvs_chapter": "C07 \u2014 Model Behavior, Output Control & Safety Assurance",
   "aisvs_text": "Verify that model-generated output is bounded by length limits and termination controls.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-06",
    "apeiris://security/controls/EC-06"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AB-06 (Rate Limiting and Resource Budget Enforcement) explicitly includes per-agent limits on token consumption enforced at the platform level with circuit-breaker behavior \u2014 this covers aggregate output token budgets. EC-06 (Contain runaway loops and over-reach) addresses termination of runaway agentic execution. Neither control is scoped to per-response output length limits or per-inference termination tokens. The L1 requirement for deterministic per-call output bounding is not directly addressed."
  },
  {
   "aisvs_id": "C7.2.1",
   "aisvs_chapter": "C07 \u2014 Model Behavior, Output Control & Safety Assurance",
   "aisvs_text": "Verify that the system assesses the reliability of generated answers using a confidence estimation method.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/BH-01",
    "apeiris://model/controls/EV-02",
    "apeiris://knowledge/controls/KR-04"
   ],
   "primary_domains": [
    "model",
    "knowledge"
   ],
   "notes": "BH-01 (Output Anomaly Detection) monitors production output distributions using statistical process control \u2014 this is a population-level reliability signal, not per-response confidence scoring. EV-02 (Fitness, Safety, Reliability Evaluation) assesses reliability pre-deployment but is a gate control, not a runtime confidence estimator. KR-04 (Retrieval Hallucination Detection) provides a form of per-response reliability assessment for RAG scenarios by detecting claims beyond the retrieved context. No Apeiris control mandates a per-inference confidence estimation method applied to all responses."
  },
  {
   "aisvs_id": "C7.2.2",
   "aisvs_chapter": "C07 \u2014 Model Behavior, Output Control & Safety Assurance",
   "aisvs_text": "Verify that the application automatically blocks answers or switches to a fallback message if the confidence score drops below a defined threshold.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AM-07",
    "apeiris://agentic/controls/AB-04",
    "apeiris://security/controls/RT-04"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AM-07 (Real-Time Alerting and Automated Agent Suspension) provides automated blocking and suspension on detected critical violations without human intervention. RT-04 (Detect anomalies and trigger pause, kill switch) provides anomaly-triggered containment. AB-04's policy enforcement layer can block outputs. However, all three controls are triggered by anomaly/violation detection or policy rules, not by a confidence score threshold. The specific mechanism \u2014 confidence below threshold \u2192 fallback \u2014 is not represented in any Apeiris control."
  },
  {
   "aisvs_id": "C7.2.3",
   "aisvs_chapter": "C07 \u2014 Model Behavior, Output Control & Safety Assurance",
   "aisvs_text": "Verify that for responses classified as high-risk by policy, the system performs an additional verification step.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/OA-02",
    "apeiris://agentic/controls/AO-04",
    "apeiris://security/controls/GV-01"
   ],
   "primary_domains": [
    "model",
    "agentic",
    "security"
   ],
   "notes": "OA-02 (Meaningful Human Oversight for High-Stakes Decisions) requires human verification before high-stakes AI outputs take effect. AO-04 (Human-in-the-Loop Gates for High-Consequence Orchestrations) mandates blocking approval checkpoints for irreversible or regulated-effect pipelines. GV-01 (Require a human hard-stop for irreversible actions) enforces human gates for irreversible actions. These controls collectively cover additional verification for high-consequence outputs but the trigger criterion differs: Apeiris gates on irreversibility and stakes-to-individuals, while C7.2.3 gates on policy-classified risk category applied to any response type."
  },
  {
   "aisvs_id": "C7.3.1",
   "aisvs_chapter": "C07 \u2014 Model Behavior, Output Control & Safety Assurance",
   "aisvs_text": "Verify that automated classifiers scan every response and block content that matches defined harmful content categories.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-04",
    "apeiris://ethics/controls/EF-05",
    "apeiris://ethics/controls/HI-03",
    "apeiris://ethics/controls/HI-07"
   ],
   "primary_domains": [
    "agentic",
    "ethics"
   ],
   "notes": "AB-04 (Output Policy Enforcement) directly requires that all agent outputs \u2014 text responses, generated content, data extracts, and API payloads \u2014 pass through a policy enforcement layer applying content filtering before delivery. This is a direct match for the automated classifier + block requirement. EF-05 (EU AI Act Prohibited Practices Governance) provides the governance framework defining which content categories are prohibited. HI-03 and HI-07 add specific requirements for vulnerable populations and minors. The combination is comprehensive."
  },
  {
   "aisvs_id": "C7.3.2",
   "aisvs_chapter": "C07 \u2014 Model Behavior, Output Control & Safety Assurance",
   "aisvs_text": "Verify that output filters detect and block responses that disclose system prompt content or backend data.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/RT-05",
    "apeiris://agentic/controls/AB-04",
    "apeiris://security/controls/EC-08"
   ],
   "primary_domains": [
    "security",
    "agentic"
   ],
   "notes": "RT-05 (Apply data-loss prevention to agent egress) is a dedicated DLP control at the output boundary \u2014 directly addresses blocking sensitive data on its way out. AB-04 includes sensitive data classification checks on all outputs. EC-08 (Keep secrets out of the prompt and context) prevents system credentials from entering the prompt in the first place, reducing the attack surface. Together these three controls provide layered coverage: prevent injection at input (EC-08), classify and block at output policy layer (AB-04), and DLP scan at egress (RT-05). System prompt leakage and backend data disclosure are addressed."
  },
  {
   "aisvs_id": "C7.3.3",
   "aisvs_chapter": "C07 \u2014 Model Behavior, Output Control & Safety Assurance",
   "aisvs_text": "Verify that model-generated output is prevented from triggering outbound requests.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://security/controls/EC-02",
    "apeiris://security/controls/PT-05"
   ],
   "primary_domains": [
    "security"
   ],
   "notes": "EC-02 (Filter the agent's outbound network traffic) enforces allowlist-based outbound network filtering at the platform level \u2014 the agent can only reach explicitly permitted destinations. PT-05 (Encode and validate the agent's own output before it reaches other systems) validates output before it propagates downstream, reducing the risk of output-embedded URLs or instructions triggering actions. However, neither control specifically targets the SSRF-via-LLM scenario where a crafted model output contains URLs or commands that cause the serving infrastructure to initiate outbound HTTP requests. The network filter in EC-02 mitigates consequences but does not inspect output content for embedded request triggers."
  },
  {
   "aisvs_id": "C7.3.4",
   "aisvs_chapter": "C07 \u2014 Model Behavior, Output Control & Safety Assurance",
   "aisvs_text": "Verify that model outputs are checked for hidden, encoded, or misleading content created through homoglyphs, formatting, metadata, or structured fields.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://security/controls/RT-02",
    "apeiris://security/controls/GV-07",
    "apeiris://agentic/controls/AB-04"
   ],
   "primary_domains": [
    "security",
    "agentic"
   ],
   "notes": "RT-02 (Detect direct and indirect prompt injection at every input and output) scans both inputs and outputs for hidden instructions attempting to hijack the agent, which covers some of the injection-via-encoding threat. GV-07 (Protect humans from being deceived by an agent) addresses deceptive output broadly. AB-04's output sanitization layer provides a hook for encoding normalization. However, homoglyph substitution, Unicode bidirectional overrides, steganographic formatting, and metadata-embedded instructions in structured fields are not explicitly called out in any Apeiris control. This is a specific L3 technique gap."
  },
  {
   "aisvs_id": "C7.4.1",
   "aisvs_chapter": "C07 \u2014 Model Behavior, Output Control & Safety Assurance",
   "aisvs_text": "Verify that responses generated using retrieval-augmented generation (RAG) include attribution to the source documents.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://knowledge/controls/KS-07",
    "apeiris://knowledge/controls/KR-03"
   ],
   "primary_domains": [
    "knowledge"
   ],
   "notes": "KS-07 (Source Attribution and Citation Disclosure Requirements) directly requires that AI systems cite the knowledge sources used when making factual claims, including source register ID, authority tier, and retrieval timestamp, and emit a disclosure flag when no supporting source exists. KR-03 (Citation Fidelity and Accuracy Enforcement) requires that cited sources accurately identify the source document, relevant passage, and supported claim. Together these two controls fully address C7.4.1."
  },
  {
   "aisvs_id": "C7.4.2",
   "aisvs_chapter": "C07 \u2014 Model Behavior, Output Control & Safety Assurance",
   "aisvs_text": "Verify that RAG attributions are derived from retrieval metadata and are not generated by the model, so provenance cannot be fabricated.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://knowledge/controls/KR-03",
    "apeiris://knowledge/controls/KM-05"
   ],
   "primary_domains": [
    "knowledge"
   ],
   "notes": "KR-03 (Citation Fidelity and Accuracy Enforcement) explicitly requires automated verification to confirm citations are not fabricated, misattributed, or materially misrepresented \u2014 directly addressing the anti-fabrication requirement. KM-05 (Knowledge-to-Output Lineage Tracking) provides the infrastructure: every AI-generated output drawing on retrieved knowledge must be traceable to specific knowledge chunks, asset versions, and retrieval queries, creating an auditable lineage graph. Provenance is anchored in retrieval metadata, not model generation, making fabrication detectable."
  },
  {
   "aisvs_id": "C7.4.3",
   "aisvs_chapter": "C07 \u2014 Model Behavior, Output Control & Safety Assurance",
   "aisvs_text": "Verify that claims in a RAG response can be traced to the retrieved chunk.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://knowledge/controls/KR-02",
    "apeiris://knowledge/controls/KM-05",
    "apeiris://knowledge/controls/KR-04"
   ],
   "primary_domains": [
    "knowledge"
   ],
   "notes": "KR-02 (Grounding Completeness Requirements) requires that retrieved content substantively supports each factual claim in the generated response \u2014 not merely shares topical overlap \u2014 and mandates flagging or suppression when grounding coverage falls below completeness thresholds. KM-05 (Knowledge-to-Output Lineage Tracking) creates an auditable lineage graph from output to the specific retrieved chunks, asset versions, and retrieval queries that informed each claim. KR-04 (Retrieval Hallucination Detection) identifies claims that exceed or contradict the retrieved context. Together these controls provide complete claim-to-chunk traceability."
  },
  {
   "aisvs_id": "C7.4.4",
   "aisvs_chapter": "C07 \u2014 Model Behavior, Output Control & Safety Assurance",
   "aisvs_text": "Verify that generated media is watermarked to prove it was AI-generated.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://model/controls/BH-09"
   ],
   "primary_domains": [
    "model"
   ],
   "notes": "BH-09 (Synthetic-Content Provenance, Disclosure and Traceability) directly addresses this requirement: it mandates embedding cryptographic provenance metadata in AI-generated content, applying mandatory disclosure labels, and maintaining a traceability chain linking content back to the generating model version. This covers watermarking at the content level with cryptographic integrity and regulatory disclosure requirements, enabling verification that media is AI-generated."
  },
  {
   "aisvs_id": "C8.1.1",
   "aisvs_chapter": "C08 \u2014 Memory, Embeddings & Vector Database Security",
   "aisvs_text": "Verify that vector identifiers and namespaces enforce uniqueness per tenant and prevent cross-tenant collisions.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://knowledge/controls/KM-02",
    "apeiris://data/controls/DA-01"
   ],
   "primary_domains": [
    "knowledge",
    "data"
   ],
   "notes": "KM-02 (Knowledge Base Segmentation and Access Control) enforces segment-level isolation where AI agents can only access segments for which they hold explicit authorization \u2014 the closest analog to tenant namespace isolation. DA-01 (AI Data Access Authorization Framework) provides the RBAC/ABAC framework governing per-tenant data boundaries. However, neither control specifically mandates vector-store-level identifier uniqueness guarantees or technical collision prevention between tenant namespaces. The requirement targets a vector-DB implementation property; Apeiris covers the access governance layer but not the identifier-space integrity constraint."
  },
  {
   "aisvs_id": "C8.1.2",
   "aisvs_chapter": "C08 \u2014 Memory, Embeddings & Vector Database Security",
   "aisvs_text": "Verify that document metadata tags are immutable after the initial write.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://knowledge/controls/KC-04",
    "apeiris://knowledge/controls/KM-03",
    "apeiris://knowledge/controls/KI-07",
    "apeiris://data/controls/DI-01"
   ],
   "primary_domains": [
    "knowledge",
    "data"
   ],
   "notes": "KC-04 (Knowledge Version Control and Change History) mandates immutable version histories where prior content is preserved and stable references cannot silently redirect to updated content. KM-03 (Knowledge Versioning and Change History) similarly requires immutably preserved prior states. KI-07 (Ingestion Audit Trail) maintains a tamper-evident log of all knowledge base writes. DI-01 establishes cryptographic fingerprints at ingest. Together these enforce auditability and detect unauthorized change, which partially satisfies the immutability intent. However, no control explicitly declares metadata tags to be write-once after initial creation as a distinct property \u2014 Apeiris models this as versioned-with-history rather than strictly immutable at the tag level."
  },
  {
   "aisvs_id": "C8.1.3",
   "aisvs_chapter": "C08 \u2014 Memory, Embeddings & Vector Database Security",
   "aisvs_text": "Verify that retrieval operations enforce scope constraints.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://knowledge/controls/KR-05",
    "apeiris://knowledge/controls/KM-02",
    "apeiris://knowledge/controls/KS-06"
   ],
   "primary_domains": [
    "knowledge"
   ],
   "notes": "KR-05 (Retrieval Permission Verification) directly mandates that every retrieval operation verifies requesting-user or agent authorization for each candidate document or chunk before inclusion in the retrieval context, enforcing the same access controls as direct document access. KM-02 enforces access control policies at the retrieval layer so agents can only access their authorized knowledge segments. KS-06 (Knowledge Domain Boundary Definition) enforces that out-of-boundary retrieval attempts are blocked and logged at the retrieval pipeline layer. Three complementary controls collectively provide strong direct coverage."
  },
  {
   "aisvs_id": "C8.2.1",
   "aisvs_chapter": "C08 \u2014 Memory, Embeddings & Vector Database Security",
   "aisvs_text": "Verify that sensitive fields are detected before embedding and are masked, tokenized, or dropped.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://knowledge/controls/KI-04",
    "apeiris://privacy/controls/DP-03",
    "apeiris://privacy/controls/DP-02",
    "apeiris://data/controls/DM-02"
   ],
   "primary_domains": [
    "knowledge",
    "privacy",
    "data"
   ],
   "notes": "KI-04 (Content Sensitivity Classification at Ingestion) mandates automated sensitivity classification at the ingestion boundary that governs which retrieval contexts and roles may access ingested content. DP-03 (Data Minimization Enforcement) technically rejects collection of personal data beyond necessity at ingestion. DP-02 (Pseudonymization Implementation) applies pseudonymization to personal data in AI pipelines. DM-02 (Data Classification and Sensitivity Tagging at Rest) enforces sensitivity labeling with access-control consequences. These controls collectively govern detection and access restriction of sensitive content, but the AISVS requirement specifically mandates pre-embedding transformation (mask, tokenize, or drop fields before vectorization). Apeiris classifies and restricts access to sensitive content post-ingestion rather than explicitly mandating field-level transformation prior to the embedding step \u2014 a gap at the pre-vectorization processing layer."
  },
  {
   "aisvs_id": "C8.2.2",
   "aisvs_chapter": "C08 \u2014 Memory, Embeddings & Vector Database Security",
   "aisvs_text": "Verify that vectors that fall outside normal clustering patterns are flagged and quarantined before entering production indices.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://data/controls/DV-03",
    "apeiris://data/controls/DV-02",
    "apeiris://knowledge/controls/KI-06"
   ],
   "primary_domains": [
    "data",
    "knowledge"
   ],
   "notes": "DV-03 (Statistical Distribution Validation) mandates continuous monitoring of AI inputs against statistical baselines with automated alerts and pipeline holds when drift exceeds thresholds. DV-02 (Data Quality Gate Enforcement) routes data failing quality thresholds to a quarantine process tracked through resolution. KI-06 (Pre-Ingestion Content Quality Gates) enforces quality standards including accuracy and factual consistency before knowledge base acceptance. These controls provide the closest analogs \u2014 statistical anomaly detection plus quarantine \u2014 but the specific requirement targets embedding-level clustering anomalies (outlier vectors in latent space), which is a vector-database-specific technique not explicitly addressed in Apeiris. The data-layer statistical validation and quarantine patterns partially satisfy the intent."
  },
  {
   "aisvs_id": "C8.2.3",
   "aisvs_chapter": "C08 \u2014 Memory, Embeddings & Vector Database Security",
   "aisvs_text": "Verify that agent outputs and tool outputs are not automatically written to trusted agent memory without explicit source validation.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AT-04",
    "apeiris://agentic/controls/AB-05",
    "apeiris://agentic/controls/AO-03"
   ],
   "primary_domains": [
    "agentic"
   ],
   "notes": "AT-04 (Tool Output Sanitization and Integrity Verification) mandates that all tool outputs are verified against expected response schemas and sanitized before being incorporated into the agent's context or reasoning \u2014 directly covering validation before context (ephemeral memory) incorporation. AB-05 (Prompt Injection Detection and Defense) explicitly covers indirect injection via retrieved documents or tool outputs before they influence agent behavior. AO-03 (Orchestration Message Integrity) ensures cryptographic integrity of inter-agent messages. However, the requirement specifically targets writes to persistent trusted agent memory as a distinct, gated operation. Apeiris addresses validation before context incorporation but does not explicitly model persistent agent memory as a separate controlled write target requiring its own explicit source-validation gate."
  },
  {
   "aisvs_id": "C8.2.4",
   "aisvs_chapter": "C08 \u2014 Memory, Embeddings & Vector Database Security",
   "aisvs_text": "Verify that content crafted to manipulate retrieval results is detected and rejected or quarantined before vectorization.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://knowledge/controls/KI-02",
    "apeiris://agentic/controls/AB-05"
   ],
   "primary_domains": [
    "knowledge",
    "agentic"
   ],
   "notes": "KI-02 (Knowledge Poisoning Detection and Prevention) directly and explicitly mandates that all content submitted for ingestion must pass automated adversarial content screening to detect manipulation, injection payloads, and coordinated poisoning attempts before being written to the knowledge base \u2014 a precise match to the pre-vectorization detection-and-reject requirement. AB-05 (Prompt Injection Detection and Defense) extends coverage to indirect injection via retrieved documents. KI-02 is the primary control and provides direct coverage; the adversarial screening gate at ingestion is exactly the control AISVS C8.2.4 requires."
  },
  {
   "aisvs_id": "C8.2.5",
   "aisvs_chapter": "C08 \u2014 Memory, Embeddings & Vector Database Security",
   "aisvs_text": "Verify that new content written to memory is checked for contradictions with what is already stored and that conflicts trigger alerts.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://knowledge/controls/KS-05",
    "apeiris://knowledge/controls/KI-06"
   ],
   "primary_domains": [
    "knowledge"
   ],
   "notes": "KS-05 (Competing Source Conflict Resolution) directly mandates automated conflict detection in the indexing pipeline, a tiered escalation path based on authority differential, and auditable resolution records for every identified contradiction between knowledge sources. This is a precise match to the requirement: check new content against stored content for contradictions and trigger alerts. KI-06 (Pre-Ingestion Content Quality Gates) reinforces this by requiring factual consistency as a quality criterion before acceptance. KS-05 is the primary control and provides direct coverage."
  },
  {
   "aisvs_id": "C8.3.1",
   "aisvs_chapter": "C08 \u2014 Memory, Embeddings & Vector Database Security",
   "aisvs_text": "Verify that expired vectors are excluded from retrieval results.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://knowledge/controls/KC-01",
    "apeiris://knowledge/controls/KC-02"
   ],
   "primary_domains": [
    "knowledge"
   ],
   "notes": "KC-01 (Knowledge Staleness Classification Policy) mandates that every knowledge asset is assigned a staleness class defining its maximum permissible age and the required action upon expiry. KC-02 (Automated Staleness Detection) mandates continuous monitoring against staleness-tier thresholds with automatic flagging, quarantine, or alerting when content exceeds its maximum permissible age. Together these two controls directly address expired vector exclusion: KC-01 defines the expiry policy and KC-02 enforces it via automated detection and quarantine that removes expired content from the active retrieval index."
  },
  {
   "aisvs_id": "C8.3.2",
   "aisvs_chapter": "C08 \u2014 Memory, Embeddings & Vector Database Security",
   "aisvs_text": "Verify that memory can be reset.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://knowledge/controls/KM-04",
    "apeiris://knowledge/controls/KC-03",
    "apeiris://data/controls/DM-03",
    "apeiris://privacy/controls/DS-04"
   ],
   "primary_domains": [
    "knowledge",
    "data",
    "privacy"
   ],
   "notes": "KM-04 (Knowledge Archival and Retention Policy) mandates deletion authorization workflows and legal hold capabilities. KC-03 (Knowledge Refresh Scheduling and Execution) provides triggered reset/refresh pathways with full execution audit trails. DM-03 (Data Retention and Disposal Governance) requires secure disposal with deletion certificates or cryptographic erasure evidence. DS-04 (Erasure and Anonymization) covers right-to-erasure including AI training data contributions. Together these establish the governance framework confirming that memory deletion and reset are controlled, auditable operations. The requirement is broad and intentionally minimal ('can be reset'); Apeiris satisfies it through a governed deletion-and-refresh capability across multiple controls, though it frames this as a lifecycle governance process rather than mandating a single operational reset mechanism."
  },
  {
   "aisvs_id": "C8.3.3",
   "aisvs_chapter": "C08 \u2014 Memory, Embeddings & Vector Database Security",
   "aisvs_text": "Verify that quarantined content is retained but excluded from all retrieval results.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://knowledge/controls/KC-02",
    "apeiris://data/controls/DV-02",
    "apeiris://knowledge/controls/KI-07"
   ],
   "primary_domains": [
    "knowledge",
    "data"
   ],
   "notes": "KC-02 (Automated Staleness Detection) mandates quarantine as an action for content exceeding staleness thresholds. DV-02 (Data Quality Gate Enforcement) routes data failing quality thresholds to a quarantine process tracked through resolution. KI-07 (Ingestion Audit Trail) maintains a tamper-evident log of all knowledge base operations, ensuring quarantine events are recorded and retained. These controls establish the quarantine-and-exclude pattern. However, the specific semantics of 'retained-but-excluded' \u2014 explicitly preserving the quarantined payload for forensic investigation and audit while simultaneously blocking it from all retrieval results \u2014 is implicit rather than explicitly mandated. Apeiris records quarantine events in audit trails (KI-07) and blocks quarantined content from retrieval (KC-02, DV-02), but does not explicitly state that the quarantined content payload itself must be preserved (as opposed to merely recording that it was quarantined)."
  },
  {
   "aisvs_id": "C9.1.1",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that per-tool quotas and timeouts (e.g., CPU, memory, disk, egress, and execution time) are enforced.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-06",
    "apeiris://security/controls/EC-05",
    "apeiris://security/controls/EC-06"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AB-06 (Rate Limiting and Resource Budget Enforcement) requires per-agent limits on API call rates, token consumption, cost expenditure, and compute time enforced by the platform with automated circuit-breaker behavior. EC-05 caps resource use and spend at the platform level. EC-06 contains runaway loops and over-reach. The per-tool granularity (CPU, disk, egress) is implied by platform enforcement but not called out at per-tool resolution; slight granularity gap but coverage is substantive."
  },
  {
   "aisvs_id": "C9.1.2",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that per-execution budgets (e.g., max recursion depth, token use, and monetary spend) are configured and enforced by the runtime.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-06",
    "apeiris://security/controls/EC-05",
    "apeiris://agentic/controls/AO-05",
    "apeiris://security/controls/EC-06"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AB-06 explicitly covers token consumption and monetary cost budgets enforced by the platform. AO-05 (Orchestration Loop and Escalation Detection) addresses recursion depth through automated loop and escalation detection with circuit-breaker controls. EC-05 and EC-06 reinforce spend caps and runaway containment. Together these cover all three budget types in the requirement."
  },
  {
   "aisvs_id": "C9.1.3",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that a swarm-level kill-switch exists that can halt all active agent instances.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AM-07",
    "apeiris://security/controls/RT-04"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AM-07 provides automated agent suspension capability and RT-04 covers kill-switch/containment triggers. However, neither control explicitly defines a swarm-level or fleet-wide coordinated halt that terminates all active instances simultaneously. The controls address individual agent suspension or anomaly-triggered containment. A dedicated swarm-level emergency stop control is a gap."
  },
  {
   "aisvs_id": "C9.2.1",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that the agent runtime blocks execution of privileged, high-impact, or irreversible actions until explicit human approval is received and verified.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/GV-01",
    "apeiris://agentic/controls/AO-04",
    "apeiris://agentic/controls/AB-03",
    "apeiris://agentic/controls/AT-05"
   ],
   "primary_domains": [
    "security",
    "agentic"
   ],
   "notes": "GV-01 requires a human hard-stop for irreversible actions. AO-04 mandates mandatory human approval checkpoints that block pipeline execution until an authorized reviewer explicitly approves. AB-03 establishes the reversibility gate. AT-05 requires additional authorization (human approval, dual-control, time-delayed execution) before irreversible tools execute. Coverage is strong across all three action categories."
  },
  {
   "aisvs_id": "C9.2.2",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that approval requests display canonicalized and complete action parameters, such as diffs, commands, recipients, amounts, resources, and scopes, without truncation or unsafe transformation.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AO-04",
    "apeiris://authority/controls/PA-07"
   ],
   "primary_domains": [
    "agentic",
    "authority"
   ],
   "notes": "AO-04 covers the human approval checkpoint and PA-07 records approval events with decision rationale, but neither control specifically mandates that approval UIs present canonicalized, complete, non-truncated action parameters. The requirement to prevent unsafe transformation of displayed parameters (e.g., Unicode homoglyphs, whitespace injection in displayed commands) is a gap. Partial coverage from the gate infrastructure controls."
  },
  {
   "aisvs_id": "C9.2.3",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that each high-impact action has a trusted reversibility classification, such as read-only, reversible, externally reversible, or irreversible.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-03",
    "apeiris://agentic/controls/AT-05"
   ],
   "primary_domains": [
    "agentic"
   ],
   "notes": "AB-03 requires that every action type available to an agent be classified as reversible or irreversible, with irreversible actions subject to an explicit authorization gate. AT-05 further enumerates categories of irreversible tools (delete, financial transaction, external communication). The four-class taxonomy in the AISVS requirement (read-only, reversible, externally reversible, irreversible) is slightly more granular than AB-03's binary classification, but the coverage is substantively direct."
  },
  {
   "aisvs_id": "C9.2.4",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that the agent runtime enforces reversibility classifications by blocking, requiring approval, or restricting actions based on their impact and ability to be reversed.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-03",
    "apeiris://security/controls/GV-01",
    "apeiris://agentic/controls/AT-05",
    "apeiris://security/controls/GV-06"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AB-03 requires irreversible actions to pass through an authorization gate at the enforcement layer. GV-01 mandates blocking until human approval. AT-05 adds further access controls on high-risk tools. GV-06 caps the rate and volume of irreversible actions even with approvals. Together these controls directly satisfy runtime enforcement of reversibility classifications."
  },
  {
   "aisvs_id": "C9.2.5",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that any self-modification capability (e.g., prompt rewriting, tool-list changes, parameter updates) is restricted by enforceable boundaries.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-01",
    "apeiris://agentic/controls/AB-02",
    "apeiris://authority/controls/PV-02"
   ],
   "primary_domains": [
    "agentic",
    "authority"
   ],
   "notes": "AB-01 (Authorized Action Scope Manifest) blocks execution of any action not in the manifest at the enforcement layer, which implicitly covers unauthorized tool-list expansion. AB-02 restricts which tools an agent may call under what conditions. PV-02 validates that runtime actions fall within the declared operating intent boundary. However, no control explicitly names self-modification (prompt rewriting, parameter updates) as a distinct threat category requiring enforceable restriction. This is a named gap in the control vocabulary."
  },
  {
   "aisvs_id": "C9.2.6",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that agentic systems include an AI-augmented review of planned high-risk actions before execution that adds to, and does not replace, the deterministic policy gate.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AO-04"
   ],
   "primary_domains": [],
   "notes": "Gap. Apeiris has strong deterministic gate controls (GV-01, AO-04, AB-03) and behavioral monitoring (AM-02, AM-07), but no control defines an AI-augmented pre-execution review layer that is explicitly additive to \u2014 not a replacement for \u2014 the deterministic policy gate. This defense-in-depth pattern (dual-layer: deterministic + AI-assisted) is not represented in the Apeiris control vocabulary. [closed 2026-07-08 via AO-04]"
  },
  {
   "aisvs_id": "C9.2.7",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that the AI-augmented review mechanism is protected against manipulation by adversarial inputs, and cannot be overridden or bypassed through prompt injection.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-05",
    "apeiris://security/controls/RT-02",
    "apeiris://security/controls/PT-08"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AB-05 (Prompt Injection Detection and Defense) and RT-02 (Detect direct and indirect prompt injection) address the underlying threat. PT-08 (instruction hierarchy) prevents tool output from being treated as commands. However, since C9.2.6 coverage is 'none' (the AI-augmented review mechanism itself is a gap), this control is partially relevant as hardening for any such mechanism but cannot be considered complete coverage."
  },
  {
   "aisvs_id": "C9.2.8",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that approvals are cryptographically bound to action parameters, requester identity, execution context, and a unique single-use nonce.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AA-05",
    "apeiris://agentic/controls/AO-03",
    "apeiris://authority/controls/PA-05"
   ],
   "primary_domains": [
    "agentic",
    "authority"
   ],
   "notes": "AA-05 (Session Token Binding and Anti-Replay Controls) cryptographically binds tokens to agent instance and session context with unique nonces for anti-replay. AO-03 provides cryptographic integrity protection for orchestration messages. PA-05 creates a 'cryptographically linked approval chain.' However, the specific binding of an approval artifact to action parameters + requester identity + execution context + single-use nonce at the approval gate is not explicitly codified as a standalone control. Partial coverage from constituent building blocks."
  },
  {
   "aisvs_id": "C9.2.9",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that cryptographic key material or credentials used to issue approvals are isolated from the agent runtime.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://security/controls/EC-08",
    "apeiris://identity/controls/NI-07",
    "apeiris://identity/controls/NI-04"
   ],
   "primary_domains": [
    "security",
    "identity"
   ],
   "notes": "EC-08 prohibits secrets from appearing in the agent's prompt or context. NI-07 requires all credentials to be stored in approved secrets management systems outside the agent runtime. NI-04 (Just-In-Time Credential Issuance) ensures no standing credentials exist in the agent runtime between tasks. These controls collectively address isolation of credentials from agent context, but none specifically targets the approval issuance key as a distinct, higher-sensitivity artifact requiring its own isolation plane."
  },
  {
   "aisvs_id": "C9.2.10",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that approval gates for multi-step or multi-agent action chains enforce the highest-impact reversibility classification present anywhere in the chain.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-03",
    "apeiris://agentic/controls/AO-04",
    "apeiris://identity/controls/DE-02"
   ],
   "primary_domains": [
    "agentic",
    "identity"
   ],
   "notes": "AB-03 establishes reversibility classification gates; AO-04 places human approval at high-consequence orchestration checkpoints. DE-02 (Scope Boundary Enforcement) enforces that delegated scope is always the intersection of parent scope and granted subset \u2014 not a union \u2014 which embodies the same conservative propagation principle. However, no control explicitly states that a multi-step chain must inherit and enforce the worst-case (highest-impact) reversibility class found at any node in the chain."
  },
  {
   "aisvs_id": "C9.3.1",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that each tool/plugin executes in a least-privilege sandbox or is otherwise isolated from model operations.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/EC-01",
    "apeiris://agentic/controls/AT-06",
    "apeiris://agentic/controls/AT-02"
   ],
   "primary_domains": [
    "security",
    "agentic"
   ],
   "notes": "EC-01 requires agents (and implicitly their tools) to run in sandboxed runtime environments scaled to their risk level, up to micro-VM isolation. AT-06 mandates that third-party plugins execute within sandboxed runtime environments that limit access to agent context and host infrastructure. AT-02 (Tool Permission Scoping) enforces least-privilege grant of tool access. Coverage is direct across both isolation and least-privilege dimensions."
  },
  {
   "aisvs_id": "C9.3.2",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that tool outputs are validated against schemas.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AT-04",
    "apeiris://security/controls/PT-04"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AT-04 (Tool Output Sanitization and Integrity Verification) requires all tool outputs to be verified against expected response schemas and confirmed within expected structural bounds before incorporation into agent context. PT-04 treats all tool results as untrusted and mandates validation before acting on them. Direct and complete coverage."
  },
  {
   "aisvs_id": "C9.3.3",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that tool manifests declare required privileges, resource limits, and output validation requirements.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AT-01",
    "apeiris://security/controls/PT-03"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AT-01 (Tool and Plugin Registry) requires each tool to have a registry entry recording its capability description, owner, risk classification, version, and approval status. PT-03 verifies the integrity of tool manifests. However, no control explicitly mandates that tool manifests must declare resource limits or output validation requirements as required manifest fields. The registry concept is present; the required manifest schema fields for privileges and resource limits are not explicitly specified."
  },
  {
   "aisvs_id": "C9.3.4",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that the runtime enforces the privileges, resource limits, and output-validation requirements declared in tool manifests.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AT-02",
    "apeiris://agentic/controls/AB-06",
    "apeiris://agentic/controls/AT-04",
    "apeiris://security/controls/PT-02"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AT-02 enforces tool permission scoping at runtime. AB-06 enforces resource budgets at the platform level. AT-04 enforces output schema validation before tool output reaches the agent. PT-02 governs which tool calls are authorized. Together these controls address runtime enforcement of all three manifest dimensions (privileges, resources, output validation), even though C9.3.3 notes the manifest declaration standard itself is a partial gap."
  },
  {
   "aisvs_id": "C9.3.5",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that components processing untrusted data are isolated from tool-calling capabilities, ensuring that compromised data processing cannot trigger unauthorized tool invocations.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://security/controls/EC-01",
    "apeiris://security/controls/PT-08",
    "apeiris://agentic/controls/AT-04"
   ],
   "primary_domains": [
    "security",
    "agentic"
   ],
   "notes": "EC-01 provides sandbox isolation at the runtime level. PT-08 (instruction hierarchy) prevents tool output from being treated as commands by the agent, which partially addresses the injection vector. AT-04 sanitizes tool outputs before they can influence the agent. However, no control explicitly defines an architectural boundary between untrusted data ingestion paths and the tool-calling capability plane as separate subsystems. This is an architectural isolation requirement not fully captured."
  },
  {
   "aisvs_id": "C9.3.6",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that there is architectural separation between processing of untrusted tool outputs and agent operations.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://security/controls/PT-08",
    "apeiris://agentic/controls/AT-04",
    "apeiris://security/controls/EC-01"
   ],
   "primary_domains": [
    "security",
    "agentic"
   ],
   "notes": "PT-08 enforces an instruction hierarchy so tool output is treated as data, not commands. AT-04 sanitizes and validates tool outputs before they enter agent reasoning. EC-01 provides runtime sandbox isolation. However, these are content-filtering and access controls rather than explicit architectural separation requirements. The AISVS requirement implies a structural/topological constraint (separate processing pipelines) that goes beyond what Apeiris currently codifies."
  },
  {
   "aisvs_id": "C9.3.7",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that external resources named in model output are verified against an approved allow-list or registry before the agent installs or invokes them.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AT-01",
    "apeiris://security/controls/PT-02",
    "apeiris://security/controls/PT-03"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AT-01 (Tool and Plugin Registry) establishes the authoritative allow-list of approved tools that must have a registry entry before being available for use. PT-02 governs which tool calls are authorized by checking against the registry. PT-03 verifies manifest integrity before tool installation. Together these controls directly implement allow-list gating for external resources before agent invocation."
  },
  {
   "aisvs_id": "C9.3.8",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that policy violations trigger automated tool containment.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AM-07",
    "apeiris://security/controls/RT-04"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AM-07 (Real-Time Alerting and Automated Agent Suspension) explicitly provides automated suspension of offending agents without human intervention on critical violations, including policy violations. RT-04 triggers pause, kill-switch, or containment on detected anomalies. Direct coverage for automated containment on policy violations."
  },
  {
   "aisvs_id": "C9.4.1",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that each agent instance has a unique cryptographic identity and authenticates as a first-class principal to downstream systems.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://identity/controls/II-03",
    "apeiris://identity/controls/II-01",
    "apeiris://agentic/controls/AA-01",
    "apeiris://agentic/controls/AA-03",
    "apeiris://security/controls/IA-01"
   ],
   "primary_domains": [
    "identity",
    "agentic",
    "security"
   ],
   "notes": "II-03 cryptographically binds each AI agent to a unique key pair at provisioning. II-01 provides the authoritative agent identity registry. AA-01 requires every agent to prove its identity at the moment it invokes a tool via signed credentials (JWT, PASETO, client cert). AA-03 mandates mTLS for service-to-service connections. IA-01 prohibits shared or human logins for agents. This requirement is among the most thoroughly covered in the Apeiris control set."
  },
  {
   "aisvs_id": "C9.4.2",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that agent-initiated actions are cryptographically bound to each step of the execution chain for non-repudiation.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/IA-06",
    "apeiris://agentic/controls/AO-03",
    "apeiris://security/controls/GV-02"
   ],
   "primary_domains": [
    "security",
    "agentic"
   ],
   "notes": "IA-06 explicitly binds a signed, end-to-end provenance chain to every agent action across the full delegation path (person \u2192 agents \u2192 tools). AO-03 provides cryptographic integrity protection for every message in an orchestration pipeline. GV-02 maintains an immutable tamper-evident audit trail. This is a core Apeiris strength \u2014 chain-of-custody and non-repudiation across multi-agent orchestration."
  },
  {
   "aisvs_id": "C9.4.3",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that agent identity credentials rotate on a defined schedule.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://identity/controls/NI-03",
    "apeiris://agentic/controls/AA-02",
    "apeiris://security/controls/IA-02"
   ],
   "primary_domains": [
    "identity",
    "agentic",
    "security"
   ],
   "notes": "NI-03 (Credential Lifetime and Forced Rotation) defines bounded maximum credential lifetimes by risk level, with rotation triggered on schedule, security events, task completion, and deployment updates. AA-02 requires API keys and bearer tokens to have enforced short lifetimes with automatic rotation before expiry. IA-02 mandates short-lived, task-scoped keys. Direct and complete coverage."
  },
  {
   "aisvs_id": "C9.4.4",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that agent state persisted between invocations is integrity-protected.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://security/controls/EC-03",
    "apeiris://security/controls/GV-02"
   ],
   "primary_domains": [
    "security"
   ],
   "notes": "EC-03 addresses memory hygiene (keep memory short-lived, validate anything written to it) which partially mitigates state tampering. GV-02 provides tamper-evident audit trails for agent actions. However, neither control explicitly requires cryptographic integrity protection (e.g., HMAC or signing) of persisted agent state between invocations as a stored artifact. This is a gap, particularly relevant for long-running agent workflows that rely on checkpointed state."
  },
  {
   "aisvs_id": "C9.5.1",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that agent actions are authorized against fine-grained policies enforced by the runtime that restrict which tools an agent may invoke, and which parameter values it may supply.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-02",
    "apeiris://agentic/controls/AB-01",
    "apeiris://security/controls/GV-04",
    "apeiris://agentic/controls/AT-03"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AB-02 (Tool-Call Authorization Policy) specifies 'which agent roles may call it, under what conditions, with what parameter constraints' \u2014 directly matching tool and parameter-level fine-grained authorization. AB-01 provides the action scope manifest enforced at the runtime boundary. GV-04 enforces policy as code in the request path. AT-03 validates parameter values against declared schemas before execution. Coverage is direct and comprehensive."
  },
  {
   "aisvs_id": "C9.5.2",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that when an agent acts on a user's behalf, the runtime propagates an integrity-protected, scope-limited token that carries the user's authorization context and is enforced at every downstream call.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://identity/controls/DE-04",
    "apeiris://identity/controls/DE-02",
    "apeiris://identity/controls/IF-06",
    "apeiris://security/controls/IA-03"
   ],
   "primary_domains": [
    "identity",
    "security"
   ],
   "notes": "DE-04 (Task-Scoped Delegation) requires all delegations to be bound to specific task type, target resources, and expiry time. DE-02 enforces that delegated scope is always the intersection of parent scope and granted subset, never expanded. IF-06 requires cryptographic validation of identity tokens at every service the agent accesses, with client-bound tokens to prevent replay. IA-03 requires explicit approval before the agent acts on user's behalf for sensitive steps. Direct and complete coverage."
  },
  {
   "aisvs_id": "C9.5.3",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that all access control decisions are enforced by application logic or a policy engine, never by the AI model itself.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/GV-04",
    "apeiris://agentic/controls/AB-02",
    "apeiris://authority/controls/PA-02"
   ],
   "primary_domains": [
    "security",
    "agentic",
    "authority"
   ],
   "notes": "GV-04 explicitly requires enforcement via code 'that actually blocks bad actions in the moment, not a document people hope agents follow,' and places enforcement 'in the request path' rather than trusting model output. AB-02 defines authorization policy at the infrastructure level, not within model reasoning. PA-02 (Approval Limit Enforcement) checks proposed actions against authority thresholds before execution. Direct coverage of the core principle."
  },
  {
   "aisvs_id": "C9.5.4",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that secrets and credentials required by an agent at runtime are not exposed within the model's observable context, including the context window, system prompts, or tool call parameters.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/EC-08",
    "apeiris://identity/controls/NI-07",
    "apeiris://identity/controls/IM-07"
   ],
   "primary_domains": [
    "security",
    "identity"
   ],
   "notes": "EC-08 explicitly prohibits secrets from appearing in the agent's text context, noting 'anything in context can be pulled back out.' NI-07 prohibits credential storage in model prompts, environment variables, code repositories, or logs. IM-07 continuously scans prompt templates and logging outputs for exposed credentials. Direct and comprehensive coverage including all three observable surfaces named in the requirement."
  },
  {
   "aisvs_id": "C9.5.5",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that inter-agent task delegation is restricted by an explicit authorization policy.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AO-02",
    "apeiris://identity/controls/DE-01",
    "apeiris://agentic/controls/AO-01",
    "apeiris://identity/controls/DE-03"
   ],
   "primary_domains": [
    "agentic",
    "identity"
   ],
   "notes": "AO-02 (Sub-Agent Authorization and Capability Delegation) requires orchestrators to only delegate explicitly authorized capability subsets with delegation tokens encoding scope, expiry, and revocation conditions. DE-01 requires every agent action to be traceable to a signed, auditable delegation chain. AO-01 provides the multi-agent trust graph as the authoritative authorization record. DE-03 (Delegation Depth Limits) adds constraints on delegation chain length. Direct and strong coverage."
  },
  {
   "aisvs_id": "C9.5.6",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that long-running agent sessions re-evaluate current backend authorization policy on every privileged action.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/IA-04",
    "apeiris://security/controls/GV-04",
    "apeiris://authority/controls/PV-08"
   ],
   "primary_domains": [
    "security",
    "authority"
   ],
   "notes": "IA-04 explicitly requires continuous permission checking at runtime on every action, not only at session start \u2014 exactly matching the requirement. GV-04 enforces policy as code in the request path for every action. PV-08 (Principal Intent vs. Agent Behavior Alignment) monitors ongoing alignment and can suspend on drift, complementing per-action re-evaluation. Direct coverage."
  },
  {
   "aisvs_id": "C9.6.1",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that a manual kill-switch mechanism exists to immediately halt AI model inference and outputs.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/RT-04",
    "apeiris://agentic/controls/AM-07",
    "apeiris://security/controls/GV-01"
   ],
   "primary_domains": [
    "security",
    "agentic"
   ],
   "notes": "RT-04 specifically covers the ability to 'pause or stop' the agent instantly on anomaly detection and references kill-switch capability. AM-07 provides automated and human-triggered agent suspension. GV-01 provides the human hard-stop mechanism. The 'manual' dimension is addressed by GV-01 and the human-triggered aspect of AM-07. Coverage is direct, though note C9.1.3 gap: a swarm-level variant of this kill-switch is a separate gap."
  },
  {
   "aisvs_id": "C9.6.2",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that when a human-approval gate is not satisfied within the defined approval time, the system blocks the pending action.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AO-04",
    "apeiris://authority/controls/PA-03"
   ],
   "primary_domains": [
    "agentic",
    "authority"
   ],
   "notes": "AO-04 establishes that approval checkpoints block pipeline execution until an authorized human reviewer explicitly approves \u2014 implying fail-closed behavior. PA-03 (Escalation Gate Design and Testing) explicitly includes 'failure-safe behavior' in its gate testing requirements, which directly covers the scenario where an approval gate times out or is not satisfied. Direct coverage for fail-closed behavior on approval timeout."
  },
  {
   "aisvs_id": "C9.6.3",
   "aisvs_chapter": "C09 \u2014 Orchestration & Agentic Security",
   "aisvs_text": "Verify that kill-switch commands are implemented through an out-of-band channel that is isolated from the agent runtime.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://authority/controls/PA-06",
    "apeiris://security/controls/RT-04"
   ],
   "primary_domains": [
    "authority",
    "security"
   ],
   "notes": "PA-06 (Emergency Override and Break-Glass) defines controlled emergency override procedures with multi-party authorization and immediate audit notification, which implies an out-of-band process. RT-04 covers kill-switch triggering. However, neither control explicitly mandates that kill-switch command delivery must use a channel that is architecturally isolated from the agent runtime (e.g., a separate management plane, out-of-band network segment, or hardware-level interrupt path). This is an L3 architectural isolation requirement that is a gap in the Apeiris control vocabulary."
  },
  {
   "aisvs_id": "C10.1.1",
   "aisvs_chapter": "C10 \u2014 Model Context Protocol (MCP) Security",
   "aisvs_text": "Verify that MCP components are obtained only from trusted sources and cryptographically verified.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AT-06",
    "apeiris://security/controls/PT-03"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AT-06 (Third-Party Plugin Vetting and Sandboxing) explicitly names MCP servers and requires formal security review before deployment. PT-03 (Verify skill/tool manifest integrity and sign the supply chain) requires cryptographic verification that every plug-in is genuine and unaltered before agent use. Together these directly satisfy the trusted-source and cryptographic-verification requirement."
  },
  {
   "aisvs_id": "C10.1.2",
   "aisvs_chapter": "C10 \u2014 Model Context Protocol (MCP) Security",
   "aisvs_text": "Verify that only allow-listed MCP servers are permitted.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/PT-02",
    "apeiris://agentic/controls/AT-01"
   ],
   "primary_domains": [
    "security",
    "agentic"
   ],
   "notes": "PT-02 (Authorize tool calls and govern the MCP server registry) explicitly governs the MCP server registry and requires approval before any tool may be called \u2014 a direct allow-list mechanism. AT-01 (Tool and Plugin Registry) requires an authoritative registry entry with approval status before any tool or plugin is available for use. Both controls together enforce the MCP server allow-list requirement."
  },
  {
   "aisvs_id": "C10.1.3",
   "aisvs_chapter": "C10 \u2014 Model Context Protocol (MCP) Security",
   "aisvs_text": "Verify that locally launched MCP servers run in a least-privilege sandbox with restricted file system, network, and system access.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/EC-01",
    "apeiris://security/controls/EC-04",
    "apeiris://agentic/controls/AT-06"
   ],
   "primary_domains": [
    "security",
    "agentic"
   ],
   "notes": "EC-01 (Run the agent in a sandbox) mandates process isolation through micro-VMs or equivalent. EC-04 (Limit filesystem and tool access to the bare minimum) requires least-privilege access to files and tools. AT-06 requires sandboxed runtime environments for third-party plugins and MCP servers that limit access to agent context and host infrastructure. The three controls together satisfy the sandboxing and least-privilege requirement for locally launched MCP servers."
  },
  {
   "aisvs_id": "C10.2.1",
   "aisvs_chapter": "C10 \u2014 Model Context Protocol (MCP) Security",
   "aisvs_text": "Verify that MCP servers validate access tokens for each request and do not rely on transport security alone.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://identity/controls/IF-06",
    "apeiris://security/controls/IA-04"
   ],
   "primary_domains": [
    "identity",
    "security"
   ],
   "notes": "IF-06 (Token Validation and Binding) requires cryptographic validation of identity tokens at every service an AI agent accesses. IA-04 (Check permission continuously at run time, not just once at login) mandates that permission checks occur on every action, not just at session start \u2014 directly prohibiting reliance on transport-layer session establishment as a substitute for per-request token validation."
  },
  {
   "aisvs_id": "C10.2.2",
   "aisvs_chapter": "C10 \u2014 Model Context Protocol (MCP) Security",
   "aisvs_text": "Verify that MCP servers validate the presented access token's issuer, audience, expiration, and scope claims in accordance with OAuth 2.1.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://identity/controls/IF-02",
    "apeiris://identity/controls/IF-06",
    "apeiris://identity/controls/NI-03"
   ],
   "primary_domains": [
    "identity"
   ],
   "notes": "IF-02 (OIDC/OAuth Federation Configuration) specifies scope definitions, token lifetime limits, and audience restrictions \u2014 covering the audience and scope claims. IF-06 covers cryptographic token validation at every service boundary. NI-03 (Credential Lifetime and Forced Rotation) enforces expiration. Coverage is partial because these controls reference OAuth 2.0/OIDC generally rather than OAuth 2.1 specifically, and issuer claim validation is implicit rather than explicitly named. No Apeiris control directly names OAuth 2.1 claim validation."
  },
  {
   "aisvs_id": "C10.2.3",
   "aisvs_chapter": "C10 \u2014 Model Context Protocol (MCP) Security",
   "aisvs_text": "Verify that MCP servers acting as OAuth 2.1 resource servers do not store or persist access tokens or user credentials.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://identity/controls/NI-07",
    "apeiris://security/controls/EC-08"
   ],
   "primary_domains": [
    "identity",
    "security"
   ],
   "notes": "NI-07 (Credential Storage and Secrets Hygiene) prohibits storage of AI agent credentials in unprotected locations including prompts, environment variables, code repositories, and logs, requiring approved secrets management. EC-08 (Keep secrets out of the prompt and context) reinforces this. Coverage is partial: the non-persistence requirement is covered at the storage hygiene level, but the MCP-specific framing of OAuth resource servers not retaining tokens passed to them from clients is not explicitly modeled."
  },
  {
   "aisvs_id": "C10.2.4",
   "aisvs_chapter": "C10 \u2014 Model Context Protocol (MCP) Security",
   "aisvs_text": "Verify that MCP tools/list returns only tools permitted by resource owners' authorized scopes.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/PT-02",
    "apeiris://agentic/controls/AT-02",
    "apeiris://agentic/controls/AB-01",
    "apeiris://identity/controls/DE-02"
   ],
   "primary_domains": [
    "security",
    "agentic",
    "identity"
   ],
   "notes": "PT-02 governs the MCP server registry and what tool calls are authorized. AT-02 (Tool Permission Scoping) mandates that each agent is granted access only to the specific tools it requires \u2014 denied by default. AB-01 (Authorized Action Scope Manifest) requires a machine-readable manifest of authorized actions, blocking execution of anything outside it. DE-02 (Scope Boundary Enforcement) ensures delegated scope never expands beyond the authorized set. Together these controls enforce scope-filtered tool visibility."
  },
  {
   "aisvs_id": "C10.2.5",
   "aisvs_chapter": "C10 \u2014 Model Context Protocol (MCP) Security",
   "aisvs_text": "Verify that MCP servers enforce access control on every tool invocation, validating that the user's access token authorizes both the requested tool and the specific argument values supplied.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-02",
    "apeiris://security/controls/IA-04",
    "apeiris://security/controls/PT-02"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AB-02 (Tool-Call Authorization Policy) requires an explicit authorization policy for each tool specifying which roles may call it, under what conditions, and with what parameter constraints \u2014 covering both tool-level and argument-level authorization. IA-04 mandates per-action permission checks at run time. PT-02 governs MCP server tool authorization at the registry level. This is the strongest coverage cluster for C10.2.x."
  },
  {
   "aisvs_id": "C10.2.6",
   "aisvs_chapter": "C10 \u2014 Model Context Protocol (MCP) Security",
   "aisvs_text": "Verify that MCP servers ensure all session artifacts are removed when a session terminates.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AA-05",
    "apeiris://security/controls/EC-03"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AA-05 (Session Token Binding and Anti-Replay Controls) covers session token lifecycle including preventing reuse outside intended scope. EC-03 (Keep memory short-lived, and validate anything written to it) requires short-lived agent memory. Coverage is partial: neither control explicitly names MCP session artifact cleanup at session termination as a required action. The intent is partially addressed through short-lived credential and memory controls but the termination-triggered cleanup is a gap."
  },
  {
   "aisvs_id": "C10.2.7",
   "aisvs_chapter": "C10 \u2014 Model Context Protocol (MCP) Security",
   "aisvs_text": "Verify that MCP servers do not pass through access tokens received from clients to downstream APIs.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AA-06",
    "apeiris://identity/controls/IF-06"
   ],
   "primary_domains": [
    "agentic",
    "identity"
   ],
   "notes": "AA-06 (Cross-System Authentication Chaining) requires that original agent identity be preserved across hops and that authorization scopes reduce never expand as calls propagate. IF-06 prohibits token forwarding without re-validation. Coverage is partial: these controls address the forwarding principle at the agent identity layer, but the MCP-specific concern of an MCP server acting as a proxy that silently forwards a client's bearer token to a downstream API without re-issuance is not explicitly named as a prohibited pattern."
  },
  {
   "aisvs_id": "C10.3.1",
   "aisvs_chapter": "C10 \u2014 Model Context Protocol (MCP) Security",
   "aisvs_text": "Verify that authenticated, encrypted streamable HTTP is used for MCP transport for remote services.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AA-03"
   ],
   "primary_domains": [
    "agentic"
   ],
   "notes": "AA-03 (mTLS and Certificate-Based Agent Authentication) requires mutual TLS for all service-to-service agent connections, which satisfies authenticated encrypted transport. Coverage is partial because the requirement specifically calls out 'streamable HTTP' (SSE/HTTP streaming as the MCP remote transport mode) and AA-03 is framed around general agent-to-service mTLS, not MCP-specific transport configuration. Basic HTTPS-only transport without mTLS is not separately named as a floor requirement."
  },
  {
   "aisvs_id": "C10.3.2",
   "aisvs_chapter": "C10 \u2014 Model Context Protocol (MCP) Security",
   "aisvs_text": "Verify that stdio transport is permitted only in controlled local environments.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://security/controls/EC-01",
    "apeiris://agentic/controls/AT-06"
   ],
   "primary_domains": [
    "security",
    "agentic"
   ],
   "notes": "EC-01 requires sandboxed runtime environments, and AT-06 requires sandboxed execution for locally launched MCP servers. These controls establish the conditions that would contain stdio-based MCP servers to controlled environments. Coverage is partial because no Apeiris control explicitly names stdio as a transport mode to be restricted, nor does any control state that stdio is only permitted in local environments as a named policy. This is a configuration governance gap for MCP-specific transport modes."
  },
  {
   "aisvs_id": "C10.3.3",
   "aisvs_chapter": "C10 \u2014 Model Context Protocol (MCP) Security",
   "aisvs_text": "Verify that MCP servers validate both the Origin header and the Host header independently on all HTTP-based transports to prevent DNS rebinding attacks.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/PT-02"
   ],
   "primary_domains": [],
   "notes": "No Apeiris control addresses Origin and Host HTTP header validation for DNS rebinding prevention. This is a web server security control specific to MCP's HTTP transport. Apeiris agentic and security controls address agent identity and tool authorization but do not reach into HTTP request header validation at the server implementation level. This is a gap. [closed 2026-07-08 via PT-02]"
  },
  {
   "aisvs_id": "C10.3.4",
   "aisvs_chapter": "C10 \u2014 Model Context Protocol (MCP) Security",
   "aisvs_text": "Verify that MCP clients enforce a minimum acceptable protocol version and reject initialize responses that propose a version below that minimum.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/PT-02"
   ],
   "primary_domains": [],
   "notes": "No Apeiris control addresses MCP protocol version negotiation or the enforcement of a minimum acceptable protocol version at client initialization. This is an MCP-protocol-specific downgrade attack prevention control. While AT-01 tracks tool versions in a registry, it does not cover MCP handshake version enforcement. This is a gap. [closed 2026-07-08 via PT-02]"
  },
  {
   "aisvs_id": "C10.3.5",
   "aisvs_chapter": "C10 \u2014 Model Context Protocol (MCP) Security",
   "aisvs_text": "Verify that access tokens between the MCP client and server are sender-constrained using mTLS or DPoP.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AA-03",
    "apeiris://identity/controls/IF-06"
   ],
   "primary_domains": [
    "agentic",
    "identity"
   ],
   "notes": "AA-03 (mTLS and Certificate-Based Agent Authentication) directly mandates mutual TLS for service-to-service agent connections \u2014 satisfying the mTLS sender-constraint mechanism. IF-06 (Token Validation and Binding) requires client-bound tokens to prevent replay and theft, which is the goal of sender-constrained tokens. Coverage is direct for the mTLS path. DPoP is not explicitly named as an alternative mechanism, which is a minor gap for implementations that prefer DPoP over mTLS."
  },
  {
   "aisvs_id": "C10.4.1",
   "aisvs_chapter": "C10 \u2014 Model Context Protocol (MCP) Security",
   "aisvs_text": "Verify that MCP tools/list and tools/call responses are validated against their declared schemas before being injected into the model context.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AT-03",
    "apeiris://agentic/controls/AT-04",
    "apeiris://security/controls/PT-04"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AT-03 (Tool Input Validation and Schema Enforcement) requires validation of all tool inputs against declared parameter schemas before execution. AT-04 (Tool Output Sanitization and Integrity Verification) requires that all tool outputs be verified against expected response schemas before being incorporated into the agent's context. PT-04 (Validate tool input/output, treat tool results as untrusted) reinforces this at the security domain level. Together these directly satisfy schema validation before context injection."
  },
  {
   "aisvs_id": "C10.4.2",
   "aisvs_chapter": "C10 \u2014 Model Context Protocol (MCP) Security",
   "aisvs_text": "Verify that MCP tools/list and tools/call responses are screened for indirect prompt injection before being injected into the model context.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-05",
    "apeiris://agentic/controls/AT-04",
    "apeiris://security/controls/RT-02",
    "apeiris://security/controls/PT-07",
    "apeiris://security/controls/PT-08"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AB-05 (Prompt Injection Detection and Defense) explicitly covers indirect injection via retrieved documents or tool outputs. AT-04 requires sanitization of tool outputs to remove injected content before context injection. RT-02 (Detect direct and indirect prompt injection at every input and output) provides runtime detection. PT-07 (Verify tool descriptions for hidden instructions) covers tool definition inspection. PT-08 enforces an instruction hierarchy preventing tool output from overriding agent instructions. This is one of the strongest coverage areas in C10."
  },
  {
   "aisvs_id": "C10.4.3",
   "aisvs_chapter": "C10 \u2014 Model Context Protocol (MCP) Security",
   "aisvs_text": "Verify that MCP servers reject unrecognized or oversized parameters in function calls.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AT-03",
    "apeiris://security/controls/PT-04",
    "apeiris://security/controls/PT-06"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AT-03 (Tool Input Validation and Schema Enforcement) explicitly requires rejection of malformed, out-of-range, or structurally invalid calls \u2014 covering unrecognized parameters. PT-06 (Sanitize model-generated tool parameters) covers semantic-level parameter sanitization. PT-04 treats tool results as untrusted and validates inputs. Coverage for 'oversized' parameters is direct via the malformed/out-of-range rejection clause in AT-03; explicit payload size limits are separately addressed in C10.4.5."
  },
  {
   "aisvs_id": "C10.4.4",
   "aisvs_chapter": "C10 \u2014 Model Context Protocol (MCP) Security",
   "aisvs_text": "Verify that all MCP servers enforce strict schema validation.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AT-03",
    "apeiris://security/controls/PT-04"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AT-03 (Tool Input Validation and Schema Enforcement) directly requires that all inputs passed to tools be validated against the tool's declared parameter schema before execution, which is the schema validation requirement for MCP servers. PT-04 reinforces this with the principle of treating tool results as untrusted and validating all I/O. These controls cover strict schema validation at the MCP tool boundary."
  },
  {
   "aisvs_id": "C10.4.5",
   "aisvs_chapter": "C10 \u2014 Model Context Protocol (MCP) Security",
   "aisvs_text": "Verify that all MCP transports enforce maximum payload size limits.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-06",
    "apeiris://security/controls/EC-05"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AB-06 (Rate Limiting and Resource Budget Enforcement) covers resource budget enforcement for agents. EC-05 (Cap spend and resource use, stop denial-of-wallet) covers resource consumption caps. Both controls establish the principle of resource bounding. Coverage is partial because no Apeiris control explicitly names maximum payload size limits as a required transport-layer control for MCP. The resource-bounding principle is present but the specific HTTP/SSE payload size enforcement requirement is not named."
  },
  {
   "aisvs_id": "C10.4.6",
   "aisvs_chapter": "C10 \u2014 Model Context Protocol (MCP) Security",
   "aisvs_text": "Verify that MCP servers sign tool responses with a unique nonce and timestamp so MCP clients can detect replay attempts.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AA-05",
    "apeiris://agentic/controls/AO-03"
   ],
   "primary_domains": [
    "agentic"
   ],
   "notes": "AA-05 (Session Token Binding and Anti-Replay Controls) requires unique nonces on every token issuance and nonce freshness validation on every use to prevent replay attacks \u2014 directly addressing the anti-replay objective. AO-03 (Orchestration Message Integrity) requires cryptographic integrity protection on all inter-agent messages including timestamps. Coverage is partial because the specific mechanism (MCP servers signing each tool response envelope with nonce+timestamp) is not explicitly named as a control; Apeiris addresses the anti-replay and message integrity goals through session token and orchestration message controls rather than per-tool-response signing."
  },
  {
   "aisvs_id": "C10.4.7",
   "aisvs_chapter": "C10 \u2014 Model Context Protocol (MCP) Security",
   "aisvs_text": "Verify that MCP clients present users with explicit consent dialogue and cancellation options upon installation of a local MCP server.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://identity/controls/DE-05",
    "apeiris://agentic/controls/AO-04"
   ],
   "primary_domains": [
    "identity",
    "agentic"
   ],
   "notes": "DE-05 (User Consent for Delegated AI Action) requires explicit, informed, action-specific consent from the human principal before any consequential AI agent action is executed, with records retained and auditable. AO-04 (Human-in-the-Loop Gates for High-Consequence Orchestrations) establishes human approval gates for high-consequence actions. Coverage is partial: the consent policy and gate are well covered, but the UX-level requirement of a specific installation-time consent dialog with a cancellation affordance for MCP server installation is not addressed \u2014 Apeiris operates at the governance and policy layer, not the client UI implementation layer."
  },
  {
   "aisvs_id": "C10.4.8",
   "aisvs_chapter": "C10 \u2014 Model Context Protocol (MCP) Security",
   "aisvs_text": "Verify that MCP clients maintain a snapshot of tool definitions and that any change to a tool definition triggers re-approval before the modified tool can be invoked.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://security/controls/PT-03",
    "apeiris://security/controls/PT-07",
    "apeiris://agentic/controls/AT-01"
   ],
   "primary_domains": [
    "security",
    "agentic"
   ],
   "notes": "PT-03 (Verify skill/tool manifest integrity and sign the supply chain) requires cryptographic verification that every plug-in is genuine and unaltered \u2014 establishing integrity detection for tool definition changes. PT-07 (Verify tool descriptions for hidden instructions) requires inspection of tool descriptions before trust is extended. AT-01 tracks tool versions and approval status in a registry. Coverage is partial: while integrity detection and registry-based approval exist as controls, the explicit workflow of maintaining a local snapshot and automatically triggering a re-approval gate whenever any tool definition changes is not named as a discrete control step. The building blocks are present; the trigger-on-change gate is the gap."
  },
  {
   "aisvs_id": "C11.1.1",
   "aisvs_chapter": "C11 \u2014 Adversarial Robustness",
   "aisvs_text": "Verify that the model has undergone alignment and safety training or fine-tuning to prevent the model from generating disallowed content categories.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/EV-02",
    "apeiris://model/controls/EV-04",
    "apeiris://model/controls/BH-10"
   ],
   "primary_domains": [
    "model"
   ],
   "notes": "EV-02 requires pre-deployment safety and policy-conformance evaluation including alignment eval for GenAI profiles. EV-04 mandates adversarial red-teaming that probes for harmful content elicitation. BH-10 governs RLHF and feedback loops that implement alignment. Apeiris verifies safety outcomes and governs the alignment feedback process, but has no control that explicitly mandates that alignment or safety fine-tuning was performed as a training-time step \u2014 the training process itself is outside Apeiris scope."
  },
  {
   "aisvs_id": "C11.1.2",
   "aisvs_chapter": "C11 \u2014 Adversarial Robustness",
   "aisvs_text": "Verify that a version-controlled alignment test suite is run on every model update or release.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://model/controls/EV-07",
    "apeiris://security/controls/AS-03"
   ],
   "primary_domains": [
    "model",
    "security"
   ],
   "notes": "EV-07 explicitly requires that every fine-tune, RLHF update, guardrail change, or model update triggers a regression evaluation run against a versioned baseline, and that safety regression blocks promotion unless explicitly accepted. AS-03 adds release gating on continuous adversarial validation. Together these provide direct coverage."
  },
  {
   "aisvs_id": "C11.1.3",
   "aisvs_chapter": "C11 \u2014 Adversarial Robustness",
   "aisvs_text": "Verify that models are evaluated against known adversarial attack techniques relevant to their modality.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://model/controls/EV-04",
    "apeiris://security/controls/AS-01",
    "apeiris://model/controls/BH-06"
   ],
   "primary_domains": [
    "model",
    "security"
   ],
   "notes": "EV-04 mandates structured adversarial probing before deployment, explicitly naming prompt injection, jailbreaks, harmful content elicitation, and misuse patterns. AS-01 requires adversarial red-teaming before launch with coverage of goal hijack and multi-turn drift. BH-06 measures injection-resistance in production using a structured probe suite. Modality scoping is EV-04's responsibility via profile applicability (generative-AI, frontier, hosted-API)."
  },
  {
   "aisvs_id": "C11.1.4",
   "aisvs_chapter": "C11 \u2014 Adversarial Robustness",
   "aisvs_text": "Verify that models are hardened against adversarial inputs.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://security/controls/RT-02",
    "apeiris://agentic/controls/AB-05",
    "apeiris://model/controls/BH-06"
   ],
   "primary_domains": [
    "security",
    "agentic",
    "model"
   ],
   "notes": "Apeiris covers detection of adversarial inputs (RT-02, AB-05) and continuous evaluation of injection resistance (BH-06). No Apeiris control mandates specific hardening techniques such as adversarial training, certified defenses, or input preprocessing/smoothing at the model weight level. Hardening verification is covered; mandated hardening methods are not \u2014 consistent with Apeiris being an evidence and assurance layer rather than a training infrastructure specification."
  },
  {
   "aisvs_id": "C11.1.5",
   "aisvs_chapter": "C11 \u2014 Adversarial Robustness",
   "aisvs_text": "Verify that an automated evaluator measures harmful-content rate and flags regressions beyond a defined threshold.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/BH-01",
    "apeiris://model/controls/EV-07"
   ],
   "primary_domains": [
    "model"
   ],
   "notes": "BH-01 requires continuous statistical monitoring of model output distributions with alerting on deviations from baseline. EV-07 requires that safety regression on updates blocks promotion unless explicitly accepted. Neither control specifically names a harmful-content rate metric or requires a dedicated harmful-content evaluator with defined threshold regression alerting \u2014 BH-01 is modality-agnostic output anomaly detection. A gap exists for the explicit automated harmful-content measurement pipeline."
  },
  {
   "aisvs_id": "C11.2.1",
   "aisvs_chapter": "C11 \u2014 Adversarial Robustness",
   "aisvs_text": "Verify that model-inferred sensitive attributes are not directly returned in outputs.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://privacy/controls/DP-04",
    "apeiris://privacy/controls/DP-05",
    "apeiris://security/controls/RT-05"
   ],
   "primary_domains": [
    "privacy",
    "security"
   ],
   "notes": "DP-04 governs the scope of inferences an AI system may draw, requiring inferred sensitive attributes to be classified and governed as personal data. DP-05 requires output PII scrubbing with audit logging. RT-05 applies DLP to all agent egress. Coverage is partial because DP-05 targets verbatim or near-verbatim PII reproduction (memorization), while this requirement targets inferred sensitive attributes \u2014 a distinct and broader category that DP-04 governs at the data-classification level but does not explicitly enforce at output time."
  },
  {
   "aisvs_id": "C11.2.2",
   "aisvs_chapter": "C11 \u2014 Adversarial Robustness",
   "aisvs_text": "Verify that inference endpoints enforce per-principal and global rate limits sized to the extraction threat model, and not solely as a generic API throttle.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-06"
   ],
   "primary_domains": [
    "agentic"
   ],
   "notes": "AB-06 mandates per-agent rate limits on API call rates and compute time, enforced by the platform with circuit-breaker behavior. Coverage is partial because AB-06 is framed around resource budget and denial-of-wallet prevention, not around sizing rate limits to a model extraction threat model. The AISVS requirement is specifically about configuring limits relative to the statistical query volume needed to mount an extraction attack \u2014 this adversarial sizing rationale is absent from Apeiris controls."
  },
  {
   "aisvs_id": "C11.2.3",
   "aisvs_chapter": "C11 \u2014 Adversarial Robustness",
   "aisvs_text": "Verify that model outputs are calibrated to reduce overconfident predictions.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/BH-01"
   ],
   "primary_domains": [],
   "notes": "Output calibration (e.g., temperature scaling, Platt scaling, isotonic regression on confidence scores) is an ML training and post-processing concern. EV-02 covers reliability evaluation but does not specify or mandate calibration techniques. No Apeiris control addresses overconfidence reduction as a defense against model stealing or membership inference. This is a gap \u2014 calibration is partially an ML engineering requirement outside Apeiris's current assurance scope. [closed 2026-07-08 via BH-01]"
  },
  {
   "aisvs_id": "C11.2.4",
   "aisvs_chapter": "C11 \u2014 Adversarial Robustness",
   "aisvs_text": "Verify that training on sensitive datasets employs differentially-private optimization.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/TG-06"
   ],
   "primary_domains": [
    "model"
   ],
   "notes": "TG-06 requires de-identification, anonymization, or synthetic replacement for sensitive training data, with tightly governed access controls. This addresses privacy protection in training but does not mandate differentially private optimization (DP-SGD or equivalent) as a formal mathematical guarantee. The distinction matters: TG-06 covers data minimization approaches; DP optimization provides quantifiable privacy bounds that resist membership inference and reconstruction attacks. A gap exists for the DP-specific requirement."
  },
  {
   "aisvs_id": "C11.2.5",
   "aisvs_chapter": "C11 \u2014 Adversarial Robustness",
   "aisvs_text": "Verify that membership-inference attack simulations demonstrate that attack accuracy does not exceed random guessing on evaluated data.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://model/controls/EV-12"
   ],
   "primary_domains": [],
   "notes": "No Apeiris control explicitly requires membership inference attack simulation or defines acceptable accuracy thresholds. EV-04 (adversarial red-teaming) could theoretically include MI attacks but does not scope them. PM-05 in Privacy monitors inference logs for unusual patterns suggesting membership inference but does not mandate proactive simulation testing with quantitative pass/fail criteria. This is a genuine gap \u2014 membership inference testing with defined accuracy thresholds is not represented in the Apeiris control set. [closed 2026-07-08 via EV-12]"
  },
  {
   "aisvs_id": "C11.3.1",
   "aisvs_chapter": "C11 \u2014 Adversarial Robustness",
   "aisvs_text": "Verify that query-pattern analysis feeds an extraction-attempt detector.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AM-01",
    "apeiris://agentic/controls/AM-02",
    "apeiris://security/controls/RT-04",
    "apeiris://privacy/controls/PM-05"
   ],
   "primary_domains": [
    "agentic",
    "security",
    "privacy"
   ],
   "notes": "AM-01 establishes behavioral telemetry baseline including action logs and session data. AM-02 detects anomalous actions in real time. RT-04 triggers containment on anomalies. PM-05 explicitly monitors inference logs for 'unusual query patterns suggesting membership inference or data extraction.' PM-05 is the closest match but is scoped to privacy/PII concerns rather than model IP theft. No control specifically requires query-pattern analysis tuned to the statistical signatures of model extraction attacks (systematic boundary probing, high-confidence-seeking queries, etc.)."
  },
  {
   "aisvs_id": "C11.3.2",
   "aisvs_chapter": "C11 \u2014 Adversarial Robustness",
   "aisvs_text": "Verify that raw model outputs are not directly exposed beyond the application backend, and that externally visible responses are calibrated to the extraction risk level.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://security/controls/RT-05"
   ],
   "primary_domains": [
    "security"
   ],
   "notes": "RT-05 applies DLP to agent egress and catches sensitive data on its way out. Coverage is partial because RT-05 addresses data loss prevention, not model IP protection. The AISVS requirement is specifically about restricting raw logit distributions, token probabilities, or full model outputs from being exposed externally as a defense against model stealing via output reconstruction. No Apeiris control mandates output abstraction or probability masking at the inference API boundary."
  },
  {
   "aisvs_id": "C11.3.3",
   "aisvs_chapter": "C11 \u2014 Adversarial Robustness",
   "aisvs_text": "Verify that model watermarking or fingerprinting techniques are applied so that unauthorized copies can be identified.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/LI-01",
    "apeiris://model/controls/BH-09"
   ],
   "primary_domains": [
    "model"
   ],
   "notes": "LI-01 provides content-addressed version hashing for model artifacts in the registry (artifact-level fingerprinting). BH-09 embeds cryptographic provenance metadata in AI-generated content (output watermarking for traceability). Neither addresses watermarking model weights or embedding statistical signatures that would survive distillation and allow detecting unauthorized stolen or distilled model copies \u2014 which is the primary intent of this AISVS control. This is a meaningful gap for model IP protection."
  },
  {
   "aisvs_id": "C11.3.4",
   "aisvs_chapter": "C11 \u2014 Adversarial Robustness",
   "aisvs_text": "Verify that detection of suspected extraction triggers response measures.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://security/controls/RT-04",
    "apeiris://agentic/controls/AM-07"
   ],
   "primary_domains": [
    "security",
    "agentic"
   ],
   "notes": "RT-04 links anomaly detection to pause, kill switch, or containment actions. AM-07 provides automated agent suspension for critical violations with state preservation for forensics. These controls provide the detection-to-response chain for general behavioral anomalies. Coverage is partial because neither control is specifically scoped to model extraction detection as the trigger, and no extraction-specific response playbook (e.g., IP throttling, session termination, adversary attribution logging) is defined in Apeiris controls."
  },
  {
   "aisvs_id": "C11.4.1",
   "aisvs_chapter": "C11 \u2014 Adversarial Robustness",
   "aisvs_text": "Verify that inputs from external or untrusted sources pass through anomaly detection before model inference.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/EC-07",
    "apeiris://agentic/controls/AB-05",
    "apeiris://agentic/controls/AT-03"
   ],
   "primary_domains": [
    "security",
    "agentic"
   ],
   "notes": "EC-07 explicitly requires trust-ranking of retrieved documents and web pages before they enter agent context. AB-05 mandates prompt injection detection for direct and indirect inputs including retrieved documents and tool outputs. AT-03 requires schema validation of all tool inputs before execution. Together these provide direct and comprehensive coverage of pre-inference anomaly detection on external inputs."
  },
  {
   "aisvs_id": "C11.4.2",
   "aisvs_chapter": "C11 \u2014 Adversarial Robustness",
   "aisvs_text": "Verify that inputs flagged as anomalous trigger gating actions.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/RT-04",
    "apeiris://agentic/controls/AM-07",
    "apeiris://agentic/controls/AB-05"
   ],
   "primary_domains": [
    "security",
    "agentic"
   ],
   "notes": "RT-04 explicitly connects anomaly detection to gating actions \u2014 pause, kill switch, or containment \u2014 and mandates immediate response capability. AM-07 provides automated agent suspension for critical violations without requiring human intervention, with reversible state preservation. AB-05 includes mitigation controls (not just detection) in its scope. These controls collectively satisfy the detect-then-gate pattern this requirement specifies."
  },
  {
   "aisvs_id": "C11.4.3",
   "aisvs_chapter": "C11 \u2014 Adversarial Robustness",
   "aisvs_text": "Verify that the safety violation feedback pipeline includes poisoning detection and human review gates to prevent adversarial manipulation of the improvement mechanism.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://model/controls/BH-10"
   ],
   "primary_domains": [
    "model"
   ],
   "notes": "BH-10 directly requires feedback poisoning detection, labeler quality controls, reward hacking prevention, online learning authorization gates, and self-reinforcing error monitoring across all feedback loops that influence model behavior post-deployment. This maps directly to every element of the AISVS requirement: poisoning detection, human review gates, and protection of the improvement mechanism against adversarial manipulation."
  },
  {
   "aisvs_id": "C12.1.1",
   "aisvs_chapter": "C12 \u2014 Monitoring, Logging & Anomaly Detection",
   "aisvs_text": "Verify that AI interactions are logged with session context and AI-specific telemetry.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://agentic/controls/AM-01",
    "apeiris://model/controls/BH-05",
    "apeiris://security/controls/RT-01"
   ],
   "primary_domains": [
    "agentic",
    "model",
    "security"
   ],
   "notes": "AM-01 (Behavioral Telemetry Collection Baseline) mandates action logs, tool invocations, token consumption, decision rationale traces, and session boundaries as a mandatory baseline for every production agent. BH-05 (Usage Telemetry and Decision Logging) requires logging every model inference with caller identity, masked inputs, sampled outputs, and latency. RT-01 adds OS-level telemetry. Together these provide direct, multi-layer coverage of session context and AI-specific telemetry."
  },
  {
   "aisvs_id": "C12.1.2",
   "aisvs_chapter": "C12 \u2014 Monitoring, Logging & Anomaly Detection",
   "aisvs_text": "Verify that safety filtering and policy decisions are logged with sufficient detail to support audit, debugging, and forensic analysis of content moderation systems.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AM-01",
    "apeiris://model/controls/BH-05",
    "apeiris://security/controls/GV-02",
    "apeiris://compliance/controls/AU-04"
   ],
   "primary_domains": [
    "agentic",
    "model",
    "security",
    "compliance"
   ],
   "notes": "AM-01 captures decision rationale traces and GV-02 mandates an immutable audit trail of actions and decisions. BH-05 logs model inference with inputs and outputs. AU-04 ensures audit trail integrity. However, no Apeiris control explicitly addresses safety-filter policy decisions and content moderation systems as a distinct logging category with forensic-depth requirements. Coverage is partial: the logging infrastructure is in scope but content moderation specifics are not explicitly called out."
  },
  {
   "aisvs_id": "C12.1.3",
   "aisvs_chapter": "C12 \u2014 Monitoring, Logging & Anomaly Detection",
   "aisvs_text": "Verify that log entries for AI inference events follow a structured, interoperable schema that includes at least the model identifier, token usage (input and output), provider name, and operation type.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/BH-05",
    "apeiris://agentic/controls/AM-01"
   ],
   "primary_domains": [
    "model",
    "agentic"
   ],
   "notes": "BH-05 requires logging model inference with caller identity, inputs, outputs, and latency. AM-01 includes token consumption. These controls capture the substance of the required fields (model identity is logged as caller identity; token counts appear in AM-01). However, neither control explicitly mandates a structured, interoperable schema with a defined minimum field set including provider name and operation type. The schema-interoperability requirement is a gap \u2014 Apeiris covers what to log but not the required log format specification."
  },
  {
   "aisvs_id": "C12.1.4",
   "aisvs_chapter": "C12 \u2014 Monitoring, Logging & Anomaly Detection",
   "aisvs_text": "Verify that RAG pipeline retrieval events are logged, including the query, documents retrieved, and knowledge source.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://knowledge/controls/KR-07",
    "apeiris://knowledge/controls/KM-05"
   ],
   "primary_domains": [
    "knowledge"
   ],
   "notes": "KR-07 (Retrieval Audit Trail) directly requires logging every retrieval operation with sufficient detail to reconstruct the query, which chunks were returned, relevance scores, and authorization checks applied \u2014 creating an immutable audit trail. KM-05 (Knowledge-to-Output Lineage Tracking) traces every AI output back to the specific knowledge chunks and retrieval queries that informed it. Together these provide direct coverage."
  },
  {
   "aisvs_id": "C12.2.1",
   "aisvs_chapter": "C12 \u2014 Monitoring, Logging & Anomaly Detection",
   "aisvs_text": "Verify that the system detects and alerts on known jailbreak patterns, prompt injection attempts, and adversarial inputs.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/RT-02",
    "apeiris://agentic/controls/AB-05",
    "apeiris://model/controls/BH-06"
   ],
   "primary_domains": [
    "security",
    "agentic",
    "model"
   ],
   "notes": "RT-02 (Detect direct and indirect prompt injection at every input and output) and AB-05 (Prompt Injection Detection and Defense) directly address detection and alerting on prompt injection and jailbreak attempts. BH-06 (Injection-Resistance Evaluation in Production) continuously measures resistance to adversarial inputs using structured probe suites. Three controls across two domains provide direct coverage."
  },
  {
   "aisvs_id": "C12.2.2",
   "aisvs_chapter": "C12 \u2014 Monitoring, Logging & Anomaly Detection",
   "aisvs_text": "Verify that behavioral anomaly detection identifies unusual conversation patterns, excessive retry attempts, or probing behaviors.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AM-02",
    "apeiris://agentic/controls/AB-07",
    "apeiris://security/controls/RT-04"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AM-02 (Anomalous Action Detection) and RT-04 (Detect anomalies and trigger pause, kill switch, or containment) cover behavioral anomaly detection and alerting broadly. AB-07 (Behavioral Drift Monitoring) adds monitoring for behavioral changes over time. Coverage is partial because these controls operate at the action and agent level; conversation-level signals such as unusual turn patterns, excessive retries, and session-scoped probing behavior are not explicitly specified as detection targets."
  },
  {
   "aisvs_id": "C12.2.3",
   "aisvs_chapter": "C12 \u2014 Monitoring, Logging & Anomaly Detection",
   "aisvs_text": "Verify that custom rules detect AI-specific threat patterns for coordinated jailbreak attempts, prompt injection, and system prompt extraction attempts.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://security/controls/RT-06",
    "apeiris://agentic/controls/AB-05",
    "apeiris://security/controls/RT-02"
   ],
   "primary_domains": [
    "security",
    "agentic"
   ],
   "notes": "RT-06 (Map AI-native threats, extend ATT&CK/ATLAS to agentic orchestration) establishes the threat taxonomy that would drive custom rule creation. AB-05 and RT-02 cover prompt injection detection. However, no Apeiris control explicitly requires a custom-rule engine or rule authoring capability for AI-specific threat patterns. System prompt extraction detection is not explicitly named as a distinct detection target in any control. Coverage is partial \u2014 the threat domain is addressed but the custom rules mechanism is implicit."
  },
  {
   "aisvs_id": "C12.2.4",
   "aisvs_chapter": "C12 \u2014 Monitoring, Logging & Anomaly Detection",
   "aisvs_text": "Verify that extraction-alert events include offending query metadata to support investigation.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AM-01",
    "apeiris://security/controls/RT-02",
    "apeiris://agentic/controls/AM-06"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AM-01 requires comprehensive telemetry and AM-06 (Monitoring Log Integrity) ensures logs are tamper-evident. RT-02 triggers on prompt injection detection events. However, no Apeiris control explicitly states that alert events \u2014 particularly extraction attempts \u2014 must include the offending query metadata as a mandatory field in the alert payload. The forensic metadata requirement for alert events is implicit at best; this is a gap in explicit specification."
  },
  {
   "aisvs_id": "C12.2.5",
   "aisvs_chapter": "C12 \u2014 Monitoring, Logging & Anomaly Detection",
   "aisvs_text": "Verify that token usage is tracked at granular attribution levels including per user, per session, per feature endpoint, and per team or workspace.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/BH-07",
    "apeiris://agentic/controls/AM-04",
    "apeiris://agentic/controls/AM-01"
   ],
   "primary_domains": [
    "model",
    "agentic"
   ],
   "notes": "BH-07 (Resource and Cost Anomaly Monitoring) monitors token consumption and API call volume in real time. AM-04 (Resource Consumption Anomaly Monitoring) and AM-01 include token consumption in the telemetry baseline. However, granular attribution across per-user, per-session, per-feature-endpoint, and per-team dimensions is not explicitly specified as a requirement in any Apeiris control. The monitoring capability is present; the attribution granularity specification is a gap."
  },
  {
   "aisvs_id": "C12.2.6",
   "aisvs_chapter": "C12 \u2014 Monitoring, Logging & Anomaly Detection",
   "aisvs_text": "Verify that LLM API traffic is monitored for covert-channel indicators and communication signatures to identify malware and command-and-control (C2) activity.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/RT-07",
    "apeiris://agentic/controls/AM-05"
   ],
   "primary_domains": [
    "security",
    "agentic"
   ],
   "notes": "RT-07 (Detect multi-agent collusion and covert channels) explicitly addresses monitoring for covert channels and communication signatures that appear harmless in isolation. AM-05 (Multi-Agent Communication Monitoring) covers monitoring of agent-to-agent communications. Together these directly cover detection of C2 and covert channel activity embedded in LLM API traffic \u2014 a sophisticated L3 requirement that Apeiris addresses directly."
  },
  {
   "aisvs_id": "C12.3.1",
   "aisvs_chapter": "C12 \u2014 Monitoring, Logging & Anomaly Detection",
   "aisvs_text": "Verify that data drift detection monitors input distribution changes that may impact model performance, using statistically validated methods matched to the input data type (e.g., KS test or PSI for tabular numeric features, embedding-distance metrics for text or image).",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://model/controls/BH-02"
   ],
   "primary_domains": [
    "model"
   ],
   "notes": "BH-02 (Concept and Data Drift Detection) directly addresses detecting when production data diverges from the training distribution with statistically validated methods, stricter thresholds for continuously trained models, and triggering review or retraining before performance silently degrades. The control's plain text explicitly covers statistical process approaches. This is a strong direct mapping."
  },
  {
   "aisvs_id": "C12.3.2",
   "aisvs_chapter": "C12 \u2014 Monitoring, Logging & Anomaly Detection",
   "aisvs_text": "Verify that hallucination detection monitors identify and flag model outputs that contain factually incorrect, inconsistent, or fabricated information.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://knowledge/controls/KR-04",
    "apeiris://model/controls/BH-01"
   ],
   "primary_domains": [
    "knowledge",
    "model"
   ],
   "notes": "KR-04 (Retrieval Hallucination Detection) directly addresses detecting and flagging outputs that contradict, misrepresent, or generate claims beyond retrieved context \u2014 but specifically in the RAG context. BH-01 (Output Anomaly Detection) monitors output distributions statistically. Together they are partial: hallucination detection for non-RAG, generative-only deployments lacks an explicit Apeiris control. The coverage is strong for RAG systems, weaker for pure generative inference."
  },
  {
   "aisvs_id": "C12.3.3",
   "aisvs_chapter": "C12 \u2014 Monitoring, Logging & Anomaly Detection",
   "aisvs_text": "Verify that hallucination rates are tracked as continuous time-series metrics to enable trend analysis and detection of sustained model degradation.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://model/controls/CR-01",
    "apeiris://model/controls/BH-03"
   ],
   "primary_domains": [
    "model"
   ],
   "notes": "CR-01 (Continuous Production Monitoring and Risk Aggregation) aggregates all runtime signals into a unified risk dashboard with automated alerting for degradation, which aligns with the time-series trend analysis requirement. BH-03 (Production Performance Degradation Alerting) tracks live metrics against signed baselines with tiered alerts. However, neither control explicitly names hallucination rate as a tracked metric. The time-series monitoring infrastructure is present; the hallucination-specific metric requirement is implicit."
  },
  {
   "aisvs_id": "C12.3.4",
   "aisvs_chapter": "C12 \u2014 Monitoring, Logging & Anomaly Detection",
   "aisvs_text": "Verify that unexplained behavioral shifts are distinguished from gradual, expected operational drift.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AB-07",
    "apeiris://agentic/controls/AM-03",
    "apeiris://model/controls/BH-02"
   ],
   "primary_domains": [
    "agentic",
    "model"
   ],
   "notes": "AB-07 (Behavioral Drift Monitoring) and AM-03 (Goal Drift and Intent Deviation Detection) address detecting behavioral changes in agentic systems. BH-02 covers concept and data drift at the model level. However, the specific requirement to formally distinguish unexplained behavioral shifts from expected operational drift \u2014 which implies baseline characterization, attribution logic, and classification \u2014 is not explicitly specified in any Apeiris control. This is an L3 gap in analytic classification depth."
  },
  {
   "aisvs_id": "C12.4.1",
   "aisvs_chapter": "C12 \u2014 Monitoring, Logging & Anomaly Detection",
   "aisvs_text": "Verify that autonomous action triggers include proactive behavior-pattern analysis, security evaluation, and threat-landscape assessment.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://agentic/controls/AM-02",
    "apeiris://agentic/controls/AM-03",
    "apeiris://security/controls/RT-06"
   ],
   "primary_domains": [
    "agentic",
    "security"
   ],
   "notes": "AM-02 covers anomalous action detection and AM-03 covers goal/intent deviation that can trigger responses. RT-06 maps AI-native threats and the threat landscape. However, no Apeiris control explicitly specifies that autonomous action trigger logic must incorporate proactive behavior-pattern analysis, a security evaluation step, and a threat-landscape assessment as formal preconditions. The constituent capabilities exist but their composition as trigger prerequisites is not specified."
  },
  {
   "aisvs_id": "C12.4.2",
   "aisvs_chapter": "C12 \u2014 Monitoring, Logging & Anomaly Detection",
   "aisvs_text": "Verify that audit logs capture security-critical proactive actions, including approver identity, timestamp, action parameters, and decision outcomes.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://security/controls/GV-02",
    "apeiris://agentic/controls/AO-07",
    "apeiris://agentic/controls/AT-07",
    "apeiris://compliance/controls/AU-04"
   ],
   "primary_domains": [
    "security",
    "agentic",
    "compliance"
   ],
   "notes": "GV-02 mandates an immutable, tamper-evident audit trail of every tool call, change, and decision including actor identity. AO-07 (Orchestration Audit Trail) and AT-07 (Tool Usage Audit Trail) capture orchestration and tool events with timestamps and actor attribution. AU-04 enforces audit trail integrity with cryptographic verification. Together these controls directly address the requirement to log approver identity, timestamp, action parameters, and decision outcomes for security-critical proactive actions."
  },
  {
   "aisvs_id": "C12.4.3",
   "aisvs_chapter": "C12 \u2014 Monitoring, Logging & Anomaly Detection",
   "aisvs_text": "Verify that kill-switch activations and override commands are logged.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://security/controls/GV-02",
    "apeiris://agentic/controls/AM-07",
    "apeiris://security/controls/RT-04"
   ],
   "primary_domains": [
    "security",
    "agentic"
   ],
   "notes": "RT-04 requires the ability to trigger pause, kill switch, or containment on anomaly detection. AM-07 (Real-Time Alerting and Automated Agent Suspension) covers the suspension mechanism. GV-02 mandates an immutable audit trail of all agent decisions and actions. However, no Apeiris control explicitly states that kill-switch activations and manual override commands must be logged as a distinct, required audit event category. This is a narrow but real gap in explicit specification."
  },
  {
   "aisvs_id": "C12.5.1",
   "aisvs_chapter": "C12 \u2014 Monitoring, Logging & Anomaly Detection",
   "aisvs_text": "Verify that dataset lineage records each dataset and its components, including all transformations, augmentations, and merges.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://data/controls/DL-01",
    "apeiris://data/controls/DL-04",
    "apeiris://data/controls/DL-02"
   ],
   "primary_domains": [
    "data"
   ],
   "notes": "DL-01 (End-to-End Data Lineage Tracking) requires a complete, machine-readable lineage graph tracing origin through all transformations, enrichments, and pipelines. DL-04 (Transformation and Enrichment Lineage) specifically requires documenting every transformation, normalization, enrichment, join, aggregation, and derivation. DL-02 (Training Data Lineage Documentation) covers collection date, collection method, consent basis, and transformation history for AI training datasets. This is a strong direct mapping."
  },
  {
   "aisvs_id": "C12.5.2",
   "aisvs_chapter": "C12 \u2014 Monitoring, Logging & Anomaly Detection",
   "aisvs_text": "Verify that all labeling activities are recorded in logs.",
   "coverage": "partial",
   "apeiris_controls": [
    "apeiris://data/controls/DL-02",
    "apeiris://data/controls/DL-04"
   ],
   "primary_domains": [
    "data"
   ],
   "notes": "DL-02 covers training data lineage including transformation history, and DL-04 covers enrichment and derivation steps. Labeling is a form of annotation/transformation that falls within these controls' scope. However, no Apeiris control explicitly names labeling activities \u2014 label assignment, annotator identity, inter-annotator agreement runs, label revision history \u2014 as a distinct audit log requirement. This is a genuine gap, particularly for RLHF and supervised fine-tuning workflows where labeler quality and label provenance are critical."
  },
  {
   "aisvs_id": "C12.5.3",
   "aisvs_chapter": "C12 \u2014 Monitoring, Logging & Anomaly Detection",
   "aisvs_text": "Verify that all model changes generate immutable audit records.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://model/controls/LI-06",
    "apeiris://model/controls/CR-02",
    "apeiris://compliance/controls/AU-04"
   ],
   "primary_domains": [
    "model",
    "compliance"
   ],
   "notes": "LI-06 (Immutable Version Control) explicitly states that no deployed model can be silently overwritten and every version change is recorded. CR-02 (Model Evidence Archive and Audit Trail) maintains an immutable, content-addressed archive of all evaluation results, monitoring snapshots, and incident records. AU-04 ensures cryptographic integrity of audit trails. Together these provide direct and strong coverage of the immutable audit record requirement for model changes."
  },
  {
   "aisvs_id": "C12.5.4",
   "aisvs_chapter": "C12 \u2014 Monitoring, Logging & Anomaly Detection",
   "aisvs_text": "Verify that every ingested document is tagged at write time with source, writer identity, and timestamp.",
   "coverage": "direct",
   "apeiris_controls": [
    "apeiris://knowledge/controls/KI-07",
    "apeiris://data/controls/DL-03"
   ],
   "primary_domains": [
    "knowledge",
    "data"
   ],
   "notes": "KI-07 (Ingestion Audit Trail) directly requires a complete, tamper-evident log of all knowledge base additions recording actor identity, source, timestamp, and content hash for every change. DL-03 (Inference-Time Data Lineage) adds per-decision provenance for records consumed at inference time. KI-07 alone provides direct coverage of the write-time tagging requirement for ingested documents."
  }
 ],
 "meta": {
  "generated_at": "2026-06-29T00:00:00.000Z",
  "endpoint": "https://apeiris.ai/integration/aisvs_coverage_matrix.json",
  "description": "Maps every OWASP AISVS 1.0 requirement to Apeiris control URIs with coverage classification"
 }
}