HAIAMM v3.0, Infrastructure Domain Handbook

AI/HAI Infrastructure Assurance, security of the infrastructure that hosts and serves the AI/HAI systems the organization operates

Version: 3.0 Domain: Infrastructure Audience: Security, Platform / SRE, Cloud Architecture, MLOps / ML Platform, AI/ML Engineering, Privacy/Legal, FinOps Use: Conduct a maturity assessment of the AI/HAI Infrastructure Assurance program, and build the practices that move it from Foundational to Industry-Leading.

Preface

This handbook is a self-contained, practitioner-facing document. Read it end to end to understand the Infrastructure domain of HAIAMM, or jump to Part IV to perform an assessment.

The handbook makes three commitments to the reader:

1. Fundamentals first. It teaches the load-bearing practices an organization must have to claim mastery of the security of the infrastructure that hosts and serves its AI/HAI systems, not a catalog of everything one could do.
2. Measurable by default. Every activity prescribed in these pages is paired with at least one outcome metric (with a baseline, a target, and a source). Activity counts are not metrics; outcomes are.
3. Self-contained. The document does not require the reader to follow links, open companion files, or chase references. Every concept used in the assessment is defined inside these pages.

If a statement in this handbook treats AI as a tool performing security rather than the infrastructure being secured as the subject, that statement is wrong. Flag it.

Table of Contents

Part I, Domain Overview

1. About this handbook
2. The Infrastructure domain in v3.0 terms
3. Why a domain-specific handbook
4. The seven AI/HAI infrastructure archetypes
5. Domain boundary rules
6. Stakeholders and roles
7. How to use this handbook

Part II, Foundations

1. The four Business Functions in this domain
2. The three maturity levels
3. HAI-specific threat tactics (EA, AGH, TM, RA)
4. The priority compliance map
5. Shadow AI in the Infrastructure domain (ungoverned AI infrastructure)
6. Metrics taxonomy

Part III, The Twelve Practices in the Infrastructure Domain

1. Strategy & Metrics (SM)
2. Policy & Compliance (PC)
3. Education & Guidance (EG)
4. Threat Assessment (TA)
5. Security Requirements (SR)
6. Secure Architecture (SA)
7. Design Review (DR)
8. Implementation Review (IR)
9. Security Testing (ST)
10. Environment Hardening (EH)
11. Issue Management (IM)
12. Monitoring & Logging (ML)

Part IV, Maturity Assessment Workbook

1. How the assessment works
2. Scoring methodology
3. The questionnaire (108 questions)
4. Practice-level rollup
5. Domain-level rollup
6. Improvement roadmap template

Part V, Reference

1. Glossary
2. Reference frameworks
3. Change log

Part I, Domain Overview

1. About this handbook

HAIAMM is the Human-Assisted Intelligence Assurance Maturity Model. It is an AI assurance maturity model, structured after OWASP SAMM and BSIMM in shape, and scoped to AI/HAI in content. HAIAMM has six domains, Software, Data, Endpoints, Infrastructure, Vendors, Processes, and twelve practices that apply across all six.

This handbook covers the Infrastructure domain. It contains:

• A definition of what the Infrastructure domain is and is not.
• The twelve practices, each described in Infrastructure-domain terms with three maturity levels (Foundational, Comprehensive, Industry-Leading).
• A complete maturity assessment workbook with 108 yes/no questions and a scoring methodology.
• A reference section with a glossary and the major frameworks HAIAMM aligns with.

This is one of six domain handbooks. Infrastructure-specific assessment questions live only in this handbook; the Software handbook contains only Software questions, the Data handbook only Data questions, and so on.

2. The Infrastructure domain in v3.0 terms

The Infrastructure domain governs the infrastructure that hosts and serves AI/HAI systems, the compute, network, and platform substrate on which AI/HAI software runs and AI/HAI data flows. The organization operates this infrastructure itself, in its own cloud accounts or on-premises footprint.

In scope:

• Inference endpoints and model-serving clusters, the network-exposed endpoints that put models behind production traffic.
• Model registries, the versioned artifact stores holding model weights, metadata, lineage records, and promotion history.
• GPU and accelerator fleets, the pool of GPU, TPU, or other accelerator instances used for training, fine-tuning, and high-throughput inference, frequently shared across workloads or tenants.
• Orchestrator and control planes, the workflow engines, agent orchestration platforms, and MLOps control planes that coordinate training jobs, agent steps, tool invocations, and pipeline execution.
• Vector-store infrastructure, the vector databases, embedding indexes, and ingest pipelines backing RAG retrieval.
• AI-specific CI/CD, the training pipelines, eval gates, model-promotion workflows, and deployment automation specific to AI artifacts.
• Feature stores and online serving caches, the low-latency feature-serving layer bridging offline feature engineering and online prediction.

Out of scope of the Infrastructure domain:

• AI software the organization builds, that is the Software domain (the software runs on this infrastructure; the two cross-reference).
• The data the infrastructure stores or moves, that is the Data domain (vector store contents, model artifacts, training corpora as data assets are governed there).
• AI tools and services consumed from third parties, that is the Vendors domain.
• Business workflows that embed AI, that is the Processes domain.
• AI-enabled endpoints and user interfaces, that is the Endpoints domain.

The subject of every cell in this handbook is the AI infrastructure the organization operates. The infrastructure is what is being secured.

3. Why a domain-specific handbook

Operating AI infrastructure is not the same as operating classic cloud infrastructure. Five reasons motivate the standalone handbook:

• AI infrastructure carries failure modes classic cloud security does not address. Model extraction from an inference endpoint, residual-state leakage between GPU jobs, model-registry tampering injecting a backdoored artifact into the supply chain, orchestrator control-plane compromise enabling agent-level EA/AGH/TM/RA at scale, vector-store cross-tenant retrieval bleed, none of these are surfaced by a generic cloud-hardening checklist.
• Engineering provisions AI infrastructure faster than security and platform can follow. A platform engineer spins up a vLLM serving cluster from an IaC module; an ML team registers a fine-tuned model into a SageMaker silo security has never reviewed; a researcher provisions GPU spot instances for an overnight training run. None of this is malicious, it is the normal pace of AI-enabled provisioning operating ahead of governance.
• Regulators have addressed AI infrastructure specifically. EU AI Act Art. 15 cybersecurity for high-risk AI systems applies to the infrastructure hosting those systems. GDPR Art. 32 security of processing applies. FedRAMP and sector cloud rules apply when AI infrastructure hosts regulated workloads. The program must produce evidence on demand.
• Shadow AI infrastructure is the program's primary L1 outcome. Untagged GPU instances, unsanctioned model registries, inference endpoints from personal cloud accounts, AI-specific CI/CD pipelines built outside the platform, these ungoverned components are the central problem the L1 program exists to solve.
• Seven archetypes, one program. The seven AI/HAI infrastructure archetypes behave differently enough that threats, requirements, reference architectures, and tests are archetype-keyed throughout the handbook.

4. The seven AI/HAI infrastructure archetypes

Most of the practices in this handbook key their content to seven archetypes. Knowing the archetypes well is a prerequisite for using the handbook.

1. Inference endpoint / model-serving cluster. The network-exposed endpoint that puts a model behind production traffic. Examples: an internal-only embedding service backed by a self-hosted model, a customer-facing inference API for an org-fine-tuned LLM, a SageMaker / Vertex / Bedrock-hosted inference endpoint. Risk shape: model extraction via inference API (ATLAS AML.T0024), denial-of-inference and prompt-flood, cross-tenant isolation breach, lateral movement from a compromised endpoint workload identity into the registry or training stores, silent model swap past the eval gate.

2. Model registry. The versioned artifact store holding model weights, metadata, lineage records, and promotion history. Examples: MLflow, Weights & Biases, SageMaker Model Registry, Vertex AI Model Registry, an org-built registry. Risk shape: unauthorized model upload (AML.T0010 ML Supply Chain Compromise), post-upload artifact tampering, credential theft for registry access, deletion or rollback abuse.

3. GPU / accelerator fleet. The pool of GPU, TPU, or other accelerator instances used for training, fine-tuning, and high-throughput inference. Frequently shared across workloads or tenants. Risk shape: cross-tenant residual-state leakage on shared GPUs, scheduler abuse co-locating hostile workloads, training-job hijack producing a backdoored model, GPU-firmware persistence.

4. Orchestrator / control plane. The workflow engine, agent orchestration platform, or MLOps control plane that coordinates training jobs, agent steps, tool invocations, and pipeline execution. Examples: Airflow, Temporal, Ray, kubeflow, LangGraph, custom orchestrators. Risk shape: orchestrator credential abuse (EA), workflow injection executing attacker logic under the pipeline's trusted identity (AGH), agent-state tampering, control-plane API abuse.

5. Vector-store infrastructure. The vector database, embedding index, and ingest pipeline backing RAG retrieval. Examples: Pinecone, Weaviate, Qdrant, Chroma, pgvector. Risk shape: unauthorized corpus read, embedding extraction at scale, indexer abuse seeding prompt-injection payloads for all future retrievals, retrieval-policy bypass enabling cross-tenant bleed.

6. AI-specific CI/CD. The training pipeline, eval-gate, model-promotion workflow, and deployment automation specific to AI artifacts. Examples: GitHub Actions / GitLab CI runners for ML pipelines, Argo Workflows for training, custom MLOps pipelines. Risk shape: training-pipeline supply-chain compromise, poisoned-dependency injection, model-promotion bypass and eval-gate spoofing, build-time SSRF reaching cloud metadata endpoints.

7. Feature store / online serving cache. The low-latency feature-serving layer bridging offline feature engineering and online prediction. Examples: Feast, Tecton, Vertex AI Feature Store, SageMaker Feature Store. Risk shape: feature poisoning, online/offline-skew abuse, unauthorized feature read.

A single piece of infrastructure can host more than one archetype simultaneously, an inference cluster running on the same GPU fleet, served from a model registry, orchestrated by a control plane. Threat libraries, requirements packs, reference architectures, and tests in this handbook accommodate that.

5. Domain boundary rules

When in doubt about whether something belongs in the Infrastructure domain, ask: who is responsible for the security of the inside of this thing, and what does the thing actually do?

• If the concern is the compute, network, or platform substrate that hosts AI/HAI software or stores AI/HAI data: it is an Infrastructure artifact.
• If the concern is the AI/HAI software that runs on it: Software. If the concern is the data inside it: Data. If the concern is a vendor service consumed from outside: Vendors.

Common boundary cases:

• A vLLM inference cluster is an Infrastructure artifact (model-serving cluster archetype); the model it serves is a Software artifact (model-serving service archetype in the Software domain, the two are linked but distinct); the model weights stored in the registry are partly a Data concern.
• An MLflow model registry is an Infrastructure artifact; the registered models are Software artifacts; the training corpora referenced in the lineage are Data artifacts.
• A shared GPU fleet running fine-tuning jobs is an Infrastructure artifact (GPU fleet archetype); the training workload that consumes the GPU is a Software artifact (fine-tuning/training workload); the training dataset is a Data artifact.
• A Pinecone vector store hosted in the org's cloud is an Infrastructure artifact (vector-store archetype); the embeddings inside it are a Data artifact; the RAG pipeline that queries it is a Software artifact.

6. Stakeholders and roles

The AI/HAI Infrastructure Assurance program is cross-functional by design. The following roles appear throughout this handbook:

• Executive sponsor. Typically the CISO co-sponsored by the VP of Infrastructure or Head of Platform Engineering; co-sponsorship by the CTO is common where AI infrastructure is a product differentiator. Owns budget, scope, and decision rights for the program.
• Program lead. Operationally accountable for the program day-to-day. Often the Cloud Security or Platform Security lead. Maintains the AI/HAI infrastructure inventory, runs the working group, owns the metrics.
• Cross-functional working group. Security, Platform / SRE, Cloud Architecture, ML Platform, AI/ML Engineering, Privacy/Legal, and FinOps. Meets at least monthly.
• Intake reviewers. A small population trained to assess AI/HAI infrastructure against the threat library, the requirements pack, and the priority compliance map. Drawn from Platform Security, Cloud Architecture, and ML Platform.
• Architect reviewers. Senior cloud architects and platform engineers with sign-off authority on design reviews for AI/HAI infrastructure provisioning.
• Platform engineering / SRE. Owns the day-to-day operation of the infrastructure and the IaC modules that provision it.
• MLOps / ML Platform. Owns the AI-specific layers, model registry, eval gate, training pipelines, serving infrastructure.
• FinOps. Provides GPU-spend and concentration-risk signals; participates in shadow-AI-infra discovery.
• Integration owners. The platform engineer or SRE owner of each AI/HAI infrastructure instance in the inventory, named and accountable for maintaining the instance's posture.

7. How to use this handbook

Three modes of use are supported:

• Read it linearly. Parts I and II ground the reader in the domain and foundations. Part III walks the twelve practices in the Infrastructure-domain context. Part IV provides the assessment instrument. Part V is reference.
• Run an assessment. Skim Parts I and II for context (one to two hours), then go directly to Part IV. The 108 questions are organized by practice and by maturity level, with explicit evidence prompts. Scoring methodology and rollup tables follow.
• Build a program from scratch. Read Part II carefully, then implement the twelve practices' Level 1 in the order described in Part II's dependency text. Use the Level 1 questions in Part IV as a self-check for completeness.

The questions in Part IV are duplicated as a per-practice "Practice Maturity Questions" section at the end of each practice in Part III. They are the same questions; the duplication is deliberate so the practice-by-practice reader sees the assessment instrument inline.

Part II, Foundations

8. The four Business Functions in this domain

The twelve practices group into four Business Functions. Each function exists for a distinct intent. Every practice belongs to exactly one function.

Governance, Strategy & Metrics (SM), Policy & Compliance (PC), Education & Guidance (EG). Establish why, what, who, and how: the program's strategic frame, its enforceable rules, and the workforce literacy that makes everything downstream possible. In this domain, Governance answers: who owns AI infrastructure risk, what policies apply, what training every platform engineer and SRE must complete, and how AI infrastructure components enter a sanctioned production state.

Building, Threat Assessment (TA), Security Requirements (SR), Secure Architecture (SA). Decide what could go wrong, what the component must do about it, and how the component is shaped to do it, before provisioning begins. In this domain, Building answers: what threats AI infrastructure archetypes carry, what requirements every component must meet, what reference architectures platform teams should reach for.

Verification, Design Review (DR), Implementation Review (IR), Security Testing (ST). Prove that the designed component, the implemented component, and the running component actually meet the Building-function outputs. In this domain, Verification answers: did the design follow the SA reference pattern, do the live IaC state and cloud-provider configuration match the design, and does the component actually behave correctly under adversarial probes.

Operations, Environment Hardening (EH), Issue Management (IM), Monitoring & Logging (ML). Run the program safely in production, harden the runtime envelope, manage the issues, and watch what is actually happening. In this domain, Operations answers: which controls keep sanctioned AI infrastructure frictionless and unsanctioned components observable, where AI infrastructure issues go, and what telemetry produces deployer-duty and cloud-compliance evidence on demand.

Cross-function rule: progress in one function without the others is unstable. The handbook is balanced across the four by design. L1 build order follows the dependency graph: SM precedes everything; PC and EG follow SM; TA, SR, and SA follow Governance; DR and ST run after SA L1 exists; IR follows DR; EH, IM, and ML form the Operations layer that depends on SM inventory, SA patterns, and PC policies all being in place.

9. The three maturity levels

Every cell in this handbook is one of three maturity levels. The levels are cumulative, Level 2 assumes Level 1 is in place; Level 3 assumes Level 2 is in place.

Level 1, Foundational. Stand up the minimum viable capability. Discover what AI/HAI infrastructure the organization operates, publish the core policies, run the first version of the controls, baseline the metrics. Typical outputs: an inventory of components across all seven archetypes, short published policies (AI Infrastructure Standards, GPU AUP, Provisioning Gate), per-archetype threat models, per-archetype requirements packs, per-archetype reference patterns, first detections, first logging baselines, AI-specific incident playbook. Reality check: if the program cannot answer "what AI infrastructure do we operate, what rules apply to it, and who is accountable" within a week, it is not at Level 1.

Level 2, Comprehensive. Calibrate the program's intensity by risk tier. Move from one-size-fits-all to differentiated depth. Replace point-in-time activities with continuous validation. Typical outputs: a published risk-tier rubric, a tier-treatment matrix, per-tier calibrated activities, per-component deep threat models for Critical-tier, IaC-encoded reference patterns with conformance test suites, scenario-based design reviews, continuous configuration-drift detection, per-tier red-team cadence, tier-calibrated hardening, tier-calibrated logging. Reality check: if the same review effort goes to a Low-tier dev sandbox and to a Critical-tier customer-facing inference cluster, the program is not at Level 2.

Level 3, Industry-Leading. Automate the substrate. Benchmark externally against peers. Contribute back to the AI-assurance ecosystem. Typical outputs: signal-driven inventory and tier updates, machine-readable requirements with IaC attestation, continuous configuration attestation, automated adversarial testing, IaC-driven hardening with adaptive tightening from ML and IM signals, detection-as-code, external benchmarking briefs, contributions to MITRE ATLAS, CNCF AI, OpenSSF AI, FinOps Foundation, sector ISACs. Reality check: if all activity is still internally generated, no external contributions, no benchmarking deltas, no automation replacing routine review work, the program is mature for its own purposes but is not industry-leading.

10. HAI-specific threat tactics (EA, AGH, TM, RA)

Four AI-specific threat-tactic categories appear throughout this handbook. In the Infrastructure domain they manifest in the components that host and serve AI/HAI systems.

EA, Excessive Agency. Infrastructure components are granted broader IAM or network reach than the workload requires, an orchestrator service account with permissions across multiple namespaces, an inference endpoint workload identity with model-registry write access, a GPU job runner with cluster-wide credentials. The over-broad infrastructure grant.

AGH, Agent Goal Hijack. In Infrastructure terms, the orchestrator control plane is the most exposed surface, a workflow injection that redirects execution under the orchestrator's trusted identity. Indirect injection via vector-store-served content reaching an agent workload that runs in the infrastructure.

TM, Tool Misuse. Infrastructure tools and APIs invoked for attacker purposes, model-registry write APIs called to swap a model artifact, control-plane APIs called to spawn unauthorized jobs, vector-store query APIs called for extraction. Differs from EA in that the scope of the tool may be appropriate; the tactic is the misuse.

RA, Rogue Agents. Autonomous agents running on infrastructure drift from intended behavior across long sessions, reflective loops, or multi-agent miscoordination, accumulating effects nobody explicitly instructed. The infrastructure carries the consequences.

The four categories sit alongside infrastructure-native failure modes, model extraction, residual-state leakage, supply-chain compromise, cross-tenant bleed, control-plane breach, and are tagged where the threat libraries, requirements, and tests reference them. The Cloud-Threat-Taxonomy (HCT) is the cross-reference for cloud-IAM standing risks (BadPermissions, BadPrincipal) that ATLAS does not enumerate.

11. The priority compliance map

Every Infrastructure-domain Policy & Compliance practice at Level 1 publishes (and downstream practices reference) a one-page priority compliance map. The set below is the priority set for the Infrastructure domain. Sector-specific items are added as applicable.

The map's purpose is traceability: an auditor or regulator asking "how is Art. 15 cybersecurity addressed for our AI infrastructure?" should reach a single cell in the map and from there one policy and from there one evidence artifact.

12. Shadow AI in the Infrastructure domain (ungoverned AI infrastructure)

Shadow AI in the Infrastructure domain takes a specific shape: ungoverned AI infrastructure components.

• Shadow AI infrastructure is the ungoverned component. Untagged GPU instances spun up for experimentation, model registries created outside the governed platform, inference endpoints deployed from personal cloud accounts, AI-specific CI/CD pipelines built outside the org's IaC standard, vector stores stood up as database extensions. The components exist in the cloud but are not in the SM-Infrastructure inventory and carry no SR REM.
• Shadow infrastructure compounds. Every month of ungoverned operation increases the compute footprint, the data-class exposure, and the regulatory blast radius. A shadow inference endpoint processing regulated data without DPA coverage creates a continuing breach. A shadow GPU fleet without residual-state clearing accumulates cross-tenant exposure across every job that runs on it.
• Shadow infrastructure is observable today. The signals already exist in most enterprises, cloud-provider asset APIs, FinOps GPU-spend data, Kubernetes admission webhooks, egress logs to AI provider domains, IAM activity logs for AI-related principals, model-registry APIs. No new tooling is required at L1.
• Shadow infrastructure manifests through more than one domain. The handbook treats it primarily in SM and EG, but it appears in TA (shadow-AI-infrastructure threat view), PC (provisioning gate amnesty path), EH (egress allowlist, signed-artifact admission), IM (shadow-endpoint containment play), and ML (shadow-endpoint detection).

Every Level 1 activity in this handbook contributes to making shadow AI infrastructure visible, attributable, and trending down. The Level 1 outcome metric "shadow-AI-infra ratio" appears in Strategy & Metrics, Policy & Compliance, Education & Guidance, Threat Assessment, Environment Hardening, and Monitoring & Logging, six of the twelve practices. That is intentional.

13. Metrics taxonomy

Every level block in this handbook carries three metric types. The taxonomy is the canonical vocabulary; examples and targets are practice-specific.

• Outcome metrics (lagging). Directly measure whether the level's goal was achieved. Reported monthly or quarterly. Stated in a four-column table: Metric · Baseline · Target · Source.
• Process metrics (leading). Predict outcome metrics by measuring execution. Reported weekly or at the cadence of the underlying activity.
• Effectiveness metrics (business value). Measure what the outcome means to the business. Reported quarterly, often qualitative supported by quantitative.

Metric selection follows two rules: SMART (specific, measurable, achievable, relevant, time-bound) and outcome over output (results are preferred to activity counts). If a metric does not have a baseline column, the baseline is the value the program records on first measurement. The first cycle of measurement is itself an L1 activity.

Part III, The Twelve Practices in the Infrastructure Domain

Each practice section follows the same shape:

• Practice Overview. Objective, description, context.
• Maturity Level 1. Objective, activities (A, B, C), outcome metrics, success criteria.
• Maturity Level 2. Same structure.
• Maturity Level 3. Same structure.
• Common Pitfalls. Three to four per level.
• Practice Maturity Questions. Three yes/no questions per level, the same questions also appear in the Part IV assessment workbook.

14. Strategy & Metrics (SM)

Practice Overview

Objective: Stand up an AI/HAI Infrastructure Assurance program that discovers, inventories, and strategically governs the infrastructure that hosts and serves the organization's AI/HAI systems, with shadow AI infrastructure prevention as the primary L1 outcome and a defensible risk-tier rubric as the primary L2 deliverable.

Description: SM-Infrastructure establishes the program charter, the authoritative inventory of the compute and platform layer that AI/HAI systems run on, and the practice-maturity metrics that prove the program is working. The Infrastructure domain governs seven archetypes: inference endpoints and model-serving clusters, model registries, GPU and accelerator fleets, orchestrator and control-plane platforms, vector-store infrastructure, AI-specific CI/CD pipelines, and feature stores or online serving caches. SM-Infrastructure L2 produces the risk-tier rubric every other Infrastructure-domain L2 practice depends on per the v3.0 dependency graph.

Context: Infrastructure teams adopt AI workloads faster than the security and platform-governance programs meant to track them. A platform engineer spins up a vLLM serving cluster from an IaC module; an ML team registers a fine-tuned model into a SageMaker Model Registry silo security has never reviewed; a researcher provisions GPU spot instances for an overnight training run and leaves persistent credentials behind. None of this is malicious, it is the normal pace of AI-enabled infrastructure provisioning. But it bypasses threat modeling, configuration requirements, reference architecture, and the deployer duties that EU AI Act Art. 15 (accuracy, robustness, and cybersecurity of high-risk systems) and GDPR Art. 32 (security of processing) place on whoever operates the system. The AI/HAI Infrastructure Assurance program makes this surface visible, attaches accountable ownership per archetype, and puts a light-touch intake gate on the path from prototype provisioning to production hosting, so sanctioned infrastructure ships faster and shadow AI infrastructure cannot quietly accumulate.

Maturity Level 1

Objective: Stand up the AI/HAI Infrastructure Assurance program, build an inventory of the seven infrastructure archetypes, and establish baseline metrics that prove shadow AI infrastructure is decreasing.

Activities.

A) Charter the AI/HAI Infrastructure Assurance program. Publish a short program charter that names the problem (shadow AI infrastructure, ungoverned GPU fleets, untracked inference endpoints, unregistered model deployments, orchestrator control planes with no security review), defines scope, and assigns accountable ownership. The program does not require a new team, it requires a named owner, a cross-functional working group, and a clear intake gate for new AI/HAI infrastructure before it reaches production hosting. Charter elements include a problem statement grounded in why AI/HAI infrastructure is a distinct first-party risk category, inference endpoints are high-value attack surfaces (model extraction, prompt injection at the serving layer, data exfiltration via API), GPU fleets concentrate sensitive training workloads and their credentials, model registries are supply-chain control points for every downstream artifact, orchestrator control planes carry EA/TM/RA risk proportional to the agent workloads they run, vector stores hold invertible embeddings and retrieval context that feeds AGH, and AI-specific CI/CD pipelines are software-supply-chain attack surfaces for model promotion; the seven in-scope archetypes (inference endpoint / model-serving cluster, model registry, GPU / accelerator fleet, orchestrator / control plane, vector-store infrastructure, AI-specific CI/CD, feature store / online serving cache); an executive sponsor (typically the CISO co-sponsored by the VP of Infrastructure / Head of Platform Engineering, co-signed by the CTO where AI infrastructure is a product differentiator); a working group spanning Security, Platform/SRE, Cloud Architecture, ML Platform, AI/ML Engineering, Privacy/Legal, and FinOps; decision rights for provisioning approval, block, exception, and go-live; and a numerical year-one success target tied to the L1 outcome metrics.

B) Build the AI/HAI infrastructure inventory and discover shadow AI infrastructure. Establish a single AI/HAI infrastructure inventory as the program's source of truth, seeded from authoritative infrastructure signals and then actively reconciled against shadow-infra discovery. Minimum inventory fields are instance name, owning team, archetype, production status (prototype / staging / production / deprecated), customer-facing / internal-only / multi-tenant flags, AI/HAI software artifacts hosted (linked to SM-Software inventory records), data classification of data passing through (public / internal / confidential / regulated, pulled from SM-Data inventory where available), geographic scope (single-region / multi-region / cross-border, the last triggering a GDPR Art. 44–49 assessment), isolation posture (dedicated / shared / multi-tenant), compute scale with a concentration flag where a single fleet serves multiple Critical-tier AI artifacts, decision-affecting use (hosts an EU AI Act Annex III / GDPR Art. 22 system, inherited from SM-Software), approval status (Sanctioned / Provisional / Under review / Prohibited / Awaiting Intake), risk tier (populated at L2), and linked artifacts (TA snapshot, SR REM, SA pattern, latest IR finding, ML logging-baseline status). Discovery at L1 uses signals platform, cloud, and FinOps teams already have: cloud-provider asset APIs (SageMaker and Bedrock listings, Vertex AI endpoints, Azure OpenAI deployments, EC2/GKE/AKS GPU instance types and node pools); Kubernetes and container-registry scans (pods with GPU resource requests, images from ML base registries, Helm releases for kubeflow / seldon / ray / temporal / airflow, ML-tagged namespaces); model-registry APIs (MLflow, Weights & Biases, SageMaker and Vertex model registries); IaC repos (Terraform / Pulumi modules tagged ai-infra, ml-platform, gpu-fleet, vector-store, model-registry, inference-endpoint); cloud-spend and FinOps signals where unexpected GPU spend spikes are shadow-infra indicators; egress logs to AI provider domains; vector-store collection listings; and a 60-second self-attestation form publicized to platform, SRE, and ML engineering with an amnesty window for previously undisclosed AI/HAI infrastructure already in production.

C) Establish foundational metrics that measure practice maturity and shadow AI infrastructure reduction. Baseline and track a small, automatable set of outcome, process, and effectiveness metrics tied to the L1 outcome (shadow-infra reduction and inventory coverage of what the org hosts). Publish a quarterly shadow AI infra scoreboard to the executive sponsor reporting total inventory by approval status broken out by archetype, new infrastructure instances discovered this quarter and their intake status, the shadow-AI-infra ratio trend across the last four quarters, AI Infrastructure Standards and GPU AUP attestation coverage across platform and SRE headcount, and the top five unmitigated infrastructure risks with owners and remediation status. Keep activity counts (scans run, tickets closed) out of the outcome view, they belong to process metrics.

Outcome Metrics (L1).

Success Criteria.

• Program charter published and sponsored by an accountable executive (CISO co-sponsored by VP Infrastructure / Head of Platform Engineering) with a cross-functional working group.
• AI/HAI infrastructure inventory exists as a single source of truth with ≥90% coverage of discovered instances within 12 months, broken out by the seven archetypes.
• Shadow-AI-infra ratio baselined and trending down for two consecutive quarters.
• ≥95% of platform and SRE headcount has acknowledged the AI Infrastructure Standards and GPU AUP policies.
• Quarterly shadow AI infra scoreboard delivered to the executive sponsor with archetype-level breakdown.

Maturity Level 2

Objective: Risk-tier the AI/HAI infrastructure inventory, calibrate the program's intensity per tier, and measure practice maturity and shadow-infra reduction per tier, establishing the tier rubric every other Infrastructure-domain L2 practice depends on.

Activities.

A) Define the AI/HAI infrastructure risk-tier rubric. Four tiers, Critical / High / Medium / Low, assigned from a small set of auditable dimensions specific to AI/HAI infrastructure: the tier of AI/HAI software hosted (an instance hosting a Critical-tier Software artifact per the SM-Software rubric is Critical infrastructure, infrastructure tier is the maximum of the hosted-software tier and every infrastructure-specific dimension below); multi-tenancy and isolation (multi-tenant serving infrastructure sharing inference compute or vector-store namespace across teams, products, or customers with no per-tenant isolation → elevate); customer exposure (customer-facing inference endpoint, public or B2B → Critical or High; internal-employee-facing → neutral; developer-only or eval-only → lower); compute scale and concentration (a single GPU fleet or inference cluster serving multiple Critical-tier AI workloads → elevate, because one compromise affects multiple critical workloads simultaneously); data classification of data passing through (regulated data, PII, PHI, PCI, source code, customer confidential, transiting or stored at inference, training, or retrieval → Critical or High; cross-border personal-data flow → elevate and trigger a GDPR Art. 44–49 assessment); decision-affecting use hosted (an EU AI Act Annex III high-risk system or a GDPR Art. 22 automated-decisioning system running on the instance → Critical); and geographic scope (multi-region, cross-border deployments where personal data transits between regions → elevate). Tier derivation is deterministic from the rubric inputs; human overrides are allowed but recorded with rationale and reviewed by the working group.

B) Calibrate program intensity per tier. Publish a tier-treatment matrix specifying what each tier receives across the Infrastructure-domain program, intake depth, isolation requirement, encryption posture, network controls, IAM posture, TA depth, IR cadence and material-change re-review triggers, ST battery, IM SLAs by severity, and FedRAMP / regional-compliance gating. Critical instances receive the full program: full SR pack with REM plus executive and security sign-off; per-tenant isolation with a dedicated namespace or cluster per workload or per customer; HSM-rooted or KMS key-per-instance encryption of model artifacts with BYOK or customer-managed data-at-rest keys and TLS 1.2+ in transit; egress allowlisting to named model providers and no public endpoint without explicit approval; least-privilege per-instance service accounts with no standing human IAM on GPU fleet or serving cluster; per-instance deep threat models covering model-extraction, inference-endpoint attack surface, and AGH/EA/TM/RA vectors for orchestrators; go-live plus semi-annual IR plus on-every-material-change re-review within 14 days; the full ST battery; FedRAMP or sector-equivalent compliance evidence before go-live where applicable; and Critical IM SLAs (ack ≤4h, mitigate ≤48h, root-cause ≤30d). Low instances use the fast-track, archetype-level threat model, base SR pack, shared cluster, managed encryption, go-live IR only, spot-check ST, and re-review at annual review. Each downstream Infrastructure-domain L2 practice inherits this calibration; the rubric and the matrix are authored here in SM L2 and changes flow through the SM working group.

C) Per-tier scoreboard and governance. The L1 shadow AI infra scoreboard becomes tier-aware. Inventory state is reported by tier and by archetype, a Critical-tier customer-facing inference cluster is its own row, the count of Low-tier internal vector-store prototypes is one line. Shadow-AI-infra ratio is reported per tier, a Critical-tier unsanctioned inference endpoint is a headline, a Low-tier one is a line item. Per-tier SLA adherence across intake, IR, ST, ML, and IM is reported monthly. The tier-movement log records upgrades (an instance that gained customer exposure, regulated-data flow, multi-tenant use, or began hosting a Critical-tier software artifact) and downgrades with rationale, reviewed by the program sponsor. Quarterly executive review explicitly discusses tier-balance: is the program's effort matching the program's risk profile?

Outcome Metrics (L2).

Success Criteria.

• Risk-tier rubric published and applied; tier assigned to 100% of inventory from auditable dimensions.
• Tier-treatment matrix published; downstream practices (PC, TA, SR, SA, DR, IR, ST, EH, ML, IM) calibrated to it.
• Per-tier shadow-AI-infra ratio reported quarterly; Critical-tier unsanctioned infrastructure in production = 0.
• Per-tier SLA adherence ≥90% across practices.
• Tier-movement governance active, changes logged with rationale and reviewed by the sponsor.

Maturity Level 3

Objective: Automate inventory and tier maintenance from cloud-provider APIs, IaC telemetry, and runtime signals; benchmark the program against external infrastructure security peers; and contribute AI/HAI infrastructure security intelligence back to the industry.

Activities.

A) Continuous inventory and tier automation from cloud, IaC, and runtime signals. Inventory auto-updates from cloud-provider asset API events (new SageMaker endpoint, new Bedrock provisioned throughput, new GKE GPU node pool, new Azure ML compute cluster), IaC state events (a new Terraform module with AI-infra tags applied or destroyed), Kubernetes admission webhook events (a new pod with a GPU resource request or AI/ML image deployed), model-registry events (a new model registered or version promoted triggers a serving-infra linkage check), GPU-spend deltas (an unexplained new spend tag is a shadow-infra signal), egress-log anomalies (a new outbound call to an AI provider domain not attributable to a known inventory instance), vector-store collection-creation events, self-attestation, and the intake queue. Tier assignments are rule-based on the L2 rubric inputs; rule changes are versioned and replayable; tier changes auto-trigger downstream practice obligations within 24 hours (a Medium-to-Critical upgrade triggers the isolation gate, the encryption upgrade, IR reconfiguration, and the FedRAMP / regional-compliance check). Human curation handles new archetype patterns, ambiguous multi-workload instances, and dimensional-input conflicts between Software and Infrastructure tier derivations. A data-quality SLO is published: ≥99% of active AI/HAI infrastructure instances correctly tiered within 48 hours of a material change; ≥95% inventory completeness against discovery-source reconciliation.

B) External benchmarking. Program metrics are compared against peer benchmarks through CNCF AI/ML working groups and CNCF TAG Security AI infrastructure guidance, OpenSSF AI supply-chain security working groups, FinOps Foundation AI infrastructure working groups, the MLOps and ML platform community (KubeCon ML track, Ray Summit, Apply(ML)), sector ISACs with AI infrastructure working groups (FS-ISAC, H-ISAC, IT-ISAC), and formal peer roundtables (CISO communities with AI infrastructure scope, cloud-provider security practitioner circles). A semi-annual "how we compare" brief covers inventory coverage, shadow-AI-infra ratio, per-tier SLA adherence, isolation posture of Critical-tier instances, automation level, IR drift detection rate, ST coverage rate, and time from provisioning request to provisional approval. Benchmark deltas inform program investment, the board-level narrative, and the next year's L2 / L3 work priorities.

C) Contribute AI/HAI infrastructure security intelligence to the industry. Contribute to MITRE ATLAS (new TTPs observed in own-operated AI/HAI infrastructure, inference-endpoint extraction, model-registry tampering, orchestrator goal-hijack via control-plane compromise, tagged to HAI TTPs EA / AGH / TM / RA where applicable), CNCF AI/ML Working Group and CNCF TAG Security AI infrastructure guidance (inference-endpoint hardening, model-registry security, Kubernetes GPU-workload isolation patterns), OpenSSF AI (model-supply-chain integrity, AI-specific CI/CD security, model-registry signing and verification), the FinOps Foundation AI Infrastructure Special Interest Group (GPU fleet governance, concentration-risk frameworks), the NIST AI RMF Playbook (infrastructure-domain operational guidance), the CSA AI Safety Initiative (AI infrastructure controls matrix), and the ISO/IEC 42001 AIMS community. Target a minimum of four substantive contributions per year; quality over volume; every contribution anonymized and legally vetted.

Outcome Metrics (L3).

Success Criteria.

• Inventory auto-update SLO published and met; tier-rule change-log versioned and replayable.
• Tier-assignment automation operational with exception-based human review; tier changes auto-trigger downstream obligations within 24 hours.
• Semi-annual external-benchmarking brief published to the sponsor with ≥5 peer-comparable metrics (CNCF, OpenSSF AI, FinOps Foundation, sector ISACs, ML-platform community).
• ≥4 substantive industry contributions per year, anonymized and cited.
• Executive / board ROI narrative refreshed at least annually with external benchmarks and avoided-loss examples.

Common Pitfalls

Level 1. - Inventory seeded only from "AI infrastructure the ML team told us about", misses GPU spot instances provisioned by researchers, model-serving deployments added to Kubernetes by engineering teams, vector stores stood up as database extensions, and orchestrators repurposed for AI workloads. - Treating AI/HAI infrastructure as a general CMDB concern without the seven-archetype taxonomy, Critical inference endpoints and Low internal vector stores are conflated, and the program cannot tier without re-inventorying. - Program positioned as a blocker, intake SLA unpublished, provisioning cycles balloon, and teams route around the program by deploying from personal cloud accounts or untagged resources. - Executive sponsor is security-only; VP Infrastructure or Head of Platform Engineering is not a co-owner, so the program lacks the infrastructure authority to enforce intake gates.

Level 2. - Tier rubric ignores the hosted-software-tier dimension, an inference cluster serving a Critical-tier customer-facing agent is tiered Low because the infra team never checked the SM-Software inventory. - Tier-treatment matrix published but not enforced, Critical-tier multi-tenant inference endpoints share namespaces with Medium-tier workloads because isolation was never made a go-live condition. - Scoreboard reported in aggregate, hiding Critical-tier shadow infrastructure because overall averages look acceptable. - Rubric over-engineered, too many sub-dimensions turn tier derivation into a long committee discussion rather than a deterministic computation, and downstream practices treat tier as advisory rather than operational.

Level 3. - Automation runs without a data-quality SLO, signal-driven inventory silently drifts as cloud-provider API schemas change or Kubernetes label conventions shift, and platform teams stop trusting it. - Benchmarking chooses peers that flatter the program (startup GPU-fleet governance benchmarks while operating at regulated-enterprise scale). - Industry "contributions" are conference talks and whitepapers, not technical artifacts that land in CNCF / OpenSSF / FinOps / MITRE working-group outputs. - Tier-change downstream-trigger automation fires on every node restart or autoscale event, platform teams disable the signal-source rather than fix rule sensitivity.

Practice Maturity Questions

Level 1. 1. Is there a published AI/HAI Infrastructure Assurance program charter with a named executive sponsor (CISO co-sponsored by VP Infrastructure / Head of Platform Engineering), a cross-functional working group, and clear decision rights for approval, block, exception, and go-live across all seven infrastructure archetypes? Evidence: charter document with sponsor signatures and working-group roster. 2. Does a single AI/HAI infrastructure inventory exist, seeded from cloud-provider APIs, Kubernetes workload signals, IaC repos, model-registry APIs, cloud-spend / GPU-spend signals, egress logs, and vector-store listings, covering all seven archetypes with ≥90% coverage of discovered instances within 12 months? Evidence: inventory export reconciled against discovery-source query results. 3. Are L1 outcome metrics baselined and reported quarterly to the sponsor, inventory coverage, shadow-AI-infra ratio (≤15% trending down), policy attestation (≥95% of platform and SRE), named-owner coverage (100%), and data-exposure events? Evidence: most recent quarterly shadow AI infra scoreboard deck.

Level 2. 1. Is every AI/HAI infrastructure instance in the inventory assigned a risk tier based on the seven auditable dimensions, tier of AI/HAI software hosted, multi-tenancy isolation, customer exposure, compute scale and concentration, data classification of data passing through, decision-affecting use hosted, and geographic scope? Evidence: rubric document plus inventory column showing tier and derivation inputs per instance. 2. Is there a published tier-treatment matrix driving differential intensity across PC, TA, SR, SA, DR, IR, ST, EH, ML, and IM, with ≥95% of Critical-tier instances receiving full-scope treatment (per-tenant isolation, HSM/KMS-rooted encryption, egress allowlisting, least-privilege IAM, semi-annual IR, full ST battery) in the last 12 months? Evidence: tier-treatment matrix plus cross-practice adherence report for Critical instances. 3. Does the quarterly shadow AI infra scoreboard report per tier and per archetype (with Critical-tier unsanctioned infrastructure in production tracked at zero), and is tier-movement logged and reviewed by the sponsor, including FedRAMP / regional-compliance gating for Critical-tier instances in applicable contexts? Evidence: tier-aware scoreboard and tier-movement log for the prior two quarters.

Level 3. 1. Do inventory and tier assignment auto-update from live cloud-provider API events, IaC state events, Kubernetes admission webhook telemetry, model-registry events, GPU-spend deltas, and egress-log anomalies, with a published data-quality SLO and ≥80% of curation handled automatically with exception-based human review? Evidence: pipeline diagram, SLO dashboard, curation-source breakdown. 2. Do you publish a semi-annual external-benchmarking brief comparing the program against ≥5 peer-comparable metrics via CNCF / OpenSSF AI / FinOps Foundation / sector ISACs / ML-platform community, and does it drive investment decisions? Evidence: most recent brief and a budget or staffing decision traceable to a benchmark delta. 3. Does the program contribute ≥4 substantive, anonymized artifacts per year to the AI/HAI infrastructure security ecosystem (CNCF, OpenSSF AI, FinOps Foundation, MITRE ATLAS, NIST AI RMF, CSA AI Safety Initiative, sector ISACs), and does the exec/board ROI narrative cite external benchmarks? Evidence: contribution log with acceptance confirmations and the most recent ROI narrative.

15. Policy & Compliance (PC)

Practice Overview

Objective: Publish the priority policies and compliance map that make the AI/HAI Infrastructure Assurance program enforceable, so every inference endpoint, model registry, GPU fleet, orchestrator control plane, vector store, AI-specific CI/CD pipeline, and feature store the organization hosts and operates is governed by documented rules, gated before it serves production AI workloads, and defensible to auditors and regulators.

Description: PC-Infrastructure codifies three priority policies specific to AI/HAI infrastructure governance, an AI Infrastructure Standards Policy establishing per-archetype security baselines (encryption, isolation, region and residency, observability minimums), a GPU / Accelerator Acceptable Use Policy governing who may run what workloads on what fleet with what data classification, and an AI Infra Intake / Provisioning Gate Policy defining what every new instance must produce before hosting production AI workloads. It maps those policies to the compliance regimes that directly apply to infrastructure hosting AI/HAI systems: EU AI Act Art. 15 (accuracy, robustness, cybersecurity of high-risk systems), Art. 12 (record-keeping and logs), and Annex III high-risk classification; GDPR Art. 32 (security of processing), Art. 44–49 (international transfers and region pinning), and Art. 33 (breach notification); ISO/IEC 42001 AIMS; ISO/IEC 27001 A.5 and A.8; SOC 2 CC6/CC7/CC8; and sector-specific obligations (HIPAA security rule, PCI-DSS, FedRAMP / sector cloud) where applicable.

Context: Most organizations operating AI infrastructure inherit generic cloud-hardening standards and generic change-management policies. Neither answers the questions AI/HAI infrastructure raises: what isolation controls are required before a multi-tenant inference cluster serves customer data, who may authorize a training run on a GPU fleet that touches regulated PII, what residency obligations apply to a cross-border vector store serving a GDPR-regulated retrieval pipeline, or how EU AI Act Art. 15 cybersecurity evidence flows from the team that provisions the inference endpoint to the security review that approved it. Without AI-specific policies and an explicit compliance map, shadow AI infrastructure accumulates, Art. 15 and Art. 32 obligations go unmet, and auditors cannot trace a regulation to a control. PC-Infrastructure governs what the organization operates, in contrast to PC-Software, which governs what it builds, and PC-Vendors, which governs what it consumes.

Maturity Level 1

Objective: Publish the three priority AI/HAI infrastructure policies, map them to the priority compliance requirements, and operate the provisioning gate that prevents ungated infrastructure from hosting production AI workloads.

Activities.

A) Publish the three priority AI/HAI infrastructure policies. Ship each in its smallest useful form, short, readable, and specific enough to be enforceable against platform provisioning decisions. The AI Infrastructure Standards Policy specifies per-archetype security baselines every instance must meet before hosting production workloads: inference endpoints require TLS 1.2+ on all serving interfaces, no public endpoint without DR approval, model artifacts encrypted at rest (managed KMS minimum), authentication on all API calls, and structured inference access logs; model registries require artifact signing or checksum verification on promotion, a two-party approval gate for production promotion, vaulted registry credentials, and a retained promotion audit log; GPU / accelerator fleets require vaulted fleet credentials, no standing human IAM on production training or inference nodes, GPU workload isolation, training-data access scoped to the declared corpus, and GPU-spend tagging by owning team and workload; orchestrator control planes require tool-call scope bounded to a declared tool list, no API calls outside SR-approved scope, control-plane authentication, and retained state and tool-call logs; vector stores require collection- or namespace-level access control, no public-read collection without DR approval, TLS on client connections, and content classified per the SM-Infrastructure and SM-Data inventories; AI-specific CI/CD requires signed or checksummed model artifacts, promotion gates conditioned on passing eval scores, vaulted pipeline credentials, and audited runs with an artifact-lineage record; feature stores require feature-group-level access control, TLS on the serving interface, and retained feature-serving logs. The GPU / Accelerator Acceptable Use Policy enumerates what is permitted without pre-approval (training or inference on sanctioned fleets using only public or internal-classified data, workloads already declared in the inventory), what requires approval before running (training or fine-tuning on confidential or regulated data, workloads spanning classification boundaries on a shared fleet, large-scale batch runs consuming the majority of a shared fleet, any workload not yet inventoried), what is prohibited without explicit named sign-off (training on customer PII without privacy-officer approval, regulated-data workloads on a multi-tenant fleet without per-workload isolation confirmation, exporting fleet credentials to personal workstations or external repositories, spinning up GPU resources in personal or untagged cloud accounts to evade the gate), the disclosure obligation to add every GPU-hosted AI workload to the SM-Infrastructure inventory including side-projects and feature-flagged workloads, and the attestation requirement at hire and annually. The AI Infra Intake / Provisioning Gate Policy makes intake mandatory before production provisioning for all seven archetypes, lists the required provisioning artifacts by archetype (named owning team and infrastructure owner, archetype-keyed Standards baseline met, TA threat snapshot from the archetype-level library, SM-Infrastructure inventory record, plus archetype-specific confirmations such as no-public-endpoint or model encryption for inference clusters, fleet credential vault storage and isolation posture for GPU fleets, SR-approved tool-call scope for orchestrators, collection access control for vector stores, and artifact signing for AI-specific CI/CD, with data-residency and GDPR Art. 44–49 transfer basis required for cross-border or regulated-data instances), exposes an amnesty path for previously ungated production instances (routed as open IM findings), and names the program sponsor (or delegated platform security lead) as the provisioning decision authority.

B) Map the three policies to the priority compliance requirements. Build a one-page priority compliance map that an auditor can read in 60 seconds. The map ties EU AI Act Art. 15 cybersecurity to the AI Infrastructure Standards Policy (archetype-level security baselines, endpoint auth, TLS, model encryption, access logging); Art. 12 record-keeping to the Standards Policy (inference access log and orchestrator state and tool-call log retention) plus the Provisioning Gate (log retention confirmed at go-live); Annex III high-risk classification to the Provisioning Gate (high-risk hosting confirmed at intake with an Art. 15 evidence checklist). GDPR Art. 32 security of processing maps to the Standards Policy (encryption at rest and in transit, access control, per-archetype isolation) plus the GPU AUP (prohibited regulated-data workloads on unisolated fleets); Art. 44–49 international transfers map to the Standards Policy (residency requirement for cross-border instances) plus the Gate (transfer basis confirmed at intake); Art. 33 breach notification maps to the Gate (IR-readiness attestation confirming a breach-response path for every regulated-data-processing instance). ISO/IEC 42001 AIMS traces to the full three-policy stack plus the Gate as the operational infrastructure evidence; ISO/IEC 27001 A.5 supplier relationships traces to the Standards Policy (cloud-provider DPA, access logging, encryption for managed services); A.8 asset management traces to the SM-Infrastructure inventory plus the GPU AUP. SOC 2 CC6 logical and physical access controls traces to the Standards Policy (per-archetype auth, vaulted credentials, IAM posture); CC7 system operations traces to the Standards Policy (log retention) plus the Gate (logging baseline confirmed); CC8 change management traces to the Gate (all provisioning changes gated, promotion gates on AI-specific CI/CD). Sector-specific rules flow into the archetype controls or the Gate's required-artifacts checklist for affected instances, the HIPAA security rule maps to encryption and access control plus a HIPAA intake checklist for PHI-processing infrastructure, PCI-DSS to isolation and access control plus a PCI scope assessment, and FedRAMP / sector cloud to the Gate's FedRAMP compliance gating for Critical-tier infrastructure in US federal or public-sector contexts.

C) Operate the provisioning gate and track foundational compliance outcomes. Run a single intake ticket queue with a published SLA (triage within 5 business days; fast-track provisional approval within 10 business days for Low-tier archetypes with no regulated data, no customer exposure, and no cross-border flows). The artifacts checklist is archetype-keyed, the platform engineer submitting intake receives the checklist for their archetype, and missing artifacts block production provisioning. Gate approval creates or updates the SM-Infrastructure inventory record with artifact links. The amnesty path is visibly linked from the intake form, the GPU AUP, and the platform engineering channel pins. Exceptions are logged with owner, rationale, and review date; no exception may remain open longer than 90 days without re-review. Cloud-provider DPA status, training-data posture for managed services, and residency configuration are confirmed at go-live rather than trusted from a marketing page.

Outcome Metrics (L1).

Success Criteria.

• Three priority policies (AI Infrastructure Standards, GPU / Accelerator AUP, AI Infra Intake / Provisioning Gate) published, approved by Legal/Privacy and Security, and communicated to all platform engineers and SREs.
• One-page priority compliance map published, covering EU AI Act Art. 15/12/Annex III, GDPR Art. 32/44–49/33, ISO/IEC 42001, ISO/IEC 27001 A.5/A.8, SOC 2 CC6/CC7/CC8, and applicable sector-specific obligations; linked from each policy.
• Provisioning gate operational with a per-archetype artifacts checklist, published SLA, and visible amnesty path.
• ≥95% of platform/SRE headcount has acknowledged the AI Infrastructure Standards AUP in the current year.
• ≥85% of AI/HAI infrastructure instances reaching production in the last 12 months passed the gate (100% for Critical/High-tier); every customer-facing or regulated-data-processing instance has a named infrastructure owner.

Maturity Level 2

Objective: Deepen policy controls and compliance evidence per AI/HAI infrastructure risk tier, assemble continuous compliance evidence bundles for Critical/High instances, and operationalize FedRAMP and regional compliance gating for applicable instances.

Activities.

A) Tier-calibrated policy depth and sign-off requirements. Extend the three L1 policies with tier-specific addenda using the SM-Infrastructure L2 tier rubric. Critical instances require a full SR pack with REM, CISO and VP Infrastructure sign-off before go-live, per-tenant isolation confirmation, FedRAMP or sector-equivalent compliance evidence for US federal or public-sector context before go-live, EU AI Act Art. 15 cybersecurity evidence assembled, GDPR Art. 32/44–49 residency and transfer basis confirmed, GPU fleet zero-standing-access confirmation, and mandatory re-review within 14 days on every material change (a new AI workload hosted, a new tenant, a new region, a new data class). High instances require a full SR pack plus REM with fast-track exemptions, CISO-delegated platform-security-lead sign-off, EU AI Act and GDPR assessments, isolation-posture confirmation, and re-review within 30 days on material change. Medium instances use a base SR pack plus REM with fast-lane DR (or a DR waiver for sanctioned reference-architecture implementations) and re-review annually or within 60 days on material change. Low instances use a base SR pack with a self-attested artifact checklist and re-review at annual review. Policy exceptions require a named owner, a compensating-control description, a Legal/platform-security reviewer acknowledgment, and an expiry date (max 12 months); Critical-tier instances have no amnesty for missing provisioning artifacts after L2 is established, missing artifacts become blocking findings routed through IM.

B) Continuous compliance evidence assembly and FedRAMP / regional compliance gating. For every Critical and High AI/HAI infrastructure instance, maintain a live compliance evidence bundle that auto-assembles the current TA snapshot, the SR REM with gap status and owner for each open gap, the SA reference-architecture confirmation or DR-approved deviation, the latest DR decision and date, the latest IR attestation or finding log where IR found drift, ST evidence (full battery last-run date, model-extraction resistance test, vector-store inversion test, orchestrator-scope test, GPU-fleet IAM test last-run dates), ML logging-baseline confirmation with last-validated date, the infrastructure-owner record (named accountable owner, data-residency declaration, Art. 32 / Art. 15 obligations checklist), and FedRAMP or sector-equivalent compliance evidence for applicable instances. Staleness rules trigger PC-Infrastructure findings routed to IM: for Critical instances, TA snapshot 90 days, IR attestation 6 months, ST evidence 30 days. The evidence bundle is the primary artifact a regulator or auditor receives when asking about a specific AI/HAI infrastructure instance.

C) Exception management, sector-specific bundles, and tier-aware enforcement. Integrate the exception register with the provisioning gate: no exception is approved without a tier-appropriate compensating control and an expiry. Monthly exception-aging review escalates exceptions more than 90 days past expiry to the program sponsor. Sector-specific evidence bundles are generated from the compliance evidence bundle for the instances they apply to, a HIPAA security-rule bundle for PHI-processing infrastructure, a PCI-DSS 12.8 bundle for cardholder-data-adjacent inference infrastructure, a FedRAMP bundle for US federal or public-sector infrastructure, and an ISO/IEC 27001 Annex A bundle, with completeness tracked per instance. Enforcement asymmetry holds: Critical-tier instances with missing provisioning artifacts are blocking findings, and no amnesty applies post-L2.

Outcome Metrics (L2).

Success Criteria.

• Three priority policies extended with tier-specific addenda; 100% of Critical instances carry CISO plus VP Infrastructure sign-off at provisioning in the last 12 months.
• Compliance evidence bundle live for every Critical/High instance; staleness inside tier-specific targets.
• Exception register comprehensive and reviewed monthly; zero exceptions past expiry un-escalated; Critical-tier missing provisioning artifacts treated as blocking findings.
• Sector-specific evidence bundles (HIPAA / PCI-DSS / FedRAMP as applicable) complete for in-scope instances.
• Regulatory or auditor inquiry evidence SLA (≤5 BD) met in the last 12 months.

Maturity Level 3

Objective: Automate compliance attestation from IaC, cloud-provider, and runtime telemetry; drive policy updates from monitoring signals and regulatory motion; and contribute to AI infrastructure standards development.

Activities.

A) Continuous compliance attestation from IaC and cloud-provider signals. Evidence bundles auto-update from IaC state events (Terraform plan and apply records carry artifact-checklist status), cloud-provider provisioning events (a new endpoint created auto-opens an intake check), Kubernetes admission webhook records (policy-as-code assertions on GPU workloads and serving deployments verified at admission), runtime configuration events (drift from the declared baseline opens a PC finding), ML logging-baseline validation events (log retention confirmed or failed), and model-registry promotion events (CI/CD pipeline-integrity evidence refreshed). The attestation-generation pipeline produces a provenance-complete evidence pack for any instance, regulation-keyed (an EU AI Act Art. 15 evidence pack, a GDPR Art. 32 processing-security pack, a SOC 2 CC6/CC7/CC8 evidence set, a FedRAMP evidence set) or instance-keyed, within 3 business days. The currency SLO is ≤24 hours latency after a triggering event; completeness is ≥99% of active Critical/High instances.

B) Telemetry-driven policy refresh and regulatory-motion tracking. Operate a quarterly policy-refresh cycle driven by ML-Infrastructure detection trends (which infrastructure misconfigurations are rising), IM-Infrastructure incident learnings (which policy gaps created the incident conditions), tier-movement data (which archetype classes are growing fastest and at what risk level), and external regulatory and standards updates (EU AI Act implementing acts, GDPR EDPB AI guidance, NIST AI RMF Playbook updates, FedRAMP revision cycles, and sector-specific guidance from HHS, the PCI SSC, the FedRAMP PMO, and sector cloud regulators). Refresh output is a versioned, dated changelog for each of the three policies approved by Legal and Security; EG-Infrastructure training content updates within 30 days of any policy change. A regulatory-motion tracker maintains a log of open regulatory instruments with expected effective dates mapped to the policy each will affect; the working group reviews it quarterly.

C) Standards contribution and external engagement. Participate in AI infrastructure standards and regulatory forums: the CNCF AI/ML Working Group, CNCF TAG Security, OpenSSF AI supply-chain security, the FinOps Foundation AI Infrastructure SIG, EU AI Act Art. 15 implementing-acts consultations, NIST AI RMF Playbook infrastructure-chapter working groups, the FedRAMP Emerging Technology Advisory Group, and sector regulators (HHS AI infrastructure guidance, PCI SSC AI guidance, sector cloud regulators). Contribute AI-infrastructure-specific artifacts to public standards, provisioning gate schemas, compliance evidence bundle templates, archetype-keyed policy-as-code assertions, and IaC module templates with embedded compliance guardrails, through CNCF, OpenSSF AI, the CSA AI Safety Initiative, and Shared Assessments. Target at least two substantive public comments or standards contributions per year on AI/HAI infrastructure policy and compliance topics.

Outcome Metrics (L3).

Success Criteria.

• On-demand attestation pack generation inside 3 business days for any active AI/HAI infrastructure instance; SLA met in the last 12 months.
• Continuous attestation pipeline operational with ≤24h currency SLO; completeness ≥99% of Critical/High instances.
• Quarterly telemetry-driven policy-refresh cycle operating with a versioned, externally-auditable changelog.
• ≥2 substantive public regulatory or standards contributions per year on AI/HAI infrastructure policy; external recognition documented.
• Zero material audit findings on AI/HAI infrastructure controls in the last 12 months.

Common Pitfalls

Level 1. - Reusing the generic cloud-hardening standard and change-management policy without AI-specific archetype clauses, no rule on GPU fleet IAM, no per-archetype inference-endpoint controls, no provisioning gate for vector stores; auditors cannot trace Art. 32 obligations to a control. - Provisioning gate applies only to new cloud deployments announced through a formal project, misses GPU workloads provisioned by researchers, vector stores stood up as database extensions, and orchestrators repurposed for AI without re-review. - Compliance map lists framework names but does not say which policy carries which regulation, an auditor asking how Art. 15 cybersecurity applies to an inference endpoint must trace it themselves and concludes coverage is untraceable. - Gate checklist is archetype-agnostic, an inference cluster and a vector store receive the same checklist, so cluster-specific controls (no-public-endpoint, model encryption) and vector-store controls (collection access control, inversion resistance) are never actually required.

Level 2. - Tier-specific addenda published but sign-off requirements never enforced, Critical-tier inference clusters ship with only the base L1 checklist because no one enforces the executive sign-off rule. - Compliance evidence bundle is a folder of PDFs only the compliance lead can navigate, a second reviewer cannot assemble the regulator pack without them. - Staleness thresholds exist on paper but no alert fires when exceeded, a Critical inference endpoint's TA snapshot ages past 90 days and nobody notices until an audit. - FedRAMP gating acknowledged in policy but the evidence-assembly process never built, the gate reads "FedRAMP required" but no checklist or evidence template exists and the requirement is bypassed silently.

Level 3. - Attestation pipeline generates evidence that is technically complete but narratively thin, a regulator still needs a human to explain what the IaC state records mean; the 3 BD SLO is met but a follow-up hearing is needed. - Policy refresh is cadence-only, a quarterly ritual without real telemetry input; the changelog reads like formatting updates and Legal cannot explain what incident prompted which change. - External regulatory contributions are deadline-only comment letters rather than technical artifacts (IaC templates, policy-as-code examples, evidence schemas) that standards bodies actually use. - Contributed policy-as-code templates and schemas are published once and then go stale, external practitioners find outdated IaC modules that miss current cloud-provider API changes and stop trusting the program.

Practice Maturity Questions

Level 1. 1. Have you published and formally approved the three priority AI/HAI infrastructure policies (AI Infrastructure Standards, GPU / Accelerator AUP, AI Infra Intake / Provisioning Gate) with per-archetype baselines, data-classification rules, and an infrastructure-owner requirement, and is there a one-page compliance map tying each priority requirement (EU AI Act Art. 15/12/Annex III, GDPR Art. 32/44–49/33, ISO/IEC 42001, ISO/IEC 27001 A.5/A.8, SOC 2 CC6/CC7/CC8, sector-specific) to the specific policy that carries it? Evidence: published policy set, approval signatures, and one-page compliance map. 2. Is the provisioning gate operational with a per-archetype artifacts checklist, a published intake SLA (triage ≤5 BD; provisional approval ≤10 BD for Low-tier), and an amnesty path, and does ≥85% of AI/HAI infrastructure reaching production in the last 12 months have a gate record (100% for Critical/High)? Evidence: intake queue export reconciled against SM-Infrastructure inventory. 3. Are ≥95% of platform/SRE headcount covered by a current-year AI Infrastructure Standards AUP acknowledgment, and does every customer-facing or regulated-data-processing AI/HAI infrastructure instance in production have a named infrastructure owner logged in SM-Infrastructure inventory? Evidence: LMS attestation report and inventory column showing infrastructure owners for affected instances.

Level 2. 1. Have the three priority policies been extended with tier-specific addenda (per the SM-Infrastructure L2 rubric), and do Critical instances carry explicit CISO plus VP Infrastructure sign-off at provisioning with a live compliance evidence bundle covering TA snapshot, SR REM, SA pattern confirmation, DR decision, IR attestation, ST evidence, ML logging-baseline, infrastructure-owner record, and FedRAMP / regional compliance evidence where applicable? Evidence: tier addenda, gate records showing dual sign-off, and a sample evidence bundle for a Critical instance. 2. Is the compliance evidence bundle continuously maintained for every Critical/High instance with staleness inside tier-specific targets, and can a regulatory or auditor inquiry be satisfied with provenance-complete artifacts within 5 business days? Evidence: evidence-registry staleness report and last inquiry-response log. 3. Is an exception register operated with named owners, compensating controls, and expiry dates, reviewed monthly, with Critical-tier missing provisioning artifacts treated as blocking findings (no amnesty), and sector-specific evidence bundles (HIPAA / PCI-DSS / FedRAMP as applicable) complete for in-scope instances? Evidence: exception register, monthly review minutes, and sector-bundle completeness report.

Level 3. 1. Does a continuous attestation pipeline auto-update evidence bundles from IaC state events, cloud-provider provisioning events, Kubernetes admission webhook records, and runtime configuration signals, with an attestation currency SLO of ≤24 hours latency and ≤3 BD on-demand pack generation, and is ≥99% of Critical/High instances continuously attested? Evidence: pipeline architecture, SLO dashboard, currency and completeness metrics. 2. Does the program operate a quarterly, telemetry-driven policy-refresh cycle (ML-Infrastructure detection trends + IM-Infrastructure incident learnings + regulatory-motion tracker + tier-movement data) with a versioned changelog where 100% of changes are traceable to a named signal or regulatory update? Evidence: most recent policy changelog with rationale entries citing telemetry or regulatory source. 3. Does the program contribute ≥2 substantive public comments or standards artifacts per year on AI/HAI infrastructure policy topics (CNCF, OpenSSF AI, FinOps Foundation, EU AI Act Art. 15 implementing guidance, NIST AI RMF Playbook, FedRAMP Emerging Technology, sector regulators) with documented external recognition? Evidence: contribution log with publication links and recognition citations.

16. Education & Guidance (EG)

Practice Overview

Objective: Build the AI-assurance literacy every platform engineer, SRE, and cloud architect touching AI/HAI infrastructure needs and the practitioner skills the smaller population performing infrastructure security reviews, IaC security assessments, and platform hardening of AI/HAI systems must have, with shadow AI infrastructure awareness as the primary L1 cultural outcome.

Description: EG-Infrastructure covers two audiences. The first is the platform and SRE workforce who provision, operate, and maintain the seven AI/HAI infrastructure archetypes (inference endpoints and model-serving clusters, model registries, GPU and accelerator fleets, orchestrator control planes, vector-store infrastructure, AI-specific CI/CD, feature stores and online serving caches); they need AI infrastructure literacy covering what the archetypes are, what GPU fleet operational risks mean for the workloads they manage, how IaC for AI differs from general-purpose IaC, what region and residency constraints apply to AI serving infrastructure, and how to provision observability-compliant infrastructure from the start. The second is the practitioner population, platform security engineers, SRE on-call leads, and cloud architects performing AI infrastructure security reviews in TA, DR, and IR, who need deep, hands-on skills covering inference-endpoint attack surface, model-registry attack surface, GPU-fleet IAM hardening, vector-store hardening, orchestrator control-plane security, AI-specific CI/CD pipeline attacks, IaC review patterns for AI infrastructure, and per-archetype security baseline verification.

Context: AI-specific infrastructure risks, model extraction at inference endpoints (ATLAS AML.T0015 / AML.T0024), model-registry tampering that injects malicious artifacts into the supply chain (ATLAS AML.T0010), GPU fleet IAM over-privilege enabling lateral movement to training data, vector-store inversion recovering sensitive content from embeddings, orchestrator control-plane compromise enabling EA/AGH/TM/RA at scale, and AI-specific CI/CD attacks that promote poisoned models to production (ATLAS AML.T0020), are not covered by classic cloud-hardening or CSPM curricula. A platform engineer who has only taken generic AWS/GCP/Azure hardening training will provision an inference cluster without thinking about model-extraction resistance; a cloud architect trained only on VPC security and IAM least-privilege will not recognize a vector-store namespace-boundary failure or an orchestrator tool-scope misconfiguration. Without a deliberate EG practice targeted at these gaps, AI infrastructure risk surfaces late, at model-extraction incident time, in external audits, or in regulatory reviews of Art. 15 cybersecurity obligations.

Maturity Level 1

Objective: Deliver foundational AI infrastructure literacy to ≥95% of the platform and SRE workforce touching AI/HAI infrastructure and role-based practitioner training to 100% of the reviewer population, with an active shadow-AI-infrastructure awareness campaign.

Activities.

A) Ship workforce AI infrastructure literacy training. A single short course (≤20 minutes) every platform engineer, SRE, and cloud architect touching AI/HAI infrastructure takes on hire and refreshes annually, tied to the AI Infrastructure Standards AUP attestation from PC-Infrastructure L1. This is not a comprehensive cloud-hardening course, it is the minimum AI infrastructure literacy needed to participate in the program without creating compliance exposure. Content covers what the seven AI/HAI infrastructure archetypes are with concrete examples from the org's own inventory and the AI/HAI software artifacts each archetype hosts; GPU fleet operational risk in plain terms (fleet credentials as high-value targets, training-data access scope as a blast-radius control, isolation between workloads on shared fleets, GPU-spend tagging as a shadow-infra detection signal, what happens when a researcher provisions GPU resources outside the sanctioned fleet); the three key differences between IaC for AI infrastructure and general IaC (model artifacts require signing or checksum, inference endpoints require auth at every interface, GPU workload isolation requires explicit namespace or VM-level controls in the IaC module) plus the most common AI-infra IaC misconfigurations and how to spot them in a pull-request review; region and residency for AI serving infrastructure (why a cross-border inference endpoint processing personal data triggers GDPR Art. 44–49, what residency means for a vector store indexed with user-generated content, the IaC attribute that pins a deployment to a declared region, how to flag a cross-border deployment in the intake form); observability minimums for AI workloads (the structured inference access logs every endpoint must emit, what an orchestrator state log captures, the difference between "logging enabled" and "logging-baseline compliant"); how the provisioning gate works (how to submit intake, what the per-archetype artifacts checklist requires, what provisional approval means, how the amnesty path works); and a shadow-AI-infra decision aid. Delivery is an LMS module plus a one-page reference card pinned in platform/SRE channels plus a brief at platform all-hands when the program launches; no role gating.

B) Deliver role-based practitioner training for the reviewer population. A deeper module (approximately 2 hours) for the practitioner population only, platform security engineers performing TA and SR intake reviews for AI infrastructure, SRE on-call leads responsible for AI infra incident response, and cloud architects reviewing AI infrastructure designs in DR. Completion is a prerequisite to approving infrastructure intakes. Content covers inference-endpoint attack surface (model-extraction techniques, ATLAS AML.T0015 ML Model Access and AML.T0024 Exfiltration via ML Inference API; prompt injection at the serving layer as an AGH vector; inference-access-log completeness as observability verification; no-public-endpoint enforcement at the IaC level; authentication-bypass patterns on serving APIs); model-registry attack surface (supply-chain compromise via the registry, ATLAS AML.T0010 ML Supply Chain Compromise; unsigned or unverified artifact promotion; how a two-party promotion gate prevents unilateral promotion; what a registry audit log should capture and how to verify it in an IR); GPU fleet IAM hardening (what "no standing human IAM on production GPU fleet" means at the AWS IAM, GCP IAM, and Azure RBAC level; secrets-vault integration for fleet credentials; training-data access scoping as a blast-radius control; GPU-spend anomalies as a shadow-infra detection signal); vector-store hardening (embedding inversion, how high-dimensional embeddings can reconstruct sensitive source content; namespace and collection boundary failures; what "no collection with public read access" means in Weaviate, Qdrant, and pgvector; TLS enforcement on client connections); orchestrator control-plane security (EA/TM/RA TTPs at the orchestrator level, a too-broad tool scope is an EA vector, a crafted workflow input that redirects orchestrator execution is an AGH vector, recursive tool invocation exceeding declared scope is a TM vector, and long-running agent sessions drifting from intended behavior in Temporal, Airflow, or LangGraph is an RA vector; how to assess tool-scope boundary in an SR REM; what control-plane authentication enforcement looks like in a DR review); AI-specific CI/CD attacks (model poisoning through the training pipeline, ATLAS AML.T0020 Poison Training Data; malicious model promotion via compromised CI/CD credentials; eval-gate bypass by manipulating threshold configuration; artifact-signing verification gaps; pipeline-credential vault gaps); IaC review patterns for AI infrastructure (a checklist-driven IaC review per archetype identifying which Terraform or Pulumi resource attributes indicate public endpoints, missing encryption, missing auth, missing isolation, or missing logging, and how to generate the SR REM gap list from an IaC review); the priority compliance map in practice (given an archetype, which requirements apply and where the evidence lives in the provisioning gate record); and a calibration exercise where three sample archetype intakes (a customer-facing inference cluster, a multi-tenant GPU fleet for training on confidential data, a cross-border vector store indexed with user-generated content) are scored independently with instructor-facilitated debrief. Delivery is an instructor-led or recorded workshop plus role-specific reference job aids (one per archetype) plus a quarterly calibration session; completion is gated on intake-approval permissions.

C) Run the shadow-AI-infrastructure awareness campaign. An always-on communications program that makes it uncomfortable to provision AI/HAI infrastructure outside the program and easy to surface it. Elements include a launch moment with the executive sponsor naming shadow AI infrastructure, announcing the amnesty window, and publishing the sanctioned-archetype catalog with explicit framing that the program is an enabler not a blocker; recurring monthly short content (a new archetype approved and available, a fast-track provisioning win such as intake-to-provisional in 3 BD for an internal vector store, an anonymized example of a risk caught during intake review, an external incident reframed as "what would we find if we checked our own GPU fleet or inference endpoints?"); an "Is this AI infra?" series calling out GPU workloads launched for side projects, inference endpoints added to Kubernetes without intake, and vector collections created for features in development; an amnesty path visibly linked from the GPU AUP, the intake form, and platform engineering channel pins; a feedback channel for platform engineers to nominate new archetype or IaC module patterns for the sanctioned catalog (triaged and acknowledged within 5 BD); and region/residency micro-content for teams deploying cross-border inference infrastructure. Campaign channel links are tagged so attribution of intake submissions and amnesty disclosures to campaign touchpoints is tracked.

Outcome Metrics (L1).

Success Criteria.

• Workforce AI infrastructure literacy module launched; ≥95% current-year completion sustained.
• Practitioner training launched, completion gated on intake-approval permissions, and reviewer calibration drift inside target for two consecutive quarters.
• Shadow-AI-infrastructure awareness campaign running with at least monthly content cadence and measurable attribution.
• Region/residency micro-content deployed for every cross-border or regulated-data-processing AI/HAI infrastructure archetype active in the inventory.
• Training content owner named; content updated within 30 days of any change to policies, the archetype list, or the compliance map.

Maturity Level 2

Objective: Deepen practitioner skill through scenario-based training from real infrastructure intake cases, deliver cloud-provider-specific tracks calibrated to SM-Infrastructure L2 risk tiers, and run seasonal shadow-AI-infra campaigns tied to provisioning cycles.

Activities.

A) Scenario-based reviewer training from real infrastructure intakes. Build a scenario library from anonymized real infrastructure intakes from the org's own provisioning queue; each scenario includes the as-submitted archetype description, the original reviewer decisions (tier, risk identifications, SR gaps), any reviewer disagreement, and the resolved outcome after calibration or post-deployment review. Organize scenarios per archetype (inference cluster, GPU fleet, orchestrator, vector store, AI CI/CD) and per risk cluster (model-extraction-exposure-heavy, IAM-over-privilege-heavy, tool-scope-violation-heavy, cross-border-transfer-heavy). Run paired calibration exercises in which two reviewers independently score the same scenario, with instructor-facilitated debrief on tier delta, risk-identification deltas, and SR gap-list differences. Weight curriculum to tier: Critical-tier customer-facing inference cluster and GPU-fleet-processing-regulated-data scenarios dominate the advanced modules while Medium and Low scenarios streamline fast-track calibration. Practitioners graduate the advanced module by running three live intakes end-to-end with a senior-reviewer shadow and producing a passing TA snapshot and SR REM for each archetype.

B) Cloud-provider-specific AI infrastructure tracks. Deliver distinct training tracks for platform and SRE teams operating AI/HAI infrastructure on each major cloud provider, not generic cloud-hardening tracks, but tracks covering the AI-specific services and their security configurations. The AWS track covers SageMaker endpoint security (auth, VPC-private serving, model encryption, inference access logs in CloudWatch), Bedrock provisioned-throughput security (IAM policies, VPC endpoints, CloudTrail audit), EKS GPU workload isolation, ECR image signing for ML base images, the SageMaker Model Registry two-party promotion gate, AWS Secrets Manager for fleet and endpoint credentials, and AWS PrivateLink for vector-store backends. The GCP track covers Vertex AI endpoint security (VPC Service Controls, IAM, Private Service Connect), GKE GPU node-pool isolation (node taints, namespaces, Workload Identity), the Vertex AI Model Registry promotion gate, Cloud KMS for model-artifact encryption, Secret Manager for fleet credentials, GCS bucket ACLs for training-corpus access scope, and Vertex AI Feature Store access control. The Azure track covers Azure OpenAI deployment security (managed identity, private endpoints, Azure Policy for no-public-access), Azure ML compute-cluster security (managed identity, network isolation, Key Vault credentials), AKS GPU node-pool isolation, Azure Container Registry image signing for ML images, Azure AI Search network isolation and RBAC, and Azure Key Vault for secrets. Each cloud-provider track is paired with the SA-Infrastructure reference architecture for the relevant cloud, the training teaches the green path the team will implement and defend in DR. Required for any team owning a Critical or High-tier infrastructure instance on the applicable cloud; target ≥1 trained practitioner per archetype instance.

C) Seasonal, behavior-driven shadow-AI-infra campaigns. Tie campaigns to observed shadow-infra risk windows in the provisioning cycle: large infrastructure provisioning windows (quarter-start GPU reservation cycles), Q1 OKR planning (teams add AI serving infrastructure to roadmaps without intake), hiring surges (new platform engineers arrive with cloud-account habits from prior employers), and post-external-incident moments (a public model-extraction or GPU-credential-leak incident creates a teachable window). Each campaign carries a pre-measured behavior target (for example, "reduce untagged GPU workloads in the AWS account by 50% in Q3" or "increase Critical-tier inference cluster intake submissions before sprint start by 30%") and a post-campaign measurement. Amnesty windows run alongside campaigns; disclosure volume and source are attributed to campaign channels. Campaigns missing behavior targets by more than 20% are redesigned by the program sponsor.

Outcome Metrics (L2).

Success Criteria.

• Scenario library of ≥30 real-sourced scenarios across archetypes; reviewer calibration drift inside target for two consecutive quarters.
• Cloud-provider-specific tracks (AWS, GCP, Azure as applicable) delivered; ≥1 trained practitioner per Critical/High-tier instance.
• ≥2 behavior-driven campaigns run in the last 12 months with measured outcomes; ≥70% of campaigns hit behavior target.
• Training content refresh cadence met; ≥80% of content updated in the last 90 days.

Maturity Level 3

Objective: Operate continuous calibration at scale, externalize the AI infrastructure assurance curriculum and reviewer rubric as industry-shared artifacts, and contribute to cloud-provider partner programs and emerging AI infrastructure security certification pathways.

Activities.

A) Externalize the curriculum, scenario library, and reviewer rubric. Publish the workforce AI infrastructure literacy module (learning objectives, GPU fleet operational-risk module, IaC-for-AI module, region/residency module, observability module, provisioning-gate workflow), the practitioner role-based training curriculum (module outlines, per-archetype attack-surface coverage, IaC review patterns, cloud-provider-specific hardening checklists, an ATLAS technique-coverage matrix), the anonymized scenario library (scenario format, per-archetype examples, calibration-debrief format), and the reviewer rubric (tier-assignment criteria, risk-identification scoring, SR-gap-list completeness scoring per archetype) under a permissive license or as a consortium deliverable through the CNCF AI/ML Working Group, OpenSSF AI supply-chain security, CNCF TAG Security, or applicable cloud-provider partner security programs. Accept community contributions; flow changes back into internal content within 30 days. Track adoption via citations in external publications, forks, downloads, and direct adoption acknowledgment from other organizations.

B) Continuous live calibration. Run monthly calibration rounds: a current anonymized infrastructure intake sampled from the program's live provisioning queue is shared with the reviewer cohort; each reviewer independently scores tier, risks, and the top three SR gaps; drift is reported to the program sponsor. Individual reviewer drift is a development signal, not a performance metric, reviewers with persistent drift on specific archetype types receive targeted coaching and additional scenario exposure. Calibration results feed the scenario library directly; new scenarios drawn from intakes where calibration revealed drift are added within 30 days.

C) AI infrastructure security certification contribution. Contribute to AI infrastructure and cloud security certification pathways as they emerge: CNCF Kubernetes and cloud-native security certifications, the OpenSSF AI Practitioner path, cloud-provider security partner programs (AWS Security Competency AI track, GCP Security Partner AI track, Microsoft MISA AI track), and ISACA AI Risk certificates where infrastructure scope is covered. Align the org's practitioner capstone with certification-grade rubrics where credentials exist; support reviewers pursuing external credentials. Contribute MITRE ATLAS new-technique candidates and confirmed-technique instances from own-operated AI/HAI infrastructure observations (inference-endpoint extraction, model-registry tampering, orchestrator control-plane compromise enabling EA/TM/RA), minimum one per year where novel observations exist. Target ≥2 substantive contributions per year to industry curriculum, certification working groups, or cloud-provider partner security programs.

Outcome Metrics (L3).

Success Criteria.

• Curriculum, scenario library, and reviewer rubric published externally (CNCF, OpenSSF AI, or cloud-provider partner programs) with documented adoption.
• Monthly live calibration operating; drift inside target for two consecutive quarters; calibration results feeding the scenario library continuously.
• ≥50% of Critical-tier reviewers credentialed where credentials exist.
• ≥2 substantive contributions to industry certification or curriculum per year.
• ≥1 MITRE ATLAS TTP contribution or confirmation per year where novel observations exist in own-operated AI/HAI infrastructure.

Common Pitfalls

Level 1. - Workforce training covers generic cloud hardening (VPC, IAM, encryption) but not AI infrastructure-specific risks, platform engineers know how to harden an EC2 instance but not how to prevent model extraction from an inference endpoint or embedding inversion from a vector store. - Practitioner training is a one-hour "intro to ML security" rather than a hands-on module covering per-archetype attack surfaces, IaC review patterns, ATLAS technique coverage, and calibration exercises against real intake examples. - Reviewer training is optional, intake-approval permissions granted without training completion; calibration drift is never measured, and two reviewers regularly arrive at different tiers for the same inference cluster. - Shadow-AI-infra campaign launches once with an exec message, then goes silent, no monthly content, no amnesty attribution, no feedback channel; platform engineers never hear about it again.

Level 2. - Scenario library built from invented examples rather than anonymized real infrastructure intakes, reviewers learn the shape of a "good" intake but not the actual misconfigurations the org's platform teams make. - Cloud-provider tracks are optional; platform teams skip them and produce IaC in DR that misses cloud-provider-specific AI security controls, and DR catches the gaps late and at high cost. - Campaigns launched without a pre-measured behavior target, "shadow AI infrastructure awareness" claimed as a success without data on whether untagged GPU workloads decreased or amnesty disclosures increased. - Calibration drift is measured but not acted on, reviewers with persistent drift on specific archetype types never receive coaching, and the calibration exercise becomes a box-check.

Level 3. - External publication without ongoing maintenance, other organizations find stale IaC review patterns and ATLAS coverage that no longer reflects current cloud-provider APIs, and citations dry up. - Credentialing becomes performative, reviewers pursue generic cloud security certifications that do not map to the org's AI-infra-specific tier-treatment rubric; credential acquisition is celebrated but calibration drift stays unchanged. - Live calibration becomes a gotcha rather than a development signal, reviewers learn to game the monthly exercise and improve their calibration scores without improving actual intake quality. - ATLAS contributions are aspirational but never actually submitted, the org observes novel inference-endpoint extraction or orchestrator-compromise patterns in own-operated infrastructure but does not complete the ATLAS submission process.

Practice Maturity Questions

Level 1. 1. Have all platform engineers, SREs, and cloud architects provisioning or operating AI/HAI infrastructure completed a current-year AI infrastructure literacy course covering the seven in-scope archetypes, GPU fleet operational risk, IaC-for-AI differences, region/residency for AI serving infrastructure, observability minimums, and the provisioning gate, with ≥95% completion and content updated within 30 days of any policy or archetype change? Evidence: LMS completion report, content change-log, and the most recent literacy module. 2. Has the practitioner population (platform security engineers, SRE on-call leads, cloud architects performing AI infrastructure reviews) completed role-based training covering inference-endpoint attack surface (ATLAS AML.T0015/AML.T0024), model-registry supply-chain attacks (ATLAS AML.T0010), GPU-fleet IAM hardening, vector-store hardening (embedding inversion), orchestrator control-plane security (EA/AGH/TM/RA TTPs), AI-specific CI/CD attacks, and IaC review patterns for all seven archetypes, with completion gated on intake-approval permissions and calibration drift ≤1 tier step and ≤2 risk misclassifications per sample for two consecutive quarters? Evidence: practitioner curriculum, permission-gating record, and calibration-exercise results. 3. Is a shadow-AI-infra awareness campaign running with at least monthly content, a visible amnesty path linked from the GPU AUP and intake form, and measurable attribution of intake submissions and amnesty disclosures to campaign channels, with disclosures rising in Q1–Q2 after launch then declining as the sanctioned-archetype program grows? Evidence: campaign content calendar, channel-attribution report, and amnesty disclosure trend.

Level 2. 1. Is there a scenario library of ≥30 anonymized real infrastructure intake cases powering practitioner training across the org's in-scope archetypes, with paired calibration exercises showing Critical-tier drift ≤1 tier step and ≤1 risk misclassification per sample for two consecutive quarters? Evidence: scenario library index and quarterly Critical-tier calibration drift report. 2. Have cloud-provider-specific engineering tracks (AWS, GCP, Azure AI infra as applicable) been delivered to ≥1 practitioner per Critical/High-tier infrastructure instance, with team-level training coverage tracked in the SM-Infrastructure inventory? Evidence: track rosters reconciled against the inventory's Critical/High instance list. 3. Are shadow-AI-infra campaigns running on a seasonal, behavior-driven cadence with pre-set behavior targets and post-campaign measurement, with ≥70% of campaigns hitting their target, and is ≥80% of training content updated in the last 90 days? Evidence: campaign plans with pre/post measurements and content-refresh changelog.

Level 3. 1. Has the practitioner curriculum, anonymized scenario library, and reviewer rubric been published externally (CNCF, OpenSSF AI, CNCF TAG Security, or cloud-provider partner security programs) with documented adoption, citations, forks, or direct acknowledgment, and do contributions loop back into internal content within 30 days? Evidence: external publication links, adoption telemetry, and internal update changelog. 2. Is a monthly live calibration cadence operating (anonymized infrastructure intake from the live provisioning queue, independent reviewer scoring, drift reported to sponsor), with calibration results feeding the scenario library within 30 days, and do ≥50% of Critical-tier reviewers hold an external AI infrastructure or cloud security credential where one exists? Evidence: calibration log, scenario-library update trail, and credential registry. 3. Does the program contribute ≥2 substantive artifacts per year to industry AI infrastructure security certification or curriculum working groups (CNCF, OpenSSF AI, cloud-provider partner programs), and ≥1 MITRE ATLAS TTP contribution or confirmation per year where novel observations exist in own-operated AI/HAI infrastructure? Evidence: contribution log with acceptance confirmations and the ATLAS submission record.

17. Threat Assessment (TA)

Practice Overview

Objective: Build and maintain a reusable threat library for the infrastructure that hosts and serves the organization's AI/HAI systems, one archetype-level threat model per infrastructure asset type, so every infrastructure asset entering the SM inventory carries a documented threat view before it is provisioned, connected to AI workloads, or exposed to external traffic.

Description: TA-Infrastructure catalogs the threats specific to the infrastructure the organization operates to host and serve AI/HAI systems, not generic cloud-infrastructure threats, but the failure modes specific to inference endpoints, model registries, GPU/accelerator fleets, orchestrator control planes, vector-store infrastructure, AI-specific CI/CD pipelines, and feature stores. At L1 the library covers one threat model per infrastructure archetype mapped to HAIAMM's HAI-specific TTPs (EA, AGH, TM, RA), to MITRE ATLAS tactics and techniques, and to the HAIAMM Cloud Threat Taxonomy (HCT: BadCode, BadAction, BadPrincipal, BadPermissions). Each new infrastructure asset registered in SM's inventory generates a threat snapshot by pulling the archetype model and adding asset-specific deltas, specific tenant configuration, specific workload classification, specific network placement. L2 layers per-asset deep models for Critical-tier assets with cloud-tactic walks and quarterly red-team cycles. L3 automates library maintenance from telemetry and external feeds, and contributes discovered TTPs back to MITRE ATLAS, AVID, CNCF AI working groups, and OpenSSF AI.

Context: Classic infrastructure threat modeling was not designed to enumerate AI-specific failure modes, cross-tenant GPU residual-state leakage, model-artifact tampering in a registry, orchestrator workflow injection that redirects agent execution, inference-API flooding that degrades serving quality for all tenants, training-job hijack that plants a backdoor in a shared accelerator fleet. These are first-party infrastructure risks owned by the platform and MLOps teams that provision and operate the substrate on which AI systems run. TA-Infrastructure closes the gap by making infrastructure-asset-specific threats a first-class library, tied to both ATLAS tactic IDs and HCT threat roots so the walk from attacker capability to infrastructure exposure is concrete and cloud-native, and so cloud-IAM standing risks that ATLAS does not enumerate are not silently dropped from the threat picture.

Maturity Level 1

Objective: Build the AI/HAI infrastructure archetype threat library, integrate a threat snapshot into every infrastructure asset intake, and ensure every asset's threat surface is documented before it is connected to AI workloads.

Activities.

A) Build the AI/HAI infrastructure archetype threat library. Author one threat model per AI/HAI infrastructure archetype. Each archetype model is concise (target two pages), explicitly scoped to infrastructure assets the organization operates to host and serve AI systems, and maps threats to HAI TTPs, ATLAS tactic and technique IDs, HCT entries, and the PC-Infrastructure priority compliance map. Archetypes to cover at L1, drawn from the SM-Infrastructure inventory schema: inference endpoint / model-serving cluster, the network-exposed endpoint that puts a model behind production traffic; model registry, the versioned artifact store holding model weights, metadata, lineage records, and promotion history; GPU / accelerator fleet, the pool of GPU or accelerator instances used for training, fine-tuning, and high-throughput inference, frequently shared across workloads or tenants; orchestrator / control plane, the workflow engine, agent orchestration platform, or MLOps control plane that coordinates training jobs, agent steps, tool invocations, and pipeline execution; vector-store infrastructure, the vector database, embedding index, and ingest pipeline backing RAG retrieval; AI-specific CI/CD, the training pipeline, eval-gate, model-promotion workflow, and deployment automation specific to AI artifacts; feature store / online serving cache, the low-latency feature-serving layer bridging offline feature engineering and online prediction. Per-archetype threat content names the inference-endpoint abuse cluster, model extraction via inference API (ATLAS AML.T0024, HAI-TTP TM, HCT.BadAction high-velocity inference calls), denial-of-service and prompt-flood (TA0040 ML Attack Staging into TA0014 Impact), cross-tenant isolation breach (HCT.BadPermissions / HCT.BadCode), lateral movement from a compromised endpoint workload identity into the registry or training stores (HAI-TTP EA, TA0007 Privilege Escalation, HCT.BadPrincipal / HCT.BadPermissions), and silent model swap past the eval gate (TA0006 Persistence); the model-registry tampering cluster, unauthorized model upload (AML.T0010 ML Supply Chain Compromise, TA0003 Initial Access), post-upload artifact tampering, credential theft for registry access, and deletion or rollback abuse; the GPU-fleet cluster, cross-tenant residual-state leakage on shared GPUs (TA0010 Collection), scheduler abuse co-locating hostile workloads, training-job hijack producing a backdoored model (AML.T0020, HAI-TTP RA), and GPU-firmware persistence (TA0006); the orchestrator cluster, orchestrator credential abuse (HAI-TTP EA, TA0008 Credential Access), workflow injection that executes attacker logic under the pipeline's trusted identity (HAI-TTP AGH, AML.T0051 analog), agent-state tampering that redirects an agent's subsequent actions (HAI-TTP AGH/RA), and control-plane API abuse (HAI-TTP TM, TA0009 Discovery); the vector-store cluster, unauthorized corpus read, embedding extraction at scale, indexer abuse seeding prompt-injection payloads for all future retrievals (HAI-TTP AGH, AML.T0051), and retrieval-policy bypass enabling cross-tenant bleed; the CI/CD cluster, training-pipeline supply-chain compromise (AML.T0010), poisoned-dependency injection, model-promotion bypass and eval-gate spoofing (TA0008 Defense Evasion), and build-time SSRF reaching cloud metadata endpoints (HCT.BadCode); and the feature-store cluster, feature poisoning (HAI-TTP RA, AML.T0020), online/offline-skew abuse, and unauthorized feature read. Each archetype model walks the HCT four roots explicitly so standing-IAM risks (HCT.BadPermissions wildcard policies, long-lived keys, over-broad service principals) that ATLAS does not enumerate are surfaced. Owner: a named TA-Infrastructure library steward; cadence: reviewed quarterly; versioned in a single location linked from every SM inventory record.

B) Produce a per-intake threat snapshot for every SM inventory registration. Bind TA into the SM intake flow, every new infrastructure asset registration emits a threat snapshot before Sanctioned status is issued; Provisional-status assets receive a snapshot within five business days of registration. Snapshot contents, designed to fit one screen: which archetype(s) apply, an asset may be composite, such as an inference endpoint backed by a GPU fleet serving a vector-store RAG pattern; asset-specific deltas over the archetype model covering the workload tier hosted (Critical / High / Medium / Low per SM-Infrastructure L2), the multi-tenancy isolation model, the customer-exposure level, the data classification of hosted workloads, geographic scope, and any decision-affecting use; the top-five threats for this asset, each with a HAI TTP tag, an ATLAS tactic ID, an HCT entry naming the BadCode / BadAction / BadPrincipal / BadPermissions root, and compliance linkage; controls already evident from the design versus gaps for SR/SA follow-up; and reviewer name, date, and expiry. Re-snapshot triggers: workload-tier change, new tenant onboarded, network topology change, or major platform version upgrade. Time target: one business day per intake with the library available. Most threat content comes pre-written in the archetype model; the reviewer adapts rather than invents.

C) Author the shadow-AI-in-infrastructure threat view. Shadow AI infrastructure, unsanctioned GPU instances spun up for experimentation, model registries created outside the governed platform, inference endpoints deployed from personal cloud accounts, has its own threat surface distinct from sanctioned assets. The shadow-AI-in-infrastructure threat document covers entry vectors (untagged GPU/TPU instances in cloud spend, model-serving endpoints outside the monitored namespace, unsanctioned artifact registries in cloud accounts, training jobs submitted through personal credentials rather than governed service accounts); elevated threats for shadow assets (no threat model, no SR requirements pack, no REM, no eval gate, EU AI Act Art. 26 deployer-duty evidence trail unmet because the asset is unknown to the program); and detections available at L1 from SM discovery sources (cloud-spend signals for untagged GPU/TPU usage and unexpected API endpoints, DNS and network signals for outbound traffic from compute to model-hosting domains outside the allow-list, IAM signals for personal credentials used for model API calls). Output: a "Shadow AI in Infrastructure, Threat View" one-pager reviewed by the program sponsor and feeding the ML-Infrastructure detection backlog and the IM-Infrastructure triage playbook.

Outcome Metrics (L1).

Success Criteria.

• Seven archetype threat models published (inference endpoint, model registry, GPU/accelerator fleet, orchestrator/control plane, vector-store infra, AI-specific CI/CD, feature store), each tagged to HAI TTPs (EA/AGH/TM/RA), ATLAS tactic IDs, HCT threat roots (BadCode/BadAction/BadPrincipal/BadPermissions), and the PC-Infrastructure priority compliance map.
• Threat snapshot gate live in the SM intake flow, 100% of newly Sanctioned AI/HAI infrastructure assets in the last 90 days have a snapshot attached.
• Shadow-AI-in-infrastructure threat view published, reviewed by the program sponsor, and feeding the ML-Infrastructure detection backlog.
• Named library steward and quarterly refresh cadence operating.
• ≥90% of active AI/HAI infrastructure assets in the inventory carry a current-year snapshot.

Maturity Level 2

Objective: Layer per-asset deep threat models on top of archetype snapshots for Critical-tier infrastructure assets, integrate external AI infrastructure threat intelligence, and red-team the threat library quarterly against real in-scope assets.

Activities.

A) Per-asset deep threat modeling for Critical-tier assets. For every Critical-tier infrastructure asset in the SM inventory, produce a full per-asset threat model that goes beyond the archetype snapshot. Coverage: a cloud-tactic walk using the per-cloud TM template (AWS / GCP / Azure), all ATLAS tactics enumerated for the specific cloud platform, cloud-native techniques from the HCT taxonomy mapped to the asset's IAM posture, network placement, and workload configuration; an HCT four-root deep analysis for the specific asset enumerating BadCode, BadAction, BadPrincipal, and BadPermissions risks in the current configuration and identifying standing-IAM risks (HCT.BadPermissions.*) that ATLAS does not enumerate but that represent significant exposure; an abuse-case catalog with named adversary archetypes (external attacker, malicious insider, compromised CI/CD runner, compromised vendor supply chain) and concrete attack narratives for this specific asset; and deployer-duty mapping covering EU AI Act Art. 26 obligations and Art. 15 accuracy/robustness/cybersecurity requirements for the workloads the asset hosts. High-tier assets receive the archetype snapshot plus asset-specific deltas and a full cloud-tactic walk; no High-tier asset remains on archetype-only. Refresh cadence: Critical semi-annual plus change-driven on platform upgrade, new tenant onboarding, network topology change, or tier reclassification; High annual plus change-driven.

B) External AI infrastructure threat intelligence integration. Subscribe to and operationalize MITRE ATLAS updates for techniques relevant to ML infrastructure, AVID infrastructure-related vulnerability entries, CNCF AI security working group advisories on Kubernetes AI workload security and container isolation, OpenSSF AI supply-chain advisories for ML dependencies and model formats, cloud-provider security bulletins for AI-hosting services (SageMaker, Vertex AI, Azure ML, Bedrock, EKS/GKE/AKS), and academic and practitioner publications on GPU security, hardware side-channels, and orchestrator-level vulnerabilities. A quarterly triage cadence determines which new items change the archetype library, change per-asset models, or require updates to dependent SR or ST artifacts. Changes are change-logged and reviewed by the library steward and the IM backlog owner. Intel-to-library update lead time targets 30 days on Critical-impact items.

C) Red-team the threat library itself. Each quarter, ST-Infrastructure runs an adversarial probe against an in-scope AI/HAI infrastructure asset using only the threat scenarios documented in the library for that archetype. Threats the exercise identifies that are not in the library are library gaps, not passing findings. Gap closure is a governance activity: every gap becomes a ticket with a named owner and an expiry date; Critical-tier gaps close within 30 days, High-tier within 60 days. The gap rate per quarter trends down as the library matures. Gaps are also reviewed for SR and ST update implications, a threat absent from the library is also likely absent from a requirement and a test.

Outcome Metrics (L2).

Success Criteria.

• Per-asset deep threat models live for 100% of Critical-tier and ≥90% of High-tier assets, with refresh cadences met and cloud-tactic walks using the per-cloud TM templates.
• External threat intel integrated with quarterly triage and documented change-log; intel-to-library update ≤30 days on Critical-impact items.
• Quarterly red-team-the-library exercise operating; every gap carries a named owner and expiry date; Critical-tier gaps close within 30 days.

Maturity Level 3

Objective: Automate threat-library maintenance from telemetry and external feeds, and contribute discovered AI/HAI infrastructure TTPs back to MITRE ATLAS, AVID, CNCF AI, and OpenSSF AI.

Activities.

A) Telemetry-driven library updates. Wire ML-Infrastructure detection alerts, IM-Infrastructure post-incident review records, external feeds (ATLAS technique additions, AVID new entries, CNCF AI security advisories, OpenSSF AI bulletins, cloud-provider security bulletins), and GPU and hardware security publication scanning into an auto-proposal pipeline. Alert patterns that do not map to any existing library entry are surfaced as candidate new threats. Human curators approve, reject, or defer each auto-proposal. The change-log is machine-readable; downstream SR, SA, and ST artifacts subscribe to the change feed and receive update-required notifications when a threat they reference changes. Target: ≥60% of library changes auto-proposed; lead time from signal to update ≤14 days.

B) Industry contribution. Contribute emerging first-party-observed TTPs, attack patterns discovered in own-operated AI infrastructure such as GPU residual-state variants, orchestrator injection mechanics, and inference-API exfiltration patterns, to MITRE ATLAS following ATLAS evidence-and-provenance requirements; to AVID via structured disclosure submissions for newly discovered infrastructure vulnerabilities; to CNCF AI working groups as security guidance for AI workload isolation in Kubernetes and threat models for AI-specific admission control and namespace isolation; and to OpenSSF AI as supply-chain security input on ML pipeline dependencies, model artifact signing, and build provenance. Target: at least four substantive contributions per year, quality-graded and legally vetted before submission, every contribution anonymized.

C) Shared threat-model artifacts. Publish anonymized archetype threat models (scrubbed of org-specific tenant names, cloud-account identifiers, and data classes) under a permissive license for peer-org adoption. Host or co-host at least one industry tabletop per year tied to the library, an ATLAS practitioner table, CNCF AI security working group, OpenSSF AI chapter, or cloud-provider ISAC AI working group.

Outcome Metrics (L3).

Success Criteria.

• Library auto-update pipeline operating with ≤14-day lead time from signal to update; ≥60% of changes auto-proposed.
• ≥4 industry contributions per year; ≥2 recognized in external artifacts (ATLAS merge, AVID entry, CNCF or OpenSSF AI guidance).
• Anonymized archetype threat models published under permissive license with tracked peer-org adoption.
• Industry tabletop hosted or co-hosted in last 12 months.

Common Pitfalls

Level 1. - Threat models describe "the AI" as the actor performing security work rather than the infrastructure asset as the subject being assessed, the library catalogs what AI tools do rather than what threats face the infrastructure the org operates. - The archetype library treats all seven infrastructure archetypes as variations of "cloud compute", GPU-specific threats (residual-state leakage, firmware persistence, scheduler abuse) and orchestrator-specific threats (workflow injection, agent-state tampering) are not separately enumerated. - HCT threat roots are not walked alongside ATLAS, standing-IAM risks (HCT.BadPermissions) and identity misuse (HCT.BadPrincipal) are missed because ATLAS does not enumerate them, leaving the snapshot incomplete for cloud-native threats. - The shadow-AI-in-infrastructure threat view is omitted because "all compute is provisioned through IaC", the entry vector for untagged GPU instances and personal-credential model deployments is never modeled.

Level 2. - The per-asset deep model is the archetype snapshot with the asset name swapped in, no cloud-tactic walk, no HCT four-root analysis, no asset-specific IAM posture review; the depth is cosmetic. - External intel is subscribed but never triaged, cloud-provider security bulletins pile up unread while GPU-firmware CVEs and orchestrator-level vulnerabilities accumulate; the library is frozen at L1 publication. - The red-team-the-library exercise is a penetration test that adds findings to a finding log but never cross-checks them against the library, gaps are never surfaced because the comparison was never made. - Deep modeling stops at Critical tier; High-tier assets such as shared GPU fleets hosting regulated training workloads remain on archetype-only snapshots.

Level 3. - The auto-proposal pipeline accepts signals without curation, false-positive ML-Infrastructure detections pollute the library with phantom threats; downstream SR and ST artifacts generate incorrect requirements and tests. - Contributions to ATLAS/AVID/CNCF/OpenSSF are observer submissions, conference talks, mailing-list comments, rather than technical artifacts with evidence that produce substantive change. - Published anonymized archetype models are not maintained after release, external adopters build on a stale version while the internal library advances; the divergence becomes visible when discrepancies are cited publicly. - The telemetry-driven update loop fires on every routine infrastructure change, overwhelming the curation queue, platform teams disable the telemetry feed rather than tune signal sensitivity.

Practice Maturity Questions

Level 1. 1. Are there published, versioned threat models for all seven AI/HAI infrastructure archetypes, inference endpoint, model registry, GPU/accelerator fleet, orchestrator/control plane, vector-store infra, AI-specific CI/CD, feature store, each mapping archetype-specific threats to HAI TTPs (EA/AGH/TM/RA), ATLAS tactic and technique IDs, HCT threat roots (BadCode/BadAction/BadPrincipal/BadPermissions), and PC-Infrastructure compliance items, with a named library steward and a documented quarterly refresh cadence? Evidence: TA library with seven versioned archetype documents and a named owner record. 2. Does every AI/HAI infrastructure asset entering the SM inventory receive a threat snapshot (delivered within one business day of intake) that documents the applicable archetype(s), asset-specific deltas (workload tier hosted, multi-tenancy isolation model, customer-exposure, data classification, geographic scope), top-5 threats with HAI TTP tags, ATLAS tactic IDs, and HCT roots, and gaps for SR/SA follow-up, with 100% of newly Sanctioned assets carrying a snapshot in the last 90 days? Evidence: SM intake tickets with snapshot attachments dated within intake SLA. 3. Is there a published shadow-AI-in-infrastructure threat view, reviewed by the program sponsor in the last 12 months, that documents entry vectors (untagged GPU instances, unsanctioned registries, personal-credential-based model deployments), elevated threat scenarios for unreviewed infrastructure assets, and the specific detections used to surface them? Evidence: Dated threat view document with program-sponsor review record and links to ML-Infrastructure and IM-Infrastructure backlogs.

Level 2. 1. Does every Critical-tier AI/HAI infrastructure asset have a current-year per-asset deep threat model covering a cloud-tactic walk using the per-cloud TM template, a full HCT four-root analysis for the asset's current IAM posture and network placement, an abuse-case catalog with named adversary archetypes, and deployer-duty mapping, with a semi-annual refresh cadence and change-driven updates on platform upgrade, new tenant onboarding, or network topology change? Evidence: Per-asset threat model documents dated within cycle, with change-driven update records. 2. Is external AI infrastructure threat intel (MITRE ATLAS updates, AVID, CNCF AI security advisories, OpenSSF AI, cloud-provider security bulletins) integrated with a quarterly triage cadence and a documented change-log, with intel-to-library update ≤30 days on Critical-impact items? Evidence: Quarterly triage meeting records and change-log entries with signal-to-update timestamps. 3. Do you run a quarterly red-team-the-library exercise that probes an in-scope AI/HAI infrastructure asset using only library threats and surfaces misses as library gaps, with every gap carrying a named owner and expiry date, Critical gaps closing within 30 days, and the gap rate trending down quarter over quarter? Evidence: Quarterly exercise artifacts with gap register showing owner assignments and closure dates.

Level 3. 1. Does the threat library auto-update from telemetry (ML-Infrastructure detections, IM-Infrastructure incidents) and external feeds (ATLAS, AVID, CNCF, OpenSSF AI, cloud-provider bulletins) via a human-curated auto-proposal pipeline, with ≥60% of changes auto-proposed, a ≤14-day lead time from signal to update, and a machine-readable change-log consumed by downstream SR and ST practices? Evidence: Pipeline telemetry showing proposal rate and lead-time distribution; SR/ST subscription confirmation. 2. Does the program contribute at least four substantive, evidence-backed technical artifacts per year to MITRE ATLAS / AVID / CNCF AI / OpenSSF AI, with at least two externally recognized in published advisory, standard revision, or community guidance? Evidence: Contribution log with external recognition citations. 3. Are anonymized archetype threat models published under a permissive license with tracked peer-org adoption, and does the program host or co-host at least one industry tabletop per year (ATLAS practitioner table, CNCF AI security working group, OpenSSF AI chapter, or cloud-provider ISAC AI working group) tied to the library? Evidence: License artifact, adoption tracking data, tabletop event record.

18. Security Requirements (SR)

Practice Overview

Objective: Translate the threats from TA-Infrastructure and the policies from PC-Infrastructure into a reusable Requirements Pack for the infrastructure that hosts and serves AI/HAI systems, a base set plus per-archetype deltas, so every infrastructure asset carries a testable Requirements-Evidence Map rather than a blank slate, and so Software-domain REMs can link directly to the Infrastructure REM of the hosting cluster.

Description: SR-Infrastructure authors a small, archetype-keyed AI/HAI Infrastructure Requirements Pack: one base requirement set that applies to every infrastructure asset hosting AI workloads, plus per-archetype deltas for inference endpoint, model registry, GPU/accelerator fleet, orchestrator/control plane, vector-store infrastructure, AI-specific CI/CD, and feature store. Each requirement is stated as a testable condition, either a measurable SLA or a binary evidence condition, not a narrative aspiration. Every infrastructure asset reaching SM intake carries a Requirements-Evidence Map (REM) linking each applicable pack requirement to current evidence, accepted gaps (with a named owner and expiry date), and compensating controls. A Software-domain artifact's REM references the Infrastructure REM of the cluster that hosts it, the two are linked, not duplicated. Downstream practices, SA, DR, IR, ST, inherit the REM rather than re-deriving requirements per asset.

Context: Without a shared infrastructure requirements pack, each platform security review, cloud architecture review, and MLOps compliance check invents the acceptance bar from scratch. GPU residual-state clearing, registry write-list enforcement, orchestrator workflow signing, and inference-endpoint rate-limiting are not consistently verified because there is no shared traceability from threat to requirement to evidence artifact. EU AI Act Art. 26 deployer duties, Art. 9 risk management, and ISO/IEC 42001 AIMS controls are hand-waved in narrative rather than traced to specific infrastructure controls. SR-Infrastructure closes that gap with the minimum viable pack, not a checklist of 60 items, but the 20-ish requirements that matter for every AI infrastructure asset the org operates, plus archetype-specific additions for GPU fleets, orchestrators, model registries, and inference endpoints.

Maturity Level 1

Objective: Publish the AI/HAI Infrastructure Requirements Pack (base plus per-archetype deltas), wire it into the SM intake gate, and produce a Requirements-Evidence Map for every infrastructure asset hosting AI workloads.

Activities.

A) Author the base AI/HAI Infrastructure Requirements Pack. The base pack applies to every AI/HAI infrastructure asset the org operates to host or serve AI systems, regardless of archetype. Keep it to 20 or fewer base requirements at L1. Each requirement has an ID, a statement, a rationale (threat tag from TA-Infrastructure and compliance tag from PC-Infrastructure), an evidence source, a test method, and an acceptance criterion. Minimum base categories: identity and authentication, workload-identity-only access for all service principals that interact with AI infrastructure with no long-lived access keys, JIT elevation for human administrator access with no standing administrative access to inference endpoints, registries, GPU schedulers, or orchestrator control planes, MFA on all human console access, and service-to-service authentication via workload identity federation; isolation, per-tenant network isolation for multi-tenant AI infrastructure, per-workload namespace isolation in Kubernetes-hosted workloads with network policies, and per-classification-tier isolation placing Critical-tier workloads on dedicated nodes, all verified through documented conformance checks rather than assumed from IaC declarations; encryption, encryption at rest with cloud KMS for all AI artifact stores, encryption in transit with mTLS or TLS 1.2+ for service-to-service communication, per-tenant key separation, and a documented and enforced key-rotation schedule; region and data-residency enforcement, region pinning for assets handling personal data or operating under a regulatory jurisdiction, and cross-region data-transfer gates for High/Critical data; observability, inference-endpoint, model-registry, GPU-scheduler, orchestrator, feature-store, and CI/CD logs forwarded to the SIEM and retained to meet the longest applicable regulation, with admin-audit events, identity events, metrics, and traces captured; patch and image hygiene, signed container images and model artifacts rejected by the admission controller if unsigned, an approved base-image policy, and a vulnerability remediation SLA (Critical CVE 14 days, High 30 days, Medium 90 days); quotas, rate limits, and abuse detection, per-consumer rate limits on inference endpoints, per-tenant GPU/TPU quotas, and an abuse-detection layer for model-extraction probes and prompt-flood signatures with alerts routed to IM-Infrastructure; backup, recovery, and RTO/RPO, model-registry and vector-store contents backed up with tier-appropriate recovery objectives and integrity tested quarterly; failure-mode design, documented degraded-mode operation for provider outage, registry unavailability, and GPU-capacity exhaustion, plus a kill-switch or circuit-breaker at the inference-endpoint and orchestrator layers; and disclosure, where the infrastructure hosts customer-facing AI/HAI features subject to EU AI Act Art. 50, the logging and metadata capabilities support the Art. 26 deployer-duty evidence trail, with this requirement linking to the Software-domain REM. Every base requirement is tagged to at least one TA-Infrastructure archetype threat and at least one item from the PC-Infrastructure priority compliance map.

B) Author per-archetype requirement deltas. Each archetype carries a short delta (three to eight additional requirements) reflecting the threat-specific obligations from TA-Infrastructure's archetype threat models. The inference-endpoint delta covers per-consumer and per-tenant authentication with no unauthenticated endpoints, enforced per-consumer rate limits and abuse detection, model-version pinning so a caller cannot be silently moved to a different model, request/response metadata logging with PII redaction, region-pinned serving, and signed-artifact-only admission. The model-registry delta requires workload-identity-only writes restricted to a named write-list, signed artifacts at push time, lineage tracked back to the training job, classification-based access control with a review-approval record before production promotion, and an immutable append-only promotion log. The GPU/accelerator-fleet delta requires workload-namespace isolation with network policies, a verified GPU residual-state clearing mechanism between every job on shared hardware, dedicated nodes for Critical-tier workloads as a binary requirement, scheduler-side data-classification awareness enforcing node affinity, and an egress allow-list on all training and inference namespaces. The orchestrator/control-plane delta requires signed workflow definitions verified before execution, workflow-step authentication under step-specific principals, a per-step principal enforced as immutable for the run, agent-state-backend encryption with a tenant-specific key, and an authenticated, rate-limited, audited control-plane API. The vector-store delta requires per-tenant index partitioning, classification labels per chunk with classification-based retrieval access control, authenticated query access with no anonymous retrieval, and query-pattern observability with anomalous-pattern alerting. The AI-specific CI/CD delta requires signed pipeline definitions, SLSA-style provenance attestation for model and dataset artifacts, the eval gate as a non-bypassable required check, an enforced promotion policy, and a secrets vault for all pipeline-step credentials. The feature-store delta requires offline/online-skew monitoring with alerting, authenticated and minimally-scoped feature reads, feature-lineage tracking, and a documented and tested rollback procedure for feature poisoning.

C) Wire the pack into the SM intake gate and establish cross-domain REM linkage. Every infrastructure asset approved for use carries a REM. Each applicable pack requirement is marked Met, Met-with-compensating-control, Gap-accepted, or Not-applicable with justification. Each Met row cites specific evidence: an IaC configuration reference, an admission-controller policy, a secrets-scanner CI result, a GPU isolation conformance test result, a SIEM log-forwarding confirmation, a backup test record, a kill-switch test result, or a signed-image attestation. Each Gap-accepted row names a compensating control, a named owner, a re-review date (maximum 90 days at L1), and the residual-risk rationale accepted by the named sponsor. The REM is stored with the SM inventory record for the infrastructure asset and linked from the intake ticket. Cross-domain REM linkage: when a Software-domain artifact's REM is authored, the Software REM references the Infrastructure REM of the hosting cluster for base infrastructure categories (identity, isolation, encryption, observability, patch hygiene) rather than re-auditing those controls independently, the Software REM row references the Infrastructure REM row, which references the evidence artifact, eliminating redundant evidence collection. Material changes, new tenant onboarded, network topology change, platform major version upgrade, workload-tier reclassification, trigger REM re-review before the change takes effect.

Outcome Metrics (L1).

Success Criteria.

• Base pack plus seven archetype deltas published, tagged to TA-Infrastructure threats and the PC-Infrastructure priority compliance map.
• 100% of new AI/HAI infrastructure assets approved in the last 90 days have a REM on file.
• ≥90% of active AI/HAI infrastructure assets in the SM inventory carry a current-year REM.
• Named pack owner and quarterly refresh cadence operating.
• Cross-domain REM linkage operational, Software REMs reference Infrastructure REMs for base categories.
• Accepted-gap backlog tracked with every gap carrying a named owner and re-review date; median age inside ≤90 days.

Maturity Level 2

Objective: Replace qualitative requirements with quantitative, SLA-bound, and binary-evidence conditions; calibrate the requirements pack per risk tier; validate REM evidence continuously for Critical and High-tier infrastructure assets; and operate the IR-Infrastructure feedback loop.

Activities.

A) Quantitative and binary requirement pack. For every requirement in the base pack and each archetype delta, replace qualitative language with measurable or binary conditions. GPU residual-state clearing: binary, a documented clearing mechanism (device reset, memory zeroing, or equivalent) is verified to run between every job on shared GPU hardware, with last conformance test date and result on file and the mechanism tested quarterly. Workload-identity-only access: binary, zero long-lived access keys associated with any service account or managed identity that can reach model-registry write operations, training-data stores, or orchestrator management APIs, confirmed by the last IAM audit scan with zero key-bearing service principals in scope. Signed model artifacts: binary, the inference endpoint's admission hook rejects model artifacts lacking a signature from a key on the approved signing-key list, with zero unsigned artifacts served in production in the last 90 days. Inference-endpoint rate limits: measurable, a per-consumer rate limit enforced at a defined threshold, with a load test or canary confirming the limit fires before serving-cluster CPU utilization exceeds a defined threshold. SIEM log-forwarding completeness: measurable, ≥99% of inference-endpoint, model-registry, and orchestrator audit events reach the SIEM within five minutes of generation, with the completeness metric collected daily and an SLA breach generating a P1 alert. GPU dedicated-node isolation for Critical: binary, zero Critical-tier workloads scheduled on nodes shared with Medium or Low workloads, confirmed by a scheduler-output audit over the last 30 days. Kill-switch: binary, an emergency-halt mechanism at the inference-endpoint and orchestrator layers tested quarterly, with halt-to-full-stop achieved in ≤5 minutes from invocation. Backup recovery: measurable, model-registry and vector-store recovery procedures tested at least quarterly, with the last test completing recovery within the defined RTO and data loss within the defined RPO.

B) Per-tier requirement depth. Publish a per-tier pack overlay aligned to the SM-Infrastructure L2 tier-treatment matrix. Critical tier: full base pack and all applicable archetype deltas; dedicated-node isolation enforced by scheduler policy; named-sponsor sign-off on the completed REM before Sanctioned status is issued; full REM with no rows left blank; accepted-gap aging SLA of 60 days maximum before mandatory escalation to the program sponsor; EU AI Act Art. 26 deployer-duty checklist as a discrete appendix to the REM; re-validation of all Critical-tier REM evidence quarterly; an IR-Infrastructure auto-revalidation cadence in which every IR finding for a Critical-tier asset triggers a full REM re-validation run within five business days. High tier: full base pack and applicable archetype deltas; accepted-gap aging SLA of 90 days; re-validation of REM evidence semi-annually; IR findings trigger targeted REM row re-validation. Medium tier: base pack and applicable archetype deltas; accepted-gap aging SLA of 120 days; re-validation annually. Low tier: base pack only; fast-track process with abbreviated evidence citations acceptable; re-validation at annual review.

C) Continuous REM-evidence validation and IR feedback loop. Critical-tier REMs are re-validated quarterly; High-tier semi-annually. Validation method: select a stratified sample of REM rows per asset, at least one row per base category, and verify each cited evidence artifact against current observable reality: re-run the IAM audit and confirm zero long-lived keys; re-run the GPU residual-state clearing conformance test and confirm the mechanism is operational; query the admission controller and confirm zero unsigned-image exceptions; query the SIEM log-completeness metric and confirm the ≥99% forwarding SLA is met; re-run the kill-switch test and confirm the ≤5-minute halt. Validation deltas, a row claimed Met but evidence fails re-validation, are routed to IM-Infrastructure as findings with severity tags and remediation SLAs matching the asset's tier. Accepted-gap aging is reviewed monthly; gaps approaching the escalation threshold notify the named owner before the deadline. The IR-Infrastructure feedback loop is active: every IR finding for a requirement covered by the pack generates a REM row re-review flag, and the finding is not closed until the REM row reflects the current state.

Outcome Metrics (L2).

Success Criteria.

• 100% of pack requirements carry a quantitative or binary evidence condition; all qualitative language removed.
• ≥95% of Critical-tier REMs re-validated against observed reality in the last 90 days; validation deltas routed to IM-Infrastructure.
• No Critical-tier accepted gap open beyond 60 days without documented escalation to the program sponsor.
• 100% of Critical-tier assets carry full EU AI Act Art. 26 deployer-duty checklist evidence in their REM.
• IR-Infrastructure feedback loop operational; ≥90% of IR findings trigger a REM row re-review within five business days.

Maturity Level 3

Objective: Express the AI/HAI Infrastructure Requirements Pack as a machine-readable artifact, automate REM-evidence validation from IaC attestation and runtime signals, and contribute to industry-standard AI infrastructure security requirements bodies.

Activities.

A) Machine-readable pack and IaC attestation at deploy. Express the Requirements Pack (base plus archetype deltas) in a structured schema, JSON or YAML, where each requirement has an ID, a machine-readable evidence type (iac-config-check, log-query, test-result-reference, runtime-signal, or manual-attestation), an acceptance predicate, and a tier applicability field. At IaC deploy time for Critical and High-tier assets, automated checks run against the asset's REM: workload-identity-only access confirmed via IAM audit, signed-image policy confirmed via admission-controller configuration, SIEM forwarding confirmed via the log-completeness signal, GPU isolation confirmed via scheduler-policy configuration, and the kill-switch mechanism confirmed via a test result within a defined age. Checks that pass write a signed attestation to the REM record; checks that fail block the deploy for Critical-tier assets and emit a warning with auto-routing to IM-Infrastructure for High-tier. Infrastructure REM attestations are published as machine-readable artifacts that Software-domain CI/CD pipelines can reference, a software artifact's CI/CD gate can verify that its hosting cluster's Infrastructure REM is currently passing before the software deploy proceeds.

B) Automated REM-evidence validation from runtime signals. Subscribe the REM validation pipeline to ML-Infrastructure monitoring (log-completeness signal, GPU isolation conformance signal, rate-limit enforcement signal), IM-Infrastructure incident records (post-incident reviews touching a pack requirement auto-flag the relevant REM rows for re-validation), and SM inventory change events (a tier upgrade auto-triggers a full REM re-validation run under the new tier's requirements depth). Human review is reserved for novel requirement types not yet in the structured schema, accepted-gap escalations, and asset-specific clauses outside the standard archetype deltas.

C) Standards contribution. Contribute the machine-readable infrastructure requirement schema to CNCF AI working groups alongside Kubernetes AI workload isolation requirements and GPU namespace isolation practices; submit supply-chain security requirements for AI CI/CD pipelines, SLSA-compatible provenance for model artifacts, and signed-artifact policy for ML registries to OpenSSF AI; submit practitioner commentary grounded in REM experience to the NIST AI RMF Playbook MEASURE and MANAGE function requirement language; and submit concrete, testable AI infrastructure security requirements as candidate clause language to ISO/IEC 27090 or equivalent AI security standards successor work. Target: at least two substantive contributions per year, legally vetted and anonymized.

Outcome Metrics (L3).

Success Criteria.

• Machine-readable pack schema published; ≥80% of Critical-tier REM requirements have IaC attestation at deploy time.
• ≥70% of REM evidence rows auto-validated; human review reserved for exceptions and novel clauses.
• Zero Critical-tier assets deploying to production with a failing REM check; the IaC gate confirmed enforcing.
• ≥70% of Critical/High Software-domain CI/CD gates referencing the Infrastructure REM attestation.
• ≥2 substantive industry-standard contributions per year.

Common Pitfalls

Level 1. - The base pack is authored with 40+ requirements at L1, reviewers cannot complete a REM in three business days and begin skipping rows, producing REMs that are structurally complete but evidentially hollow. - GPU residual-state clearing is in the GPU-fleet delta on paper, but the evidence source is "team asserts it is configured", no conformance test, no test date, no result; the control is nominal. - Cross-domain REM linkage is discussed in documentation but never wired, Software REMs re-audit all infrastructure categories independently; duplicate reviews consume reviewer bandwidth and produce inconsistent findings. - The material-change trigger is not defined, new tenants onboarded, platform major version upgrades, and workload-tier reclassifications ship without triggering a REM re-review; the REM drifts from the actual asset configuration within weeks.

Level 2. - Quantitative conditions are set too loosely to be testable, "GPU residual-state clearing runs between jobs" becomes a documented policy on paper but is never confirmed against actual scheduler or device-driver configuration. - REM re-validation is scheduled quarterly for Critical-tier but samples only what engineers self-report, IAM audit, scheduler-output review, admission-controller query, and SIEM completeness metrics are never cross-referenced. - The IR-Infrastructure feedback loop exists in policy but IR findings never reach the REM, the finding is closed in the IR tracker while the REM row still says Met despite the finding demonstrating the control is absent. - Per-tier differentiation is documented in the pack overlay but not enforced at intake, every asset receives the same review depth regardless of tier.

Level 3. - The machine-readable pack schema is published but the organization stops maintaining the public version, external adopters build on a stale version while the internal version has advanced. - IaC attestation covers deploy-time config checks but not post-deploy drift, a GPU isolation policy that passes at deploy time is modified six weeks later with no detection while the pipeline still shows "passed." - Software-domain CI/CD gates declare they reference the Infrastructure REM attestation, but the reference is a static link to a past attestation record, the Software deploy proceeds without verifying that the Infrastructure REM is currently passing. - Standards contributions are submitted to working groups with no active AI infrastructure security track, they appear in the contribution log but have no path to adoption.

Practice Maturity Questions

Level 1. 1. Is there a published, versioned AI/HAI Infrastructure Requirements Pack containing a base set of 20 or fewer requirements plus seven per-archetype deltas, with every requirement tagged to at least one TA-Infrastructure archetype threat and one PC-Infrastructure priority-compliance item, and are reviewers selecting from the pack rather than drafting requirements per asset at intake? Evidence: Pack document with ID-tagged requirements, quarterly refresh record, and named pack owner. 2. Do 100% of new AI/HAI infrastructure assets approved in the last 90 days have a completed REM on file, with every applicable requirement marked Met, Met-with-compensating-control, Gap-accepted, or Not-applicable, each Met row citing specific verifiable evidence (IaC config reference, conformance test result, IAM audit output, SIEM completeness metric), each Gap-accepted row naming a compensating control, owner, and re-review date, and material-change triggers defined? Evidence: SM intake tickets with attached REM artifacts; gap register with owner and expiry fields populated. 3. Is cross-domain REM linkage operational, with Software-domain REMs referencing the Infrastructure REM of their hosting cluster for base infrastructure categories (identity, isolation, encryption, observability, patch hygiene) rather than re-auditing those controls independently, and is the pack on a quarterly refresh cadence with a named owner? Evidence: Cross-domain REM linkage telemetry; quarterly refresh records; named owner record.

Level 2. 1. Do 100% of pack requirements carry a quantitative or binary evidence condition, with every SLA (vulnerability remediation days, GPU clearing conformance cadence, SIEM completeness percentage, kill-switch response time, RTO/RPO) and every binary state (workload-identity-only access, signed-artifact enforcement, dedicated nodes for Critical tier, rate limits verified) specified, and has all qualitative "reasonable" and "appropriate" language been removed from the pack? Evidence: Pack document with no instances of qualitative acceptance language. 2. Are ≥95% of Critical-tier REMs re-validated against observed reality (IAM audit, GPU isolation conformance test, signed-image admission-controller query, SIEM completeness metric, kill-switch test) in the last 90 days, with validation deltas routed to IM-Infrastructure and no Critical-tier accepted gap aging beyond 60 days without documented escalation to the program sponsor? Evidence: Validation log with timestamps; gap register with escalation records. 3. Is the IR-Infrastructure feedback loop operational, with ≥90% of IR findings for requirements covered by the pack triggering a REM row re-review within five business days, and the finding not closed until the REM row reflects the current state, and is the per-tier pack overlay enforced at SM intake? Evidence: IR-to-REM linkage telemetry; SM intake routing log showing tier-differentiated processing.

Level 3. 1. Is the AI/HAI Infrastructure Requirements Pack expressed in a machine-readable schema and enforced via IaC attestation at deploy time, with ≥80% of Critical-tier requirements having automated checks, zero Critical-tier assets deploying to production with a failing REM check, and the schema published under a permissive license with tracked external adoption? Evidence: IaC pipeline attestation log; zero-failure production deploy record; external adoption tracking. 2. Are ≥70% of REM evidence rows auto-validated via IaC, runtime monitoring (ML-Infrastructure), and SIEM signal ingestion, with ≥70% of Critical/High Software-domain CI/CD gates referencing the Infrastructure REM attestation to verify hosting-cluster compliance before the software deploy proceeds? Evidence: Validation telemetry showing auto-vs-manual split; cross-domain pipeline telemetry. 3. Does the program contribute at least two substantive artifacts per year (machine-readable requirement schema, IaC attestation framework, Kubernetes AI workload isolation requirements) to recognized standards bodies (CNCF AI, OpenSSF AI, NIST AI RMF Playbook, ISO AI security standards work), with contributions publicly documented and traceable to adoption? Evidence: Contribution log with public links to accepted or in-progress submissions.

19. Secure Architecture (SA)

Practice Overview

Objective: Publish the reference architectures for safely hosting and serving each AI/HAI infrastructure archetype the organization operates, so platform and MLOps teams have a vetted green path that already implements SR-Infrastructure requirements and contains the threats identified by TA-Infrastructure.

Description: SA-Infrastructure ships a catalog of reference patterns, one per AI/HAI infrastructure archetype, showing how to establish identity, isolate tenants, encrypt data at rest and in transit, log activity, enforce region pinning, sign artifacts, and implement kill-switch and fallback mechanisms for infrastructure that hosts AI systems. Each pattern covers scope, identity and auth model, traffic path and isolation controls, logging specification, controls mapped to SR-Infrastructure requirements, and threats mitigated, tagged to HAI TTPs (EA/AGH/TM/RA), MITRE ATLAS mitigation IDs, and the HCT threat roots addressed. The catalog is accompanied by an anti-pattern list derived from real incidents and from first-party post-incident reviews. Teams use the reference pattern as the starting point; deviations require design review. At L2, patterns are encoded as IaC modules and cover multi-region, multi-tenant, and per-tier complexity calibrated to SM-Infrastructure L2's tier-treatment matrix. At L3, patterns are published as open artifacts adopted by CNCF AI working groups and OpenSSF AI, and MITRE ATLAS mitigation library entries are proposed from pattern controls.

Context: Without reference patterns, every platform team provisioning an inference endpoint, a model registry, a GPU fleet, or an orchestrator control plane makes the same architectural missteps, inference endpoints without per-tenant authentication, model registries with world-readable write access, GPU fleets without residual-state clearing between jobs, orchestrator control planes without signed workflow definitions, vector stores without per-tenant index partitioning, CI/CD pipelines with hardcoded registry credentials. The downstream cost is design reviews that repeat the same finding set and incidents that replay avoidable anti-patterns. SA-Infrastructure makes the secure path the default path, not by blocking MLOps, but by publishing a pre-vetted architecture for each archetype so platform teams reach for the pattern first.

Maturity Level 1

Objective: Publish reference architectures per AI/HAI infrastructure archetype and an anti-pattern catalog derived from real incidents; link each pattern to SR-Infrastructure requirements and TA-Infrastructure threats.

Activities.

A) Publish reference architectures per AI/HAI infrastructure archetype. Publish one pattern per archetype the org actually operates. Each pattern is concise (target three pages), includes a labeled architecture diagram, and covers a consistent skeleton: scope (what the pattern covers and explicitly does not); identity and auth model (workload identity for service principals, JIT elevation for human admin access, no long-lived keys, per-tenant token scoping); isolation model (per-tenant network isolation, per-workload namespace isolation, per-classification-tier node isolation for Critical workloads); traffic path (ingress and egress controls, allowlisted destinations, API-gateway or load-balancer placement, mTLS or TLS 1.2+ enforcement); logging specification (events logged, retention period, SIEM forwarding, exportability for regulatory requests); controls mapped row-by-row to SR-Infrastructure requirements with gaps acknowledged; and threats mitigated (which TA-Infrastructure archetype threats the pattern addresses, which remain residual, HAI TTP tags, applicable MITRE ATLAS mitigation IDs, and HCT threat roots addressed). All seven archetype reference patterns ship at L1. The inference-endpoint pattern uses workload-identity-backed serving with no long-lived API key, per-tenant authentication on every inference consumer, mTLS between the API gateway and serving cluster, a rate-limit and abuse-detection layer at the gateway, metadata-only request/response logging with PII redaction, region-pinned deployment, signed-artifact-only admission, and a canary deployment with a tested rollback playbook; threats mitigated include model extraction via inference API (HAI-TTP TM, AML.T0024, ATLAS TA0013 Exfiltration mitigated by rate limiting and abuse detection), cross-tenant isolation breach, silent model swap (TA0006 Persistence mitigated by signed artifacts and version pinning), and denial-of-service / prompt flood. The model-registry pattern enforces workload-identity-only writes restricted to an eval-gate-passed write-list, signed artifacts at push time, lineage tracked back to the training job, classification-based access control with a promotion-log approval record, an immutable append-only promotion log, and minimum-scope read access; threats mitigated include unauthorized model upload (AML.T0010, TA0007 Privilege Escalation mitigated by write-list enforcement), model-artifact tampering, credential theft, and deletion/rollback abuse, with TA0006 Persistence mitigated by signed artifacts and lineage. The GPU/accelerator-fleet pattern enforces workload-namespace isolation with network policies, GPU residual-state clearing between jobs conformance-tested quarterly, dedicated nodes for Critical-tier workloads via node affinity, scheduler-side data-classification awareness, and an egress allow-list on all training and inference namespaces; threats mitigated include cross-tenant residual-state leakage (HAI-TTP RA, TA0010 Collection mitigated by residual-state clearing and namespace isolation), scheduler abuse, training-job hijack, and GPU-firmware persistence (TA0006 Persistence reduced by dedicated nodes). The orchestrator/control-plane pattern enforces signed workflows verified before execution, workflow-step authentication under step-specific principals, an immutable per-step principal, agent-state-backend encryption with a tenant-scoped key, and an authenticated, rate-limited, audited control-plane API; threats mitigated include orchestrator credential abuse (HAI-TTP EA), workflow injection (HAI-TTP AGH, AML.T0051 analog mitigated by signed workflows), agent-state tampering, and control-plane API abuse, with TA0007 Privilege Escalation mitigated by the per-step principal. The vector-store pattern enforces per-tenant index partitioning with namespace-scoped retrieval, classification labels per chunk with classification-based access control, authenticated query access, query-pattern observability, and ingest-time injection defense against a prompt-injection canary list; threats mitigated include unauthorized corpus read, embedding extraction at scale (AML.T0024), indexer abuse (HAI-TTP AGH), and retrieval-policy bypass, with TA0010 Collection mitigated by per-tenant partitioning. The AI CI/CD pattern enforces signed pipeline definitions, SLSA-style provenance for model and dataset artifacts, the eval gate as a non-bypassable required check, an enforced promotion policy requiring named-reviewer sign-off for Critical-tier artifacts, a secrets vault for all credentials, and dependency pinning and scanning; threats mitigated include training-pipeline supply-chain compromise (AML.T0010, TA0003 Initial Access), poisoned-dependency injection, model-promotion bypass and eval-gate spoofing (TA0008 Defense Evasion), and build-time SSRF. The feature-store pattern enforces offline/online-skew monitoring with a human review gate, workload-identity-scoped minimum-feature-set access, feature-lineage tracking, and a documented and tested rollback procedure invocable without the compromised serving layer; threats mitigated include feature poisoning (HAI-TTP RA, AML.T0020 analog mitigated by skew monitoring and rollback), online/offline-skew abuse, and unauthorized feature read.

B) Publish the anti-pattern catalog. Name, describe, and prohibit AI/HAI infrastructure architectural patterns that reliably produce incidents. Each entry includes a description, why it is dangerous, real-incident flavor (industry or first-party), and the reference pattern element that replaces it. The L1 set covers: shared GPUs for regulated workloads (regulated training jobs co-scheduled with unrelated workloads on shared GPU nodes, residual state accessible to a subsequent tenant, replaced by GPU-fleet dedicated-node isolation and residual-state clearing); world-readable model registry (public-read or all-authenticated-users access lets any credentialed principal pull model weights, replaced by scoped read access and workload-identity-only writes); unsigned model artifacts in production (no mechanism to detect tampering between registry push and serving, replaced by signed artifacts and admission-hook signature verification); control-plane API without auth (the orchestrator management API reachable without authentication lets a network-adjacent principal trigger runs or exfiltrate secrets, replaced by an authenticated, rate-limited, audited API); vector store without per-tenant partitioning (a single-namespace retrieval store returns one tenant's chunks to another and exposes classified content to lower-privilege consumers, replaced by per-tenant index partitioning and classification-based access control); CI/CD with hardcoded credentials (registry tokens or cloud credentials embedded in pipeline files or container images, replaced by a secrets vault); inference endpoint without rate limits (a model-extraction probe or compromised consumer can exhaust GPU capacity or reconstruct model weights, replaced by a rate-limit and abuse-detection layer); and long-lived admin credentials for registry and orchestrator (a credential compromised on a developer laptop yields durable access to production AI infrastructure, replaced by workload-identity-only access and JIT human admin elevation).

C) Integrate patterns into the intake/inventory flow and establish the deviation-review path. SM inventory records link to the applicable reference pattern(s) at intake. Teams choosing an archetype see the reference pattern and declare "using pattern" or "deviating from pattern." Deviations require a lightweight design review (DR-Infrastructure L1) with a named architect reviewer and a documented rationale stored with the asset's inventory record. Patterns are reviewed and change-logged quarterly; repeat deviations in the same direction signal the need to update the pattern rather than continue approving exceptions. New archetypes that do not fit an existing pattern trigger a pattern-authoring sprint within 30 days of the first intake.

Outcome Metrics (L1).

Success Criteria.

• Seven reference patterns published, one per archetype, each with a labeled architecture diagram, scope declaration, identity and auth model, isolation spec, traffic path, logging spec, and row-by-row mapping to SR-Infrastructure requirements and TA-Infrastructure threats with HAI TTP tags, applicable MITRE ATLAS mitigation IDs, and HCT threat roots addressed.
• Anti-pattern catalog published with at least eight entries, linked from the AI Acceptable Use Policy, the SM intake gate, and EG-Infrastructure training.
• Deviation-review path operational with a named architect-reviewer population and ≤5 business day SLA.
• ≥85% of active AI/HAI infrastructure assets in the SM inventory classified as "on pattern" or "deviation with review"; no silent deviations.
• 100% of inference endpoints and model registries with workload-identity-only access confirmed by IAM audit, no long-lived API keys in service principals.

Maturity Level 2

Objective: Extend reference patterns to multi-region, multi-tenant, and per-tier complexity calibrated to SM-Infrastructure L2's tier-treatment matrix; encode patterns as IaC modules with conformance test suites; update the anti-pattern catalog from IM-Infrastructure incidents.

Activities.

A) Tier-conditional pattern extensions. Publish extended pattern variants calibrated to SM-Infrastructure L2's tier-treatment matrix. The Critical-tier overlay (applicable to any archetype at Critical tier) adds dedicated-node isolation IaC provisioning a tainted dedicated node group with scheduler-enforced node affinity, kill-switch IaC providing infrastructure-level process termination for the inference endpoint and orchestrator control plane tested quarterly with the result written to the REM, a data-residency enforcement variant with region pinning at the API-gateway and networking layers and a GDPR Art. 44–49 international-transfer mechanism selection step as a required decision gate in the IaC module, EU AI Act Art. 9 and Art. 15 controls explicitly mapped in the pattern, and a technical-documentation artifact template auto-populated from the IaC module to support Art. 11 documentation duties. The High-tier overlay adds monitoring and logging IaC modules pre-wired with the SIEM log-forwarding pipeline for inference-endpoint, model-registry, GPU-scheduler, orchestrator, and vector-store events, standard ML-Infrastructure L2 detections, and alert routing. The multi-region pattern covers region pinning at the API-gateway layer, cross-region failover with residency preservation, and GDPR international-transfer legal-basis confirmation as a required step. The multi-tenant pattern covers per-tenant namespace isolation at the Kubernetes, network, and storage layers, per-tenant KMS keys for model artifacts and vector-store data, per-tenant IAM scope for service principals, and a tenant-isolation conformance test wired into CI. The per-tier IaC modules, Critical-tier inference endpoint, Critical-tier model registry, Critical-tier GPU fleet, Critical-tier orchestrator, each ship as a forkable IaC module with a conformance test suite.

B) Patterns-as-IaC with conformance test suites. Encode all Critical and High-tier pattern variants as forkable IaC modules, Terraform, Pulumi, Helm, or equivalent, so teams fork rather than handcraft, and deviations surface at plan or apply time. Each IaC module ships with a conformance test suite: automated checks that the deployed asset matches the pattern's controls (workload-identity-only access confirmed, signed-artifact admission hook present, GPU residual-state clearing configured, SIEM forwarding active, per-tenant partitioning enforced for multi-tenant assets, rate-limit layer active for inference endpoints). IaC modules are version-pinned; module updates trigger a drift-detection pass against all deployed instances. A module change log is maintained; teams consuming a module are notified of updates requiring remediation.

C) Incident-informed anti-pattern catalog refresh. Every IM-Infrastructure incident is classified to an anti-pattern (existing or new); the classification is recorded in the IM finding. The catalog is refreshed monthly from IM-Infrastructure findings; new anti-patterns are surfaced to teams at intake time rather than stored only in a reference document. Quarterly review: if three or more assets have deviated from a pattern in the same direction, the pattern is queued for update rather than continued exception approval. Anti-patterns originating from Critical-tier incidents are escalated to the SM working group for a pattern-update sprint within 30 days.

Outcome Metrics (L2).

Success Criteria.

• Five tier-conditional extended patterns published (Critical overlay, High overlay, multi-region, multi-tenant, per-tier IaC modules), each encoded as a forkable IaC module with a conformance test suite.
• ≥80% of Critical and High-tier AI/HAI infrastructure assets running on IaC-encoded patterns with plan-time deviation flagging.
• Anti-pattern catalog updated from ≥3 real IM-Infrastructure incidents in the last 12 months; new entries surfaced at intake time.
• Conformance test coverage at 100% of IaC-encoded asset deployments.
• 100% of Critical-tier assets with EU AI Act Art. 9 and Art. 15 controls explicitly mapped in the pattern documentation.

Maturity Level 3

Objective: Publish infrastructure reference patterns as open industry artifacts; contribute pattern-derived mitigations to MITRE ATLAS; engage CNCF AI working groups, OpenSSF AI, and regulators on architecture norms for AI/HAI infrastructure.

Activities.

A) Publish reference patterns as open artifacts. Publish patterns under Apache 2.0 or equivalent via CNCF AI working groups, OpenSSF AI, CSA AI Safety Initiative, or equivalent body; route sector-specific variants through relevant sector bodies (FS-ISAC, H-ISAC, sector AI working groups). Maintain the public repository as the upstream source; internal use aligns with the external version; internal deviations are documented with rationale and fed back as upstream proposed changes rather than silent forks. Track pattern adoption telemetry: GitHub forks, citations in published work, documented adopters. New archetypes or overlays developed internally are proposed for inclusion in the external catalog within 90 days of internal publication.

B) Contribute to MITRE ATLAS mitigation library. For each control in the reference patterns that corresponds to a threat technique in the ATLAS taxonomy, propose or validate a mitigation entry in the ATLAS mitigation library (AML.M00xx). Priority contributions align to SA-Infrastructure's primary ATLAS tactics: TA0006 Persistence (signed artifacts, version pinning, residual-state clearing, immutable promotion log), TA0007 Privilege Escalation (workload-identity-only access, per-step principal, per-tenant partitioning), and TA0008 Defense Evasion (eval-gate enforcement, signed pipeline definitions, conformance testing). Target at least two AML.M00xx entries proposed or validated per year, contributions traceable to specific SA-Infrastructure pattern controls. Participate in the ATLAS practitioner community to align SA-Infrastructure control vocabulary with ATLAS technique taxonomy.

C) Engage regulators, CNCF, and OpenSSF on architecture norms. Participate actively in the CNCF AI working group, contribute the GPU isolation pattern, orchestrator signing pattern, and vector-store partitioning pattern as practitioner input to AI workload security guidance for Kubernetes. Submit the AI CI/CD pattern (signed pipeline definitions, SLSA provenance, eval-gate enforcement) as a practitioner contribution to OpenSSF AI supply-chain security guidance. Participate in EU AI Act implementing-act consultations where architecture standards for high-risk AI systems are under discussion, submitting SA-Infrastructure patterns as evidence of state-of-the-art architectural practice under Art. 9 and Art. 15. Contribute to ISO/IEC 42001 AIMS community guidance on architecture documentation, engage NIST AI RMF Playbook successor editions with SA-Infrastructure pattern mappings, and engage sector regulators with sector-relevant pattern variants, seeking inclusion in sector architecture guidance documents.

Outcome Metrics (L3).

Success Criteria.

• ≥5 reference patterns published as open artifacts under a recognized open license via at least one industry body (CNCF AI, OpenSSF AI, CSA, or equivalent).
• ≥2 patterns externally cited or forked by recognized industry or sector bodies.
• ≥2 MITRE ATLAS AML.M00xx mitigation entries proposed or validated, traceable to SA-Infrastructure pattern controls, aligned to TA0006, TA0007, and TA0008.
• Internal practice 100% aligned to the published external version; all deviations proposed as upstream contributions, none silently forked.
• At least one documented regulatory or standards-body reference to SA-Infrastructure patterns in implementing-act, guidance, or standards text.

Common Pitfalls

Level 1. - Patterns are written but not linked from the SM inventory record or the intake gate, platform teams skip them because they are hard to find, not because they disagree with them. - The GPU-fleet pattern mentions residual-state clearing but gives no implementation guidance (device reset vs. memory zeroing vs. namespace teardown), teams interpret "clearing" as whatever is cheapest, which may not actually prevent residual-state leakage. - The model-registry pattern requires signed artifacts but the inference-endpoint pattern omits the admission-hook signature-verification requirement, unsigned artifacts still reach serving without triggering a violation. - Anti-patterns remain theoretical, not tied to real incidents or to the specific pattern element that replaces them, so engineers do not recognize the hazard when they encounter it.

Level 2. - IaC patterns are forked once and then hand-edited at each deployment, drift is immediate and the IaC substrate provides no baseline enforcement; conformance tests are skipped because they block the fastest path to production. - Tier-conditional patterns exist in documents but the IaC modules do not enforce the tier-specific controls, the Critical overlay exists on paper; deployed Critical-tier assets lack dedicated-node isolation IaC or kill-switch infrastructure. - The multi-region pattern covers residency in the diagram but omits the GDPR international-transfer mechanism selection step, teams deploy cross-region inference pipelines without a documented legal basis. - The per-tier GPU-fleet IaC modules enforce node affinity at provisioning time but do not wire the residual-state clearing mechanism, nodes are dedicated, but clearing is absent and cross-tenant residual-state risk persists.

Level 3. - Externally contributed patterns diverge from internal practice, what is published reflects what the org once did; external adopters discover the discrepancy during implementation and trust erodes. - ATLAS contribution targets are treated as a compliance checkbox, entries are proposed but never followed through to publication because internal legal or security review creates indefinite delay. - Regulatory engagement is declaratory ("we participated in the consultation") rather than substantive ("our pattern text was incorporated into the guidance"), the program cannot demonstrate that engagement produced outcomes. - Industry contributions are conference presentations and blog posts; no technical artifacts actually land in MITRE, CNCF, or OpenSSF AI, external recognition is aspirational.

Practice Maturity Questions

Level 1. 1. Are seven reference patterns published, one per archetype (inference endpoint, model registry, GPU/accelerator fleet, orchestrator/control plane, vector-store infra, AI-specific CI/CD, feature store), each with a labeled architecture diagram, identity and auth model, isolation spec, logging spec, and explicit row-by-row mapping to SR-Infrastructure requirements and TA-Infrastructure threats with HAI TTP tags, applicable MITRE ATLAS mitigation IDs, and HCT threat roots addressed, accessible within one click of the SM inventory record? Evidence: Pattern catalog with seven versioned documents; SM inventory record containing direct links. 2. Are 100% of inference endpoints and model registries verified via IAM audit (not only policy declaration) to use workload-identity-only access with no long-lived API keys in service principals, and is the anti-pattern catalog linked from the AI Acceptable Use Policy, the SM intake gate, and EG-Infrastructure training, with each entry tied to a real incident or authoritative case study? Evidence: IAM audit output; anti-pattern catalog linked from AUP, intake gate, and EG training curriculum. 3. Is a repeat-deviation signal operational, such that three deviations in the same direction for the same archetype automatically queue a pattern-update review with SA-Infrastructure ownership, and are ≥85% of active AI/HAI infrastructure assets in the SM inventory classified as "on pattern" or "deviation with review" with no silent deviations? Evidence: Pattern metadata showing on-pattern or deviation-with-review status; deviation aggregation report from the last quarter.

Level 2. 1. Are the five tier-conditional extended patterns (Critical overlay, High overlay, multi-region, multi-tenant, per-tier IaC modules) published as forkable IaC modules with conformance test suites, and are ≥80% of Critical and High-tier AI/HAI infrastructure assets running on IaC-encoded patterns as confirmed by the IaC and SM inventory registries? Evidence: IaC module repository with five variant directories; conformance test run history; SM inventory showing tier-to-pattern alignment. 2. Has the anti-pattern catalog been updated from ≥3 real IM-Infrastructure incidents in the last 12 months, with new entries surfaced at intake time rather than stored only in a reference document, and does conformance testing cover 100% of IaC-encoded asset deployments with findings tracked to resolution? Evidence: Anti-pattern change log with IM incident references; intake gate showing current anti-pattern catalog version; CI/CD conformance test coverage report. 3. Are 100% of Critical-tier assets carrying explicit EU AI Act Art. 9 and Art. 15 control mappings in the pattern documentation, and is the tier-treatment matrix from SM-Infrastructure L2 reflected in the pattern variants (Critical assets get the Critical overlay, High assets get the High overlay, Medium/Low follow the base pattern)? Evidence: Critical-tier pattern documents with Art. 9/Art. 15 mapping sections; SM intake routing log showing tier-differentiated pattern assignment.

Level 3. 1. Have ≥5 reference patterns been published as open artifacts under a recognized open license via at least one industry body (CNCF AI, OpenSSF AI, CSA, or equivalent), and have ≥2 been cited or forked by recognized industry or sector bodies, with documented adoption evidence and internal practice aligned to the published version? Evidence: External repository with license file; citation or fork count; internal-vs-external pattern diff audit with no unexplained deviations. 2. Have ≥2 MITRE ATLAS AML.M00xx mitigation entries been proposed or validated, traceable to specific SA-Infrastructure pattern controls aligned to ATLAS primary tactics TA0006 Persistence, TA0007 Privilege Escalation, and TA0008 Defense Evasion, and is there an active ATLAS practitioner engagement cadence? Evidence: ATLAS contribution log with PR or submission references; meeting records from the ATLAS practitioner community. 3. Is there at least one documented reference to SA-Infrastructure patterns in a regulatory implementing-act, sector guidance document, CNCF AI community document, OpenSSF AI guidance, or published standards text, and is the regulatory and community engagement calendar maintained with active items, target timelines, and evidence of substantive participation? Evidence: Regulatory engagement log with document references and citation extracts; engagement calendar with active items.

20. Design Review (DR)

Practice Overview

Objective: Operate the design checkpoint between intake approval and build-out for every new AI/HAI infrastructure component, confirming the proposed design follows the applicable SA-Infrastructure reference pattern, covers the SR-Infrastructure requirements pack, and documents residual risks before provisioning begins.

Description: DR-Infrastructure is the single moment where infrastructure architecture (SA-Infrastructure), requirements (SR-Infrastructure), and threats (TA-Infrastructure) meet a specific planned component, an inference endpoint, a model registry, a GPU/accelerator fleet node, an orchestrator control plane, a vector-store deployment, an AI-specific CI/CD pipeline, or a feature store. The review runs before the infrastructure team begins provisioning, catching deviations when they cost hours to correct, not migration cycles. A two-lane model routes Low / Medium-tier components to an async fast-lane (target ≤2 business days) and High / Critical-tier or deviation cases to a full-lane architect review (target ≤5 business days). Every review produces a written decision (approve / approve-with-conditions / send-back) stored against the SM-Infrastructure inventory record. Loop-back signals ensure the review process improves SA-Infrastructure patterns and SR-Infrastructure packs over time rather than accumulating silent technical debt.

Context: Without a design checkpoint, AI/HAI infrastructure components reach production without verified workload identity, without per-tenant isolation bounds, without encryption-key placement decided, and without a signed-artifact requirement on the model registry. The SA-Infrastructure reference pattern and SR-Infrastructure requirements pack exist, but teams skip them under sprint pressure, deviate without recording rationale, or provision before the archetype pattern is consulted. DR-Infrastructure enforces the handoff between "design approved" and "provisioning begins," making deviations visible and deliberate. EU AI Act Art. 9 risk management requires documented pre-deployment decisions for high-risk AI systems; the DR decision record is that documentation for the infrastructure layer.

Maturity Level 1

Objective: Run a per-archetype design checkpoint for every AI/HAI infrastructure component before provisioning, producing a written decision traceable to the SA-Infrastructure reference pattern, SR-Infrastructure requirements pack, and TA-Infrastructure threat snapshot.

Activities.

A) Publish the per-archetype AI/HAI Infrastructure Design Checklist. One checklist per SM-Infrastructure archetype, derived from the applicable SA-Infrastructure reference pattern and keyed to the SR-Infrastructure base pack and archetype delta. Each item is a yes/no with an evidence pointer. The seven checklists share a common spine, pattern adherence (using the SA reference pattern or a documented deviation with rationale), workload identity (service account per component, no shared credentials, no long-lived static keys in code, config, or environment variables, secrets managed via vault), per-tenant isolation (data, compute, and network boundary specified with an explicit mechanism, namespace, VPC, IAM policy, or API key scope), encryption (at rest and in transit declared with algorithm, key management, and KMS placement, no keys in code or environment variables), region / data residency (residency requirements satisfied, cross-region movement constrained, compliance classification applied), observability (logging, tracing, and alerting design declared with required event types, log destination, and retention named), patch / image hygiene (base image provenance declared, image scan required, patch cadence specified, no unpinned or latest-tagged images), quotas / rate-limits (resource quotas, API rate-limits, and burst limits specified, no unbounded GPU, memory, or API consumption), backup / recovery (backup policy and RTO/RPO targets declared with the restore procedure referenced), failure-mode documentation (degraded-mode behavior documented, no silent failure producing misleading output or undefined system state), and residual risk (explicit list with named owner, accepted rationale, and expiry date), plus archetype-specific additions. The inference endpoint checklist adds mTLS between clients and the serving endpoint, a per-tenant rate-limit design (not only global), model artifact signed and signature verified at load time, a canary deployment plan for new model versions, and PII-redaction-at-logging (PII in prompts or completions redacted before logs are written). The model registry checklist adds signed-artifacts-only (unsigned artifacts must not be promotable to production), lineage required for every artifact (training-data version, eval suite results, provenance chain), promotion-rights access control restricted to named principals, and a documented rollback mechanism. The GPU / accelerator fleet checklist adds residual-state-clearing (GPU memory wiped between jobs using vendor-supported procedures), classification-aware scheduling (regulated or Critical-tier workloads must not share a physical node with other-classification workloads), a no-shared-GPU policy for Critical-tier workloads, and credential isolation (each job's credentials scoped to that job and expiring on completion). The orchestrator / control plane checklist adds a workflow-signing requirement, a per-step principal design (each step under its own minimal-scope identity, not the orchestrator's full identity), control-plane API authentication (not network-implicit), and agent-state-tampering prevention. The vector-store checklist adds per-tenant partitioning of embeddings, classification labels propagated through query results, query observability (queries logged with tenant context, volume, and result-count), and inversion defense (raw vector access controlled, nearest-neighbor query scope bounded). The AI-specific CI/CD checklist adds a pipeline-signing requirement, SLSA provenance generation for model artifacts as a required step, an evaluation gate as a required check before promotion, and a secrets-leak-prevention scan as a required step. The feature store checklist adds feature-skew monitoring design, feature-lineage tracking, a rollback playbook for feature versions, and an access-control design for feature reads and writes.

B) Triage and route reviews by risk tier and deviation status. The two-lane model is driven by the SM-Infrastructure tier assignment and the deviation flag. Fast-lane (Low / Medium tier, on-pattern): async checklist review by the designated reviewer, target SLA ≤2 business days; output is one structured decision record, approve / approve-with-conditions (explicit list) / send-back (reasons stated), stored against the SM-Infrastructure inventory record. Full-lane (High / Critical tier, or any pattern deviation, regulated data processed, or component running on shared GPU): a 45–60 minute architect review with the infrastructure team walking the SA-Infrastructure reference pattern section-by-section, target SLA ≤5 business days; output is a written decision record with the residual-risk list reviewed by a named architect. Before SM-Infrastructure L2 tiers are established, inference endpoints and GPU fleet nodes handling regulated data default to full-lane, AI-specific CI/CD pipelines and orchestrators default to full-lane, and all others default to fast-lane with override to full-lane available on reviewer judgment. Every decision record, both lanes, carries: decision (approve / approve-with-conditions / send-back), checklist completed with evidence pointers, deviations listed with rationale, residual risks with named owner and expiry, reviewer name and date, and links to the SM-Infrastructure inventory record, TA-Infrastructure threat snapshot, and SR-Infrastructure REM.

C) Close the loop with SA-Infrastructure, SR-Infrastructure, and IM-Infrastructure. Design review is a learning surface for the program. Three deviations in the same direction for the same archetype auto-queue a pattern-update review with SA-Infrastructure ownership, recurring deviations signal the pattern is miscalibrated, not that infrastructure teams are wrong. An SR requirement repeatedly waived with a compensating control auto-queues an SR pack-revision review. Every IM-Infrastructure incident re-examines the DR decision record that approved the affected component: was the issue visible at design time, and which checklist item would have caught it? The answer updates the checklist and feeds the next archetype review cycle.

Outcome Metrics (L1).

Success Criteria.

• Per-archetype design checklists published, versioned, and traceable to the applicable SA-Infrastructure reference pattern, SR-Infrastructure requirements pack, and TA-Infrastructure threat snapshot, one per archetype (inference endpoint, model registry, GPU fleet, orchestrator, vector-store, AI-CI/CD, feature store).
• Two-lane review model operational with published SLAs (≤2 BD fast-lane, ≤5 BD full-lane) and named lead reviewers per archetype trained on EG-Infrastructure L1.
• ≥95% of AI/HAI infrastructure components going to production in the last 90 days carry a completed DR decision record before provisioning begins.
• SA pattern-update and SR pack-update triggers wired so recurring deviations and waived requirements feed back; every IM-Infrastructure incident re-examines the DR record that approved the affected component.

Maturity Level 2

Objective: Upgrade Critical-tier reviews to scenario-based walkthroughs driven by TA-Infrastructure per-component threat models, detect design drift for High and Critical components on a published cadence, and coordinate joint DR-Infrastructure / DR-Software reviews for Critical-tier software artifacts integrating with shared AI infrastructure.

Activities.

A) Scenario-based reviews for Critical and High-tier components. For every Critical-tier infrastructure component, the full-lane checklist walkthrough is replaced by a scenario walkthrough. The reviewer sources 3–5 specific threat scenarios from the TA-Infrastructure per-component deep threat model and the TA-Infrastructure archetype library. Scenarios must be specific to this component's data classification, tenant population, network placement, and connectivity, not generic archetype scenarios. Each scenario is walked as: "If an adversary does X, does the proposed infrastructure design have a control that prevents or detects it? Where? What is the residual risk?" The DR decision record maps each scenario to a design control or an accepted residual risk with a named owner and expiry. Scenario sources include the TA-Infrastructure per-component deep threat model, anonymized IM-Infrastructure incidents from the same archetype, MITRE ATLAS technique candidates for the component's primary defensive coverage (TA0001 Reconnaissance, does the design minimize the inference endpoint's attack surface; TA0004 ML Model Access, does the model registry enforce signed artifacts and access control; TA0012 ML Attack Staging, does the GPU fleet prevent residual state leakage; TA0013 Exfiltration, does the vector store prevent cross-tenant retrieval extraction), and OWASP LLM / Agentic Top 10 infrastructure-relevant entries. For High-tier components, the standard full-lane review is augmented with at least one scenario from the TA-Infrastructure archetype library.

B) Cross-domain joint reviews for Critical-tier software-to-infrastructure integrations. When a Critical-tier first-party software artifact integrates with shared AI infrastructure, an agent calling a shared inference endpoint, a RAG pipeline backed by a shared vector store, a fine-tune job running on the shared GPU fleet, DR-Infrastructure coordinates a joint review with DR-Software. The DR-Infrastructure reviewer and DR-Software reviewer attend the same session; the responsibility boundary (which controls are the infrastructure team's responsibility vs. the software team's) is explicitly documented in both DR records. DR-Infrastructure covers the shared component's design; DR-Software covers the software artifact; residual risks spanning both are noted in both records with shared ownership and a single named resolution owner. Where the software integration is new and no DR-Infrastructure record exists for the referenced component, DR-Software flags the gap and withholds Sanctioned status until DR-Infrastructure completes.

C) Design-drift detection. The live production component is compared against its approved DR design at a published cadence. Critical-tier: quarterly drift check, examining IaC-repository changes since the last DR that affect SA-pattern controls (workload identity, encryption, isolation policies, rate-limit configs, image pins), cloud-provider API resource-configuration changes vs. the DR-approved baseline, Kubernetes / orchestrator API deployment-manifest drift, model-registry events (model version and signing policy changes), and CI/CD job parameter changes. High-tier: annual drift check using the same sources. Material drift, a new tenant added to a shared component without isolation review, a GPU scheduling policy changed to allow sharing on Critical workloads, a rate-limit removed or raised, workload identity changed to a shared credential, an encryption key changed to an unmanaged key, pipeline signing disabled, automatically re-opens the DR record and routes back through the appropriate lane. Each drift check produces a written artifact: the diff between approved design and live configuration, each delta classified as material or non-material, with material deltas tracked to DR re-review or accepted residual.

Outcome Metrics (L2).

Success Criteria.

• 100% of Critical-tier DR reviews conducted as scenario-based walkthroughs with the decision tied to how the design handles each scenario.
• Design-drift detection operating quarterly for Critical and annually for High; 100% of material drifts re-routed to DR.
• Joint DR-Infrastructure / DR-Software review records on file for 100% of Critical-tier software-to-infrastructure integrations.
• IR-stage design surprises measurably fewer than at L1 over consecutive quarters.

Maturity Level 3

Objective: Operate continuous design attestation via IaC-compliance scans and cloud-policy enforcement, automate drift-triggered DR exception tickets, and contribute review rubrics and scenario templates to CNCF AI, OpenSSF, and the OWASP LLM / Agentic Top 10 infrastructure patterns.

Activities.

A) Continuous design attestation via IaC-compliance scans and cloud-policy enforcement. Critical-tier infrastructure components produce a daily attestation signal covering: an IaC compliance scan (SA-Infrastructure reference pattern controls present and enforced in the deployed IaC state, Terraform / Pulumi plan-vs-state diff, admission-controller policy checks via Kyverno / Gatekeeper), a cloud-provider API check (workload identity not reverted to long-lived keys, encryption keys in KMS not inline, rate-limit configuration active, per-tenant isolation policy intact), a model-registry check (signing policy enforced, lineage required for every artifact in scope), and a logging-completeness check (the ML-Infrastructure signal that required event types are flowing at expected volume). Deviations from the approved design automatically open a DR-exception ticket in IM-Infrastructure, triaged within 3 business days. Attestation artifacts are machine-readable and regulator-consumable, EU AI Act Art. 9 risk-management evidence and ISO/IEC 42001 AIMS operational records are produced by the attestation pipeline without manual assembly. Human reviewers handle novel architectures not covered by existing attestation rules, accepted exceptions with documented rationale, and escalations from the IM-Infrastructure backlog.

B) Contribute review rubrics and scenario templates to industry. Publish under Apache 2.0 or equivalent through the CNCF AI Working Group, OpenSSF AI / MLOps, or the OWASP LLM / Agentic Top 10 infrastructure-pattern workstream: per-archetype AI/HAI infrastructure design review rubrics (tier-assignment criteria, checklist items with evidence pointers, scenario-selection guidance keyed to ATLAS tactics TA0001, TA0004, TA0012, TA0013), scenario template libraries (scenario format, per-archetype examples, debrief rubric), and a pattern-evolution framework (how external signals, ATLAS updates, CNCF AI advisories, IM incidents, feed DR checklist and scenario updates on a quarterly cadence). Internal rubrics and templates remain aligned to the published external versions; internal deviations are proposed as upstream changes, not silently forked. Adoption is tracked by citations, forks, and direct acknowledgment from peer organizations or standards bodies.

C) Pattern evolution driven by external and internal signals. A quarterly pattern-evolution review combines external signals (MITRE ATLAS technique additions and refinements for TA0001 Reconnaissance, TA0004 ML Model Access, TA0012 ML Attack Staging, and TA0013 Exfiltration; CNCF AI and OpenSSF MLOps advisories; OWASP LLM / Agentic Top 10 revisions affecting infrastructure patterns) with internal signals (IM-Infrastructure incident patterns by archetype, ML-Infrastructure telemetry anomalies, ST-Infrastructure red-team findings) to produce structured checklist and scenario library updates. Updates are change-logged with signal provenance; downstream DR records for in-flight reviews are notified of pattern changes affecting their archetype. Where a new ATLAS technique or IM incident reveals a checklist gap, the gap is propagated to SA-Infrastructure and SR-Infrastructure to maintain the full traceability chain from threat to requirement to design review.

Outcome Metrics (L3).

Success Criteria.

• Daily attestation operating for ≥90% of Critical-tier components; DR-exception tickets opened on deviation and triaged within 3 business days.
• ≥2 externally contributed review artifacts per year, per-archetype rubrics, scenario templates, or pattern-evolution frameworks, published to CNCF AI / OpenSSF / OWASP with documented adoption.
• Review backlog for non-exception work inside ≤7 days; attestation has absorbed the routine review volume.
• Quarterly pattern-evolution cadence traceable to external (MITRE ATLAS TA0001/TA0004/TA0012/TA0013, CNCF AI, OpenSSF) and internal (IM-Infrastructure, ML-Infrastructure, ST-Infrastructure) signals with a versioned change log.

Common Pitfalls

Level 1. - Design review runs after the infrastructure team has already provisioned the component, the checkpoint loses leverage because re-provisioning cost is already sunk; the review becomes a retrospective, not a gate. - Checklists are identical across archetypes, the GPU fleet checklist does not include residual-state-clearing or classification-aware scheduling because it was copied from the inference endpoint checklist. - Fast-lane becomes the default for everything, GPU fleet nodes and orchestrators slip through with a 15-minute async check rather than the full-lane architect session they require. - Approve-with-conditions is issued but conditions have no named owner and no expiry, conditions sit unresolved at go-live with no enforcement path.

Level 2. - "Scenario-based" review is the same checklist read aloud in a meeting, same items, different format; the scenario-to-design-control mapping is never actually performed. - Scenario library is not refreshed quarterly, scenarios pulled from a 12-month-old TA snapshot do not reflect the current per-component threat model or recent IM-Infrastructure incidents. - Design-drift detection runs on a schedule but findings dead-end in a spreadsheet, no DR-exception ticket is opened; the approved design remains fiction while the live component has diverged. - Joint DR-Infrastructure / DR-Software reviews never happen because the coordination channel was never established, Critical-tier software artifacts calling shared inference endpoints have no responsibility-boundary documentation on file.

Level 3. - Attestation signals show green across all Critical components but underlying checks cover only logging settings, workload identity state, encryption key placement, and rate-limit configuration are not checked; attestation is cosmetic. - Externally published rubrics diverge from internal practice, the published artifact reflects how the org reviewed components 18 months ago; peer adopters find inconsistencies when comparing the rubric to actual DR records. - Exception queue overwhelms reviewers because attestation thresholds are too sensitive, every image patch triggers a DR-exception ticket; reviewers suppress the signal source rather than tune the sensitivity threshold. - Industry contributions are conference talks and blog posts, no technical artifacts (rubrics, scenario templates, pattern-evolution frameworks) land in CNCF / OpenSSF / OWASP with documented adoption.

Practice Maturity Questions

Level 1. 1. Is there a published, versioned per-archetype AI/HAI Infrastructure Design Checklist, one per SM-Infrastructure archetype (inference endpoint, model registry, GPU fleet, orchestrator, vector-store, AI-CI/CD, feature store), traceable to the applicable SA reference pattern, SR requirements pack, and TA threat snapshot, with the GPU fleet checklist covering residual-state-clearing and classification-aware scheduling, the inference endpoint checklist covering mTLS, per-tenant rate-limit, signed-model, canary, and PII-redaction-at-logging, and the model registry checklist covering signed-artifacts-only and lineage-required? Evidence: Checklist document with version history; traceability matrix linking each item to an SA pattern control and SR requirement; GPU fleet and inference endpoint checklist sections signed off by the named lead reviewer. 2. Do ≥95% of AI/HAI infrastructure components going to production in the last 90 days carry a completed DR decision record (approve / approve-with-conditions / send-back) before provisioning begins, with a two-lane routing model (fast-lane ≤2 BD, full-lane ≤5 BD), named lead reviewers per archetype trained on EG-Infrastructure L1, and a residual-risk list with named owner and expiry in every record? Evidence: SM-Infrastructure inventory query showing last-90-days production entries with DR decision record IDs linked; review SLA telemetry report; sample of 5 decision records showing the residual-risk section populated. 3. Are recurring pattern deviations and repeatedly-waived SR requirements automatically queuing SA-Infrastructure pattern-update and SR-Infrastructure pack-update reviews, and does every IM-Infrastructure incident trigger a re-examination of the DR record that approved the affected component? Evidence: SA pattern-update queue entries with triggering deviation counts; SR pack-update tickets linked to waiver patterns; IM-Infrastructure incident post-mortems with a DR-record re-examination section completed.

Level 2. 1. Are 100% of Critical-tier DR reviews conducted as scenario-based walkthroughs, with 3–5 specific threat scenarios sourced from TA-Infrastructure per-component deep models and anonymized IM-Infrastructure incidents, keyed to ATLAS tactics TA0001, TA0004, TA0012, TA0013, with the DR decision tied explicitly to how the proposed design handles each scenario rather than checklist conformance alone? Evidence: Critical-tier DR decision records from the last 90 days, each showing a scenario-to-design-control mapping table and a decision statement tied to scenario outcomes. 2. Is design-drift detection running quarterly for Critical-tier and annually for High-tier, using IaC-repository changes, cloud-provider API state, Kubernetes API manifest drift, model-registry events, and CI/CD parameter changes, with 100% of material drifts automatically re-routed to DR for a new review? Evidence: Drift-detection run log with cadence dates; material-drift classification report showing re-routed components; DR queue entries with a drift-triggered source tag. 3. Are joint DR-Infrastructure / DR-Software review records on file for 100% of Critical-tier software artifacts integrating with shared AI infrastructure, with an explicit responsibility boundary and shared residual-risk ownership documented in both DR records? Evidence: Cross-reference report of Critical-tier software-to-infrastructure integrations; matching DR-Infrastructure and DR-Software decision records; responsibility-boundary section in each record.

Level 3. 1. Are ≥90% of Critical-tier AI/HAI infrastructure components producing a daily automated attestation signal, checking IaC compliance, cloud-provider API configuration, workload identity state, encryption key placement, rate-limit configuration, and logging completeness, with deviations auto-opening DR-exception tickets triaged within 3 business days? Evidence: Attestation telemetry dashboard showing a daily signal per Critical component; DR-exception ticket queue with open/triage timestamps; sample attestation artifact in machine-readable format. 2. Has the program contributed ≥2 substantive review artifacts per year (per-archetype rubrics, scenario templates, pattern-evolution frameworks) to CNCF AI, OpenSSF, or the OWASP LLM / Agentic Top 10 infrastructure patterns, with documented adoption and internal practice aligned to the published versions? Evidence: Contribution log with external publication links and adoption indicators; comparison document showing the internal checklist aligned to the published version. 3. Is there a quarterly pattern-evolution review driven by external signals (MITRE ATLAS TA0001/TA0004/TA0012/TA0013, CNCF AI and OpenSSF advisories) and internal signals (IM-Infrastructure incidents, ML-Infrastructure telemetry, ST-Infrastructure findings), with a versioned change log and notification to in-flight DR reviews affected by pattern changes? Evidence: Quarterly pattern-evolution review minutes with signal-source citations; versioned checklist change log; in-flight DR review notification records for the most recent pattern update.

21. Implementation Review (IR)

Practice Overview

Objective: Verify, at go-live and on a recurring cadence, that the actual configuration of AI/HAI infrastructure the organization operates matches the design approved at DR, and that it stays there as components evolve.

Description: IR-Infrastructure is the configuration check for AI/HAI infrastructure components, the moment a reviewer opens the IaC state, the cloud-provider API, the Kubernetes manifest, and the model registry and confirms that what is running matches the DR decision record. At L1 the review runs at go-live, at least annually, and on material change (model version swap, new tenant added, GPU scheduling policy changed, isolation policy updated). At L2, IR-Infrastructure consumes IaC drift-detection tooling, cloud-provider Config Rules and asset-inventory APIs, admission-controller policy checks, model-registry webhooks, and vendor admin API probes to detect configuration drift continuously for High and Critical-tier components. Findings are severity-tagged and SLA-bound per the SM-Infrastructure L2 tier-treatment matrix; they feed IM-Infrastructure for tracking and resolution. Per-tenant isolation, signing policies, rate-limit configurations, and GPU residual-state-clearing are probed recurrently, not trusted from design text alone.

Context: The gap between the approved infrastructure design and the running state is the primary source of silent security exposure in AI/HAI infrastructure. A GPU fleet's residual-state-clearing policy is correct in the DR record but the scheduler was reconfigured to allow cross-workload sharing on a Critical-tier node. A model registry's signed-artifacts-only policy appears in the SR REM but a platform update reset the enforcement flag. An inference endpoint's per-tenant rate-limit is documented in the SA pattern but the rate-limit layer was removed during a cost-optimization change. IR-Infrastructure closes these gaps by making the implementation check systematic, evidence-based, and recurring, not a one-time pre-launch checkbox or a scramble when an incident reveals a configuration regression.

Maturity Level 1

Objective: Run per-archetype implementation reviews at go-live, annually, and on material change, verifying deployed configuration matches the SA-Infrastructure pattern and the DR decision, and that the SR-Infrastructure REM evidence is current.

Activities.

A) Publish the per-archetype implementation review checklist. One checklist per SM-Infrastructure archetype, focused on the configuration points where production reality most commonly drifts from the approved design. Each item is a yes/no with a required evidence artifact (IaC plan output, cloud-provider API response, screenshot, test result). The common spine across all archetypes covers: IaC state matches the SA pattern (a Terraform / Pulumi plan-vs-apply confirms the deployed configuration is within tolerance of the DR-approved IaC module, deviations flagged); config matches the DR decision (workload identity, encryption key placement, isolation policies, rate-limit configs, and image pins match the DR decision record, deviations flagged); SR REM evidence is current (a stratified sample of REM rows verified against current observable reality, workload identity confirmed via IAM API not assumed, encryption keys confirmed in KMS not inline, rate-limit confirmed active via probe, image pins confirmed in the deployment manifest); logging is actually producing the events the design promised (a sample of required event types, model-serve events, admin-audit events, identity events, pulled from the logging pipeline and confirmed present, in format, and meeting the retention policy in the SR REM); and per-tenant isolation is actually enforced (a cross-tenant probe confirms one tenant cannot access another's data, compute, or model artifacts through the component). The inference endpoint checklist adds verification that mTLS is active (not bypassed by a network policy change), the per-tenant rate-limit is active (not reverted to global-only), model artifact signature verification is active at serving time (tested by attempting to serve an unsigned artifact and verifying rejection), the canary deployment configuration matches the DR-approved rollout plan, and PII redaction at logging is active (tested with a synthetic PII-containing prompt, verifying the PII is absent from log output). The model registry checklist confirms signed-artifacts-only is active (attempt to push an unsigned artifact, verify rejection), lineage-required is active (attempt to promote without lineage, verify rejection), rollback was tested within the last 90 days (test record on file), and promotion-rights access control matches current IAM assignments. The GPU / accelerator fleet checklist confirms residual-state-clearing is operational (run job A on a node, then run job B on the same node and verify job A's GPU memory is inaccessible, test record on file), classification-aware scheduling is enforced (attempt to schedule a Critical-tier workload on a shared node, verify the scheduler rejects or redirects), and per-job credential scoping is enforced (credentials expire after job completion and cannot be reused). The orchestrator checklist confirms workflow-signing enforcement (attempt to submit an unsigned workflow, verify rejection), per-step principal assignment (each step runs under its own identity via an IAM audit-log sample), control-plane API authentication (an unauthenticated probe returns 401/403), and agent-state isolation (a step cannot read another step's in-flight state). The vector-store checklist confirms cross-tenant retrieval isolation (a query from tenant A using a term matching tenant B's index returns zero results or a namespacing error), classification-label propagation (query results carry index labels in metadata), and query observability (a query-log sample captures tenant context, query, and result-count). The AI-specific CI/CD checklist confirms pipeline-signing enforcement (an unsigned pipeline is rejected), SLSA provenance generation is active (a recent model artifact carries a provenance attestation), eval-gate enforcement (a model without a passing eval attestation cannot be promoted), and a secrets-leak-prevention scan is active (a recent scan result is on file with zero findings or documented exceptions). The feature store checklist confirms the offline/online feature-skew alert is active (an injected synthetic skew fires the alert), feature lineage is recorded (a recent feature version carries a traceable source dataset and transformation), the rollback playbook was tested within the last 90 days (test record on file), and access control is enforced (unauthorized read and write attempts are rejected via probe).

B) Perform reviews at the right moments. Three triggers at L1: go-live (before the component enters production, or before a new version or configuration goes live, verify the as-deployed state against the DR-approved design; no production cutover with a blocker finding open); annual (every active AI/HAI infrastructure component reviewed at least annually, scheduled from the SM-Infrastructure inventory with a last-IR-date field linked to a review-due alert); material-change (any of the following triggers an ad-hoc review before the change ships to production, a GPU scheduling policy change, a new tenant added to a shared component, a rate-limit policy change, a workload identity change, an encryption-key rotation to a new key management mechanism, a model version or signing policy change on the model registry, a pipeline signing policy change on AI-CI/CD, or a feature schema change on the feature store). The material-change trigger is wired to the same signal sources as SM-Infrastructure inventory material-change events. Reviews are evidence-based, IaC plan outputs, cloud-provider API responses, or probe results stored with the IR record.

C) Track findings to closure. Every review produces zero or more findings. Each finding carries a severity (Critical, for example a GPU node sharing Critical-tier and non-Critical workloads without residual-state-clearing, / High / Medium / Low, calibrated to the SM-Infrastructure tier-treatment matrix; at L1 use a consistent judgment rubric pending SM L2 formalization), a named owner (a named engineer or team owner, not "the platform team"), an SLA from the SM-Infrastructure tier-treatment matrix (Critical blocker resolved before production cutover or rollback required; High ≤7 days; Medium ≤30 days; Low ≤90 days or accepted residual), and an after-fix evidence artifact (IaC plan output, probe result, screenshot) linked before closure. Findings feed IM-Infrastructure as issues for tracking and aging, and loop back to SR-Infrastructure where a finding reveals that an REM row's cited evidence was inaccurate, the REM row is updated before the finding is closed. Drift sources verified at L1 without continuous tooling include the IaC repository (Terraform / Pulumi plan-vs-apply state), cloud-provider APIs (AWS Config, GCP Asset Inventory, Azure Policy state), the Kubernetes / orchestrator API (deployment-manifest drift), model-registry events (model version and signing policy changes), and CI/CD job parameters (parameters affecting model versions, pipeline signing, and eval-gate settings).

Outcome Metrics (L1).

Success Criteria.

• Per-archetype IR checklists published, owned, and linked from the SM-Infrastructure inventory record and the DR decision record.
• Go-live, annual, and material-change review triggers wired to the SM-Infrastructure inventory; 100% of new AI/HAI infrastructure components in the last 90 days have a go-live IR record.
• ≥90% of active AI/HAI infrastructure components carry a current-year IR record.
• All Critical / blocker findings resolved before production cutover; High findings closed within 7 days with evidence linked.
• Findings-aging dashboard reviewed at least monthly by the program sponsor.

Maturity Level 2

Objective: Detect configuration drift continuously for Critical and High-tier components via IaC drift-detection tooling, cloud-provider Config Rules, admission-controller checks, model-registry webhooks, and vendor admin API probes; run boundary probes recurrently; calibrate IR cadence per SM-Infrastructure L2 risk tier.

Activities.

A) Continuous drift detection from IaC, cloud-provider APIs, and admission-controller checks. Wire the following signal sources to an automated drift-detection pipeline for Critical and High-tier components. IaC drift-detection tooling: Terraform Cloud / Atlantis / Pulumi state-diff runs on a defined cadence for Critical and High components; configuration deviations from the approved IaC module open IR findings automatically. Cloud-provider Config Rules / asset-inventory APIs: AWS Config Rules, GCP Asset Inventory, or Azure Policy continuously check resource configurations against the DR-approved baseline; violations open IR findings with severity tags. Admission-controller policy checks: Kyverno / Gatekeeper policies enforce SA-Infrastructure reference pattern controls at the Kubernetes API level (workload identity annotations required, image signing required, resource quota policies enforced); policy violations open IR findings. Model-registry webhooks: model version promotions, signing policy changes, and lineage-exemption events trigger an IR re-review gate for the affected component; a model promotion without a corresponding DR material-change review is a Critical finding. Vendor admin API recurrent probes: for managed AI infrastructure components (Amazon Bedrock fleet configuration, Vertex AI model deployment settings, Azure OpenAI deployment configurations), recurrent probes via vendor admin APIs verify rate-limit settings, signing policies, and logging configurations match the DR-approved baseline; a delta from the previous probe opens an IR finding. Detection latency targets: Critical-tier ≤7 days from change event to finding opened; High-tier ≤30 days.

B) Per-archetype boundary probing. For every Critical and High-tier component, boundary probes are executed at each IR cycle to verify isolation and enforcement claims, not assumed from configuration declarations. Inference endpoint: a cross-tenant probe (a request with tenant A credentials attempting to access tenant B's model endpoint or model artifact) is verified rejected, and an unsigned-model-artifact serving probe is verified rejected. GPU fleet: the residual-state-clearing test is executed (run job A, then run job B on the same node, verify job A's GPU memory is inaccessible) with the test date and result recorded, and an attempt to schedule a Critical-tier workload on a shared node is verified rejected or redirected. Orchestrator: an unsigned workflow definition is submitted and verified rejected, and a step-privilege-boundary test (attempt to invoke a resource from within one step that belongs to another step's principal scope) is verified rejected. Vector-store: a cross-tenant retrieval probe is verified to return zero results or a namespacing error, and classification labels are verified present and correct in query results. AI-CI/CD: an unsigned pipeline run is verified rejected, and an attempt to promote a model artifact without a passing eval attestation is verified blocked. Boundary probe evidence is stored with the IR record; failures are Critical findings for Critical-tier components and High findings for High-tier components.

C) Tier-calibrated IR cadence. Publish and enforce per the SM-Infrastructure L2 tier-treatment matrix: Critical (go-live + semi-annual + material-change-triggered + continuous drift detection), High (go-live + annual + material-change-triggered), Medium (go-live + annual), Low (go-live + re-review on material change). Every component in the SM-Infrastructure inventory carries a last-IR-date and next-IR-due field; Critical-tier components with no IR in the last 180 days are escalated to the program sponsor. IR findings are aged tier-aware: Critical-tier findings never wait behind Low-tier queue items, and severity tags and SLAs match the SM-Infrastructure L2 tier-treatment matrix.

Outcome Metrics (L2).

Success Criteria.

• ≥90% of Critical-tier components under continuous drift detection; median detection latency ≤7 days.
• Vendor admin API probes current for ≥80% of Critical/High-tier managed components on a monthly (Critical) and quarterly (High) probing cadence.
• 100% of Critical/High-tier components with boundary probes on record in the current IR cycle.
• Tier-cadence adherence ≥95%; Critical-tier findings aged per the SM-Infrastructure L2 tier-treatment matrix SLAs.

Maturity Level 3

Objective: Operate continuous configuration attestation for Critical-tier components with a daily signal confirming IaC-pattern compliance and evidence freshness, auto-open IM tickets on drift, and contribute per-archetype configuration baseline schemas to OpenSSF AI, the CNCF AI Working Group, and the OWASP LLM / Agentic Top 10 infrastructure patterns.

Activities.

A) Daily attestation signal for Critical-tier components. Each Critical-tier AI/HAI infrastructure component produces a daily composite attestation signal covering three dimensions: IaC-pattern compliance (an automated IaC-compliance scan confirming key controls are present and active in the deployed state, workload identity correctly assigned, encryption keys in KMS, rate-limit configuration active, per-tenant isolation policy intact, image pins enforced, signing policies active, using the IaC drift-detection tooling and admission-controller checks from IR L2 on a daily schedule with machine-readable output); evidence freshness (the SR-Infrastructure REM's evidence citations checked for staleness against defined freshness windows, IaC plan ≤1 day, boundary probe ≤90 days, vendor admin API probe ≤30 days for Critical / ≤90 days for High, GPU residual-state-clearing test ≤90 days; stale evidence opens a finding automatically); and configuration within tolerance (deployed configuration checked against the DR-approved baseline per defined tolerances, patch versions within the same major image tag tolerated, image family changes not tolerated without DR re-review, workload identity principal changes not tolerated without a material-change review). Attestation artifacts are machine-readable, signed, and stored in the SM-Infrastructure inventory record; they are regulator-consumable for EU AI Act Art. 9 risk-management evidence and ISO/IEC 42001 AIMS operational records. Drift auto-opens an IM-Infrastructure ticket carrying the drift dimension (IaC-pattern compliance / evidence freshness / configuration), the specific control that failed tolerance, and a link to the DR decision record.

B) Contribute per-archetype configuration baseline schemas. Publish per-archetype IR configuration baseline schemas, defining what correct implementation looks like for each AI/HAI infrastructure archetype at each SM-Infrastructure tier, to OpenSSF AI (a reference attestation schema for AI infrastructure implementations, machine-readable and compatible with supply-chain attestation frameworks SLSA and in-toto), the CNCF AI Working Group (per-archetype configuration controls for AI/ML infrastructure on Kubernetes, with checklist items and evidence-type definitions aligned to CNCF AI security best practices), and the OWASP LLM / Agentic Top 10 infrastructure patterns (Verification function, Implementation Review stream, with practitioner-level checklist items for inference endpoint, model registry, GPU fleet, orchestrator, and vector-store archetypes). Internal practice remains aligned to the published external versions; internal-only deviations are proposed as upstream changes. Adoption is tracked by citations, forks, direct acknowledgment from peer organizations, or inclusion in external tooling or assessment frameworks.

C) Automated drift-to-IM escalation and post-incident attestation refinement. All IR findings, whether from daily attestation or periodic reviews, flow into IM-Infrastructure automatically with severity and SLA pre-populated from the SM-Infrastructure L2 tier-treatment matrix. The IM-Infrastructure SLA clock starts when the finding is opened; overdue Critical findings escalate to the program sponsor automatically at 50% and 100% of the SLA window. Post-incident reviews in IM-Infrastructure that touch a configuration control automatically re-examine the IR record for the affected component, was the drift detectable earlier, and what attestation rule would have caught it? The answer updates the attestation rule and the IR checklist.

Outcome Metrics (L3).

Success Criteria.

• Daily attestation operating for ≥90% of Critical-tier components across all three dimensions (IaC-pattern compliance, evidence freshness, configuration tolerance); deviations auto-opening IM tickets within 1 hour.
• Zero stale-evidence violations for Critical-tier REMs; High-tier stale-evidence rate trending down.
• Per-archetype configuration baseline schemas published to OpenSSF AI, CNCF AI, or the OWASP LLM / Agentic Top 10 infrastructure patterns with documented external adoption.
• IR reviewer-hours per Critical component per year trending down over two consecutive quarters.

Common Pitfalls

Level 1. - IR treated as a one-time go-live formality, no annual re-review and no material-change trigger; configuration drift accumulates silently for quarters until an audit or incident surfaces it. - Reviewers take the DR decision record at face value without querying the IaC state or cloud-provider API, the workload identity is declared correctly in the DR record but the deployed service account was swapped to a shared long-lived key during a deploy emergency. - Per-tenant isolation "verified" by reviewing the IaC module description without running a cross-tenant probe, the isolation is declared in config but never confirmed to actually block cross-tenant access at the API layer. - GPU residual-state-clearing documented in the DR record but never tested, the IR checklist has a "residual-state-clearing: yes" box that is checked without an actual test execution and a recorded result.

Level 2. - Drift-detection pipeline ingests IaC state events but generates no findings on deltas, the pipeline exists but automated finding creation was never configured; drift detection is manual in practice. - Vendor admin API probing is configured once at onboarding and never re-run, a rate-limit policy reset by a vendor platform update is undetected for months. - Boundary probing is documented as "verified at go-live" but never repeated, GPU residual-state-clearing and cross-tenant isolation may have regressed at a subsequent configuration change; the go-live test is the only record. - Drift findings from automated detection dead-end in an alert dashboard rather than auto-opening IM tickets, findings age without owners.

Level 3. - Daily attestation signals show green across all Critical components but underlying checks cover only logging volume, workload identity state, per-tenant isolation policy, and signing enforcement are not checked; attestation is cosmetic. - Configuration baseline schemas published externally diverge from internal practice, what is published reflects the L1 checklist; internal practice has advanced to L2 tooling and boundary probing; external adopters build on a stale baseline. - Attestation-exception queue overwhelms the team because configuration tolerance thresholds are too tight, every image patch triggers a deviation; reviewers suppress the signal source rather than tune the tolerance rules. - Post-incident IR feedback loop exists in policy but never fires in practice, IM post-incident reviews do not include the IR-record re-examination step; attestation rules never update from incident learning.

Practice Maturity Questions

Level 1. 1. Is there a published, per-archetype IR checklist, one per SM-Infrastructure archetype (inference endpoint, model registry, GPU fleet, orchestrator, vector-store, AI-CI/CD, feature store), covering IaC-state-matches-pattern, config-matches-DR, SR REM evidence currency, logging-event production, and per-tenant isolation confirmation, with the GPU fleet checklist requiring a residual-state-clearing test record and a classification-aware scheduling probe, and the inference endpoint checklist requiring mTLS, per-tenant rate-limit, signed-artifact enforcement, and PII-redaction-at-logging verification? Evidence: Published checklists with version history; GPU fleet checklist section showing a residual-state-clearing test step distinct from DR checklist conformance; sample IR record with IaC plan output and probe-result evidence attached. 2. Do 100% of new AI/HAI infrastructure components going to production in the last 90 days carry a go-live IR record, and do ≥90% of all active components carry a current-year IR record, with material-change triggers wired to SM-Infrastructure inventory events, Critical / blocker findings resolved before production, and High findings closed within 7 days with evidence linked? Evidence: SM-Infrastructure inventory query for last-90-days production entries with IR record IDs; annual review calendar with last-IR dates; findings backlog report showing zero open blockers at go-live and High-finding closure times. 3. Are findings severity-tagged and tracked in IM-Infrastructure with named owners and SLA-bound closure dates, and does every IR finding that reveals stale or inaccurate REM evidence trigger an SR-Infrastructure REM row update before the finding is closed? Evidence: IM-Infrastructure backlog export showing severity tags and SLA fields populated; REM update log showing IR-triggered row updates; findings-aging dashboard reviewed by the program sponsor within the last 30 days.

Level 2. 1. Are ≥90% of Critical-tier AI/HAI infrastructure components under continuous drift detection, via IaC drift-detection tooling, cloud-provider Config Rules / asset-inventory APIs, admission-controller policy checks, model-registry webhooks, and CI/CD parameter monitoring, with median detection latency ≤7 days and automated finding creation on material deviations? Evidence: Drift-detection telemetry report showing per-component signal coverage; detection-latency histogram for Critical-tier; sample auto-generated IR finding linked to a cloud Config Rule or admission-controller violation. 2. Are vendor admin API probes current for ≥80% of Critical/High-tier managed components on a monthly (Critical) and quarterly (High) cadence, and are 100% of Critical/High-tier components covered by boundary probes (cross-tenant isolation, signing enforcement, rate-limit enforcement, GPU residual-state-clearing, pipeline-gate enforcement) in the current IR cycle? Evidence: Vendor API probing log with cadence dates per component; boundary probe records per component (input, expected behavior, actual behavior, date); coverage report showing the percentage of Critical/High components covered. 3. Is tier-cadence adherence ≥95% with Critical-tier findings aged per the SM-Infrastructure L2 tier-treatment matrix SLAs, and is the drift-detection pipeline wired to auto-open IR findings (not just alert dashboards) for all Critical-tier components? Evidence: Tier-cadence adherence report from the IR schedule; IM-Infrastructure backlog showing Critical-tier findings aged by SLA; sample auto-created IR finding traced to a drift-detection event.

Level 3. 1. Are ≥90% of Critical-tier AI/HAI infrastructure components producing a daily attestation signal across all three dimensions (IaC-pattern compliance, evidence freshness, configuration tolerance), with deviations auto-opening IM-Infrastructure tickets within 1 hour and zero stale-evidence violations for Critical-tier REMs? Evidence: Attestation telemetry dashboard showing a daily signal per Critical component for the last 30 days; IM-Infrastructure ticket creation log with timestamps within 1 hour of attestation findings; Critical-tier REM evidence-freshness report with zero stale entries. 2. Has the program published per-archetype configuration baseline schemas to OpenSSF AI, the CNCF AI Working Group, or the OWASP LLM / Agentic Top 10 infrastructure patterns, with documented adoption and internal practice aligned to the published versions, and is IR reviewer-hours per Critical component per year trending down over two consecutive quarters? Evidence: External publication links with adoption indicators (forks, citations, inclusion in external tooling); comparison document showing the internal checklist aligned to the published baseline schema; reviewer time-tracking report showing a QoQ decline. 3. Is the post-incident IR feedback loop operational, IM-Infrastructure post-incident reviews include a mandatory IR-record re-examination step, and ≥1 attestation rule update is produced per material incident, ensuring incident learning continuously improves attestation coverage? Evidence: Sample post-incident review showing the IR-record re-examination section completed; attestation rule change-log entries linked to incident review IDs; trend showing attestation rule count increasing with incident volume.

22. Security Testing (ST)

Practice Overview

Objective: Prove that every AI/HAI infrastructure component the organization operates behaves correctly under adversarial conditions, by running a foundational per-archetype test battery in CI and on a defined cadence, maintaining versioned regression corpora, and escalating to scheduled red-team and continuous adversarial testing at higher maturity levels.

Description: ST-Infrastructure exercises the AI/HAI infrastructure the organization runs, inference endpoints, model registries, GPU / accelerator fleets, orchestrator control planes, vector-store infrastructure, AI-specific CI/CD pipelines, and feature stores, against a battery of AI-specific test classes tied directly to the threats in the TA-Infrastructure library and the requirements in the SR-Infrastructure pack. At L1, every archetype has a published test battery (model-extraction probes, cross-tenant isolation tests, GPU residual-state-clearing tests, workflow-signing enforcement tests, retrieval-extraction probes, pipeline-signing tests, feature-poisoning detection tests) plus six versioned regression corpora (model-extraction, cross-tenant-isolation, GPU-residual-state, workflow-injection, retrieval-extraction, pipeline-signing) running on a defined cadence. L2 adds per-tier scheduled red-team exercises using TA-Infrastructure L2 deep threat models and cross-archetype composition tests. L3 operates continuous automated adversarial testing and contributes findings to MITRE ATLAS, AVID, CNCF AI infrastructure advisories, and the OWASP LLM / Agentic Top 10 infrastructure patterns.

Context: Classic infrastructure testing exercises availability and performance, leaving AI-specific adversarial paths untested. An inference endpoint passes all health checks and then leaks embeddings at scale through an extraction-pattern query campaign. A GPU fleet passes scheduling tests and then allows job B to read job A's residual GPU memory. A model registry passes its access-control tests and then accepts an unsigned model artifact because the signing enforcement flag was reset by a platform update. These failures are invisible to classic infrastructure testing because classic testing was not designed for AI-specific infrastructure failure modes, model extraction (ATLAS TA0004), cross-tenant retrieval extraction (ATLAS TA0013), ML attack staging via the pipeline (ATLAS TA0012), and initial access through the inference endpoint surface (ATLAS TA0001). ST-Infrastructure closes this gap by making AI-specific infrastructure tests a first-class testing citizen and connecting them directly to the TA threat library so test coverage tracks threat coverage, not just availability coverage.

Maturity Level 1

Objective: Establish a foundational per-archetype test battery and regression corpora that run on a defined cadence, and verify that every AI/HAI infrastructure component reaches production with a passed go-live battery on record.

Activities.

A) Publish the foundational per-archetype test battery. Ship one test battery per AI/HAI infrastructure archetype targeting the top archetype threats from TA-Infrastructure and the archetype-specific SR requirements. Each test class specifies inputs, expected output, pass/fail criteria, an evidence artifact (probe result, log snippet, CI run link), and the TA threat plus SR requirement it maps to. The inference endpoint battery covers: a model-extraction probe (a sequence of prefix-completion queries sent at the rate-limit ceiling, asserting the rate-limit layer enforces the cap before query volume reaches extraction-pattern scale and the rate-limit event is logged, ATLAS TA0004 / TA0013); a cross-tenant isolation test (a request with tenant A's credentials referencing tenant B's model endpoint, version, or artifact, verified rejected and the rejection logged with tenant context, EA); a DoS / prompt-flood resilience test (inputs above the declared burst limit, asserting the rate-limit and abuse-detection layer enforces the cap and degraded-mode fallback produces a logged, non-misleading response without cascading to other tenants); a model-swap detection test (the canary slot flips when a model version changes silently before full traffic promotion); and a logging-completeness test (required log fields appear in the org-side log store within the retention SLA, ATLAS TA0013). The model registry battery covers an unauthorized-upload probe (a push without promotion rights is rejected and logged, ATLAS TA0004), a signed-artifact enforcement test (an unsigned artifact with valid promotion credentials is rejected and the policy violation logged), a lineage-required test (a promotion without a complete lineage record is blocked), and a rollback-abuse probe (a rollback to a retired version with a known critical finding requires explicit authorization and is logged). The GPU / accelerator fleet battery covers a residual-state-clearing test (job A writes a known pattern to GPU memory, then job B on the same node is verified unable to read it, ATLAS TA0012), a classification-aware scheduler test (a Critical-tier or regulated workload placed on a shared-designated node is rejected or redirected), and a credential-isolation test (job A's credentials cannot be used by job B on the same node after job A completes). The orchestrator / control plane battery covers a workflow-signing test (an unsigned workflow definition is rejected and the rejection logged, ATLAS TA0012), a per-step principal test (a step attempting to invoke a resource outside its declared principal scope is rejected), a control-plane API auth test (an unauthenticated request returns 401/403 and is logged), and an agent-state tampering test (a crafted payload attempting to modify the orchestrator's in-flight state is blocked by the state isolation boundary, AGH; ATLAS TA0012). The vector-store battery covers a cross-tenant retrieval probe (a tenant A query matching tenant B's namespace returns zero results or a namespacing error, ATLAS TA0013; EA), an embedding-extraction-at-scale test (a sequence of nearest-neighbor queries designed to reconstruct a tenant's embedding space is bounded by rate-limit and query-scope before recovery, ATLAS TA0013), and a retrieval-policy-bypass probe (a crafted query attempting to retrieve a document above the requesting principal's clearance is blocked or filtered, EA). The AI-specific CI/CD battery covers a pipeline-signing test (an unsigned pipeline definition is rejected and logged, ATLAS TA0012), a SLSA-provenance verification test (a recently promoted artifact carries a valid provenance attestation), an eval-gate enforcement test (a model without a passing eval attestation cannot be promoted), and a secrets-leak probe (a recent pipeline run's log output and artifact storage are scanned for credential patterns with zero findings asserted, ATLAS TA0001). The feature store battery covers a feature-poisoning detection test (a synthetic anomalous feature value injected into the online serving cache fires the skew alert within the declared window), an offline/online-skew alert test (a controlled skew fires the skew-monitoring alert and produces an IM ticket within the declared window), and an access-control test (a read with an identity that has no declared read rights is rejected and logged).

B) Build and maintain regression corpora. Maintain six versioned regression corpora in source control, running on a defined cadence. Each corpus entry carries a threat tag (HAI TTP + ATLAS tactic ID), source, and date added. The model-extraction corpus (20–60 prefix-completion and nearest-neighbor query patterns) runs against inference endpoint and vector-store archetypes on a monthly cadence, and before any model version promotion for Critical-tier. The cross-tenant-isolation probe corpus (20–60 cross-tenant query patterns) runs across inference endpoint, vector-store, and GPU fleet archetypes on a monthly cadence; failure blocks production promotion for Critical-tier components. The GPU-residual-state corpus (15–40 job-pair test configurations documenting memory patterns that should be inaccessible after job completion) runs quarterly or after any GPU fleet scheduling policy change. The workflow-injection corpus (20–50 crafted workflow step payloads and unsigned workflow definitions) runs against orchestrator archetypes on a monthly cadence. The retrieval-extraction corpus (20–60 query sequences probing for cross-tenant retrieval, embedding extraction at scale, and classification-label bypass) runs against vector-store archetypes on a monthly cadence. The pipeline-signing corpus (15–40 pipeline trigger attempts with unsigned definitions, missing provenance, and bypass variations) runs against AI-CI/CD archetypes on a monthly cadence. Corpora are versioned in source control with a named corpus owner and review on change; the refresh cadence is monthly minimum from three sources, internal observations (IR findings, IM incidents, red-team results), external public corpora (ATLAS technique examples, OWASP LLM / Agentic Top 10 infrastructure examples), and MLOps security research. New AI/HAI infrastructure component provisioning triggers a corpus completeness check against the component's archetype battery.

C) Operate the go-live battery and wire test failures to IM. Every AI/HAI infrastructure component must pass its archetype battery before receiving Sanctioned status in the SM-Infrastructure inventory. Go-live triggers: pre-production (all applicable archetype tests must pass before the component is promoted to production; the go-live test record is linked from the SM-Infrastructure inventory and the PC intake artifact); post-configuration-update (any GPU scheduling policy change, signing policy change, rate-limit policy change, or isolation policy change triggers a re-run of the relevant battery subset within 7 days for Critical-tier and within 14 days for High-tier); post-incident (any IM-Infrastructure incident involving the component triggers a re-run of the relevant battery subset before the incident is closed); quarterly (all active AI/HAI infrastructure components re-run their battery, with results reviewed by the named test-battery owner). All test failures route to IM-Infrastructure within one business day with a severity tag. Named battery owner per archetype is a named role, not a shared-team responsibility.

Outcome Metrics (L1).

Success Criteria.

• Per-archetype foundational test battery published for all seven archetypes (inference endpoint, model registry, GPU fleet, orchestrator, vector-store, AI-CI/CD, feature store), linked from the SM-Infrastructure inventory record and the DR/IR artifacts.
• Six regression corpora published in source control, running on a monthly-or-better cadence for Critical/High-tier components, with a named corpus owner and a monthly refresh cadence.
• 100% of AI/HAI infrastructure components reaching production in the last 90 days have a passed go-live battery on record.
• All test failures routed to IM with a 1-day handoff SLA and named owner.
• Named battery owner per archetype; automation covers ≥60% of battery items.

Maturity Level 2

Objective: Calibrate test depth per risk tier using the SM-Infrastructure L2 tier-treatment matrix, run scheduled per-tier red-team exercises using TA-Infrastructure L2 deep threat models, and test cross-archetype compositions for Critical-tier components.

Activities.

A) Tier-calibrated test battery and corpus depth. Publish a per-tier test treatment aligned to SM-Infrastructure L2's tier-treatment matrix. Critical tier: the full archetype battery at go-live with executive sign-off on results; all six corpora on a monthly cadence with a component-specific tuned corpus (probe inputs specific to this component's tenant population, model versions, query patterns, and GPU fleet configuration) maintained in addition to the archetype-level corpus; full-battery re-run within 7 days of any policy change; logging-completeness verified quarterly with findings routed to IM within 1 business day. High tier: the full archetype battery; all six corpora on a monthly cadence; full-battery re-run within 14 days of any policy change; logging-completeness verified semi-annually. Medium tier: a subset battery (top-4 threat classes); model-extraction and cross-tenant-isolation corpora on a quarterly cadence; subset-battery re-run within 30 days of any policy change; logging-completeness verified annually. Low tier: a spot-check (3 test classes) at go-live; the model-extraction corpus on a quarterly cadence; the relevant corpus subset at the next quarterly run after any policy change; logging-completeness verified at go-live.

B) Scheduled per-tier red-team exercises using TA-Infrastructure L2 threat models. Red-team cadence by tier: Critical (quarterly, 4 per year, scope derived from the TA-Infrastructure L2 per-component deep threat model, covering model-extraction campaigns against the inference endpoint, cross-tenant retrieval extraction against the vector-store, GPU residual-state composition with the inference endpoint, workflow-injection against the orchestrator, pipeline-tampering against AI-CI/CD, and feature-poisoning chains); High (semi-annual, 2 per year, scope from TA-Infrastructure L2 component deltas, covering the top-5 threats from the per-component model); Medium / Low (ad-hoc before major configuration changes or tenant expansions, with the archetype snapshot driving scope). Each exercise follows a written rules of engagement, a test plan reviewed with the component owner, an execution log, and a structured findings report (severity, root cause, ATLAS tactic ID, SR requirement traced). Cross-archetype composition tests for Critical-tier: inference endpoint + GPU fleet residual-state composition (run job A from tenant A on a GPU node, then run inference from tenant B on the same node, probing for evidence of tenant A's job residual state in tenant B's completions, ATLAS TA0004 / TA0012); orchestrator + vector-store retrieval-injection chain (craft a retrieval response from the vector store that contains workflow-injection instructions, verifying the orchestrator does not execute them, AGH; ATLAS TA0001 / TA0012); and AI-CI/CD + model registry tampering (craft a pipeline run that attempts to replace a signed model artifact in the registry with an unsigned or modified artifact, verifying registry and pipeline signing enforcement prevent the substitution, ATLAS TA0012).

C) Red-team findings to corpus pipeline. Every Critical or High-severity red-team finding produces: a new corpus entry (input, expected safe outcome, threat tag, ATLAS tactic ID, date, source reference) committed to the relevant regression corpus within 30 days; an IM-Infrastructure finding with a severity tag and the named component owner as assignee; and a TA-Infrastructure library-gap ticket if the finding was not in the archetype library, tracked with a named owner and a 30-day close SLA for Critical-tier gaps. This pipeline ensures every quarterly red-team exercise produces durable cadenced coverage for the findings it surfaces.

Outcome Metrics (L2).

Success Criteria.

• Quarterly red-team for 100% of Critical-tier components; semi-annual for 100% of High-tier; scope tied to TA-Infrastructure L2 per-component deep threat models.
• All six regression corpora running on a monthly cadence for all Critical-tier components; per-tier calibration enforced.
• ≥90% of Critical/High-severity red-team findings converted to corpus entries within 30 days.
• Cross-archetype composition tests documented and run for all Critical-tier components with composition dependencies (inference endpoint + GPU fleet, orchestrator + vector-store, AI-CI/CD + model registry).
• Per-tier SLA adherence for testing activities ≥90%.

Maturity Level 3

Objective: Operate continuous automated adversarial testing for Critical-tier infrastructure components, publish regression corpora and test patterns as open artifacts, and contribute discovered techniques to MITRE ATLAS, AVID, CNCF AI infrastructure advisories, and the OWASP LLM / Agentic Top 10 infrastructure patterns.

Activities.

A) Continuous automated adversarial testing harness. Deploy an automated testing harness that runs daily against all Critical-tier AI/HAI infrastructure components. A model-extraction generator produces novel model-extraction query sequences using mutation of the regression corpus, query-pattern variation, and rate-limit boundary probing, running against inference endpoint and vector-store archetypes (ATLAS TA0004 / TA0013). A cross-tenant isolation prober generates cross-tenant access patterns targeting namespace boundaries, IAM scope boundaries, and API key scope limits, running against inference endpoint, vector-store, and GPU fleet archetypes (ATLAS TA0013; EA). A GPU residual-state prober generates job-pair compositions for residual-state leakage testing on GPU fleet archetypes, surfacing new memory-pattern leakage paths (ATLAS TA0012). A pipeline-tampering generator generates unsigned pipeline trigger attempts, missing-provenance promotion attempts, and eval-gate bypass variations, running against AI-CI/CD and model registry archetypes (ATLAS TA0012). A retrieval-extraction seeder generates query sequences designed to reconstruct tenant embedding spaces at scale, running against vector-store archetypes (ATLAS TA0013). Findings are triaged by a named ST owner at least weekly. Novel techniques, patterns not in the TA-Infrastructure library, are fed into the TA L3 auto-proposal pipeline within 14 days. High-severity automated findings route to IM-Infrastructure within 24 hours.

B) Contribute findings to industry. Contribute anonymized, legally-vetted findings to MITRE ATLAS (new technique observations, novel model-extraction patterns, GPU residual-state leakage mechanics, pipeline-tampering paths, cross-tenant retrieval extraction methods, following ATLAS evidence-and-provenance requirements; target ≥4 contributions per year), the AI Vulnerability Database (AVID) (structured disclosure submissions for novel vulnerabilities in AI/HAI infrastructure components or their upstream dependencies, with coordinated disclosure where third-party components are involved), the CNCF AI Working Group / CNCF TAG Security (AI infrastructure security advisories and configuration guidance for inference serving, model registry, GPU scheduling, and MLOps pipeline security; target ≥2 substantive contributions per year), and the OWASP LLM / Agentic Top 10 infrastructure patterns (real-world telemetry evidence during revision cycles; target ≥2 substantive submissions per revision cycle).

C) Publish regression corpora and test patterns as open artifacts. Publish anonymized versions of the six regression corpora (model-extraction, cross-tenant-isolation, GPU-residual-state, workflow-injection, retrieval-extraction, pipeline-signing) under an open license, scrubbed of org-specific component names, tenant identifiers, and model versions. The internal corpora are a superset of the published versions with org-specific entries not shared externally. Maintain the published versions upstream; internal updates that belong upstream are proposed as contributions, not silently retained. Host or co-host at least one industry red-team benchmark per year (CNCF AI security working group, ATLAS practitioner table, or sector ISAC AI working group); collect cross-org detection-benchmark improvement data from participants.

Outcome Metrics (L3).

Success Criteria.

• ≥80% of Critical-tier AI/HAI infrastructure components under continuous automated adversarial testing with daily probe execution; novel techniques triaged into the TA-Infrastructure library within 14 days; high-severity findings routed to IM within 24 hours.
• ≥4 industry contributions per year to MITRE ATLAS, AVID, CNCF AI, or the OWASP LLM / Agentic Top 10 infrastructure patterns.
• All six open regression corpora published under a permissive license and maintained upstream.
• ≥1 industry-shared exercise hosted per year plus ≥2 participated; cross-org detection-benchmark improvement documented.

Common Pitfalls

Level 1. - Test battery reduced to a logging-completeness check and a rate-limit availability probe, no adversarial probes (model-extraction, cross-tenant isolation, GPU residual-state-clearing) are actually exercised. - Regression corpora committed to source control but not wired to a cadenced run, they exist but run only when a reviewer manually triggers them; coverage erodes after every sprint. - Go-live battery runs once pre-production but is never re-run after configuration policy changes, test coverage erodes as GPU scheduling policies, signing enforcement settings, and rate-limit configs change. - Test failures logged in a spreadsheet separate from IM, no SLA enforcement, no aging visibility, no named owner; the same failure recurs across multiple configuration changes undetected.

Level 2. - Red-team scope defined as "availability probes and rate-limit tests" but model-extraction campaigns, cross-tenant retrieval extraction, GPU residual-state composition, and pipeline-tampering are excluded, the top threat classes for Critical-tier AI infrastructure go untested. - Per-tier calibration documented in the tier-treatment matrix but the test runner applies the same corpus to all tiers, Critical components run the same tests as Low; differentiation exists on paper only. - Red-team findings route to IM but the finding-to-corpus pipeline is never executed, 12 months of Critical/High findings sit in IM as closed tickets with no corpus entries; the same vulnerabilities are re-discovered at the next exercise. - Cross-archetype composition tests scoped but not executed because no engineer owns inference-endpoint-plus-GPU testing, composition-specific failure modes (GPU residual-state leakage into inference endpoint serving) are in the threat model but not in any test.

Level 3. - Continuous harness runs extraction probes that the component's rate-limit trivially blocks, the coverage metric looks good but the probes are not exercising novel extraction techniques; new attack patterns are not generated. - Industry contributions are legally-vetted case-study summaries rather than actionable, reproducible technique descriptions, ATLAS reviewers cannot map them to a technique ID; CNCF advisories lack reproducibility notes. - Open corpora published once and then not maintained, external organizations build on a stale version while the internal corpus has 40 new entries; discrepancies surface at community exercises and damage the program's credibility. - New-technique ingestion from automated probes to the TA-Infrastructure library is manual and quarterly, by the time a novel technique reaches SR and SA updates and is reflected in controls, the technique is already being exploited in the wild.

Practice Maturity Questions

Level 1. 1. Is a per-archetype foundational test battery published for all seven AI/HAI infrastructure archetypes, with each test class tied to a TA-Infrastructure archetype threat (HAI TTP + ATLAS tactic ID) and an SR-Infrastructure requirement, defined inputs/outputs/pass-fail criteria, and an evidence artifact, and are 100% of new AI/HAI infrastructure components required to pass the battery before production Sanctioned status is issued? Evidence: Published battery documents per archetype with a TA-threat and SR-requirement traceability table; SM-Infrastructure inventory showing Sanctioned entries with a passed go-live battery record linked; sample test run with an evidence artifact attached. 2. Are six regression corpora (model-extraction, cross-tenant-isolation, GPU-residual-state, workflow-injection, retrieval-extraction, pipeline-signing) versioned in source control, running on a monthly-or-better cadence for Critical/High-tier components, with a named corpus owner and a monthly refresh cadence from internal and external sources, and are ≥90% of Critical/High-tier component changes verified to have triggered the relevant corpus run? Evidence: Source-control repository showing six corpus directories with version history and the corpus owner in CODEOWNERS; corpus run registry showing cadenced execution for the last 90 days; monthly corpus refresh commit log. 3. Are all test failures routed to IM-Infrastructure within 1 business day with a severity tag and named owner, and does TA-Infrastructure archetype threat coverage by the test battery and corpus reach ≥80% by end of year one? Evidence: IM-Infrastructure query for ST-originated issues with creation timestamps within 24 hours of test failure; threat-coverage matrix mapping TA archetype threats to battery test classes and corpus entries showing a ≥80% coverage ratio.

Level 2. 1. Are 100% of Critical-tier AI/HAI infrastructure components red-teamed at least quarterly, and 100% of High-tier semi-annually, with scope derived from TA-Infrastructure L2 per-component deep threat models, covering model-extraction campaigns, cross-tenant retrieval extraction, GPU residual-state composition, pipeline-tampering, workflow-injection chains, and feature-poisoning detection, with findings routed to IM and remediation tracked? Evidence: ST records showing red-team exercise dates per Critical and High-tier component for the last 12 months; the red-team report for the most recent Critical-tier exercise showing scope sourced from the TA L2 per-component model; IM-Infrastructure findings linked from the report. 2. Is per-tier corpus calibration enforced (Critical-tier: all six corpora on a monthly cadence plus quarterly red-team; Low-tier: the model-extraction corpus on a quarterly cadence), and are ≥90% of Critical/High-severity red-team findings converted to corpus entries within 30 days? Evidence: Test-runner configuration showing per-tier corpus routing; corpus run registry confirming the monthly cadence for Critical-tier components; finding-to-corpus pipeline telemetry showing the conversion rate and lead times. 3. Are cross-archetype composition tests (inference endpoint + GPU fleet residual-state, orchestrator + vector-store retrieval-injection, AI-CI/CD + model registry tampering) documented and executed for all Critical-tier composite components, and is per-tier SLA adherence for testing activities ≥90%? Evidence: Composition test plans per Critical-tier composite component; execution logs with pass/fail results; per-tier SLA adherence report from program telemetry for the last two quarters.

Level 3. 1. Are ≥80% of Critical-tier AI/HAI infrastructure components under continuous automated adversarial testing with daily probe execution, using model-extraction generators, cross-tenant isolation probers, GPU residual-state probers, pipeline-tampering generators, and retrieval-extraction seeders, with novel techniques triaged into the TA-Infrastructure library within 14 days and high-severity automated findings routed to IM within 24 hours? Evidence: ST harness telemetry showing daily probe execution per Critical component; harness-to-TA-library pipeline log with lead time per novel technique; IM-Infrastructure high-severity finding creation timestamps within 24 hours of automated detection. 2. Has the program contributed ≥4 anonymized, legally-vetted findings per year to MITRE ATLAS, AVID, the CNCF AI Working Group, or the OWASP LLM / Agentic Top 10 infrastructure patterns, with at least one accepted as a new or refined technique, and are all six open regression corpora published under a permissive license and maintained upstream? Evidence: Contribution log with external submission links and acceptance confirmation from ATLAS, AVID, CNCF, or OWASP; open-source repository links for the six published corpora with commit history showing active maintenance; legal review records for each submission. 3. Has the program hosted at least 1 industry-shared red-team exercise per year and participated in ≥2 additional cross-org exercises, with documented cross-org detection-benchmark improvement data from participants? Evidence: Exercise log with hosted and participated entries for the last 12 months; post-exercise report showing detection-benchmark data collected from participants; co-published results or testimonials from at least one cross-org partner.

23. Environment Hardening (EH)

Practice Overview

Objective: Harden the identity, network, compute, supply-chain, and egress/DLP envelopes that surround the infrastructure hosting and serving AI systems, inference endpoints, model registries, GPU/accelerator fleets, orchestrator control planes, vector-store infrastructure, AI-specific CI/CD, and feature stores, so each archetype runs in a least-privilege, observable perimeter and unsanctioned data movement across infrastructure boundaries is detectable before it causes harm.

Description: EH-Infrastructure tunes the organization's existing cloud, network, identity, and pipeline controls for the specific surfaces that AI-hosting infrastructure creates. Five envelope dimensions are in scope: the identity envelope (workload identity for every infrastructure component with no long-lived service-account keys, just-in-time human admin access, SSO + MFA on cloud, registry, vector-store, and orchestrator consoles, and an audit log for every console action); the network envelope (private endpoints for internal inference clusters, egress allow-lists scoped to LLM-provider domains and own-VPC only, per-tenant network segmentation, and service-mesh mTLS between inference and storage tiers); the compute envelope (workload-namespace isolation per archetype, GPU residual-state clearing between tenants and jobs, classification-aware scheduling that prevents lower-classification workloads from landing on nodes carrying higher-classification residual state, and cgroup and quota enforcement); the supply-chain envelope (signed container images, SBOM for all AI-infra components, a base-image patch SLA, signed model artifacts in the registry, and signed CI/CD pipeline definitions); and the egress/DLP envelope (DLP rules tuned for AI-infra-specific exfiltration, bulk model-weight download, mass-embedding extraction, and training-data export, with classification-aware egress policy preventing regulated content from crossing a boundary without an explicit approval gate).

Context: AI infrastructure accumulates risks that cloud-security baselines were not designed for. A model registry exposed on a public endpoint lets anyone download fine-tuned weights containing training-data memorization. A GPU node that clears memory only on OS reboot leaks tensor residuals from one tenant's inference job into the next. An orchestrator control plane with standing admin credentials gives an attacker who compromises one workflow lateral access to every workflow in the cluster. An inference endpoint with no ingress policy gets enrolled in a prompt-abuse campaign because its URL was discovered by scanning. EH-Infrastructure closes these gaps not by adding new tooling but by tuning controls the organization already operates, IAM, network policies, node configuration, container signing, CI/CD secrets management, for the seven archetypes that make up the AI infrastructure surface. The HAI TTPs EA, AGH, TM, and RA are mitigated here at the perimeter level: EA via least-privilege workload identity and egress allow-lists; AGH and RA via orchestrator control-plane isolation and per-workflow service-account scoping; TM via tool-scope enforcement at the runtime envelope and per-namespace default-deny. Controls cross-reference the Cloud-Controls-Taxonomy, and standing-IAM risks are tracked against the Cloud-Threat-Taxonomy.

Maturity Level 1

Objective: Harden the identity, network, compute, supply-chain, and egress/DLP envelopes for all seven AI infrastructure archetypes so each component runs under a least-privilege, observable perimeter and AI-specific exfiltration paths are controlled.

Activities.

A) Harden the identity and network envelopes. Every AI infrastructure archetype registered in the SM-Infrastructure inventory, inference endpoint / model-serving cluster, model registry, GPU/accelerator fleet job runner, orchestrator / control plane, vector-store infrastructure, AI-specific CI/CD, and feature store / online serving cache, runs under a platform-native workload identity (AWS IAM Roles for Service Accounts, GCP Workload Identity Federation, Azure Managed Identity, or a Kubernetes service account with OIDC) rather than a static service-account key or shared credential; any component using a long-lived key is a blocking finding, keys discovered in configuration are rotated immediately, and the workload is migrated to workload identity within 30 days. No standing admin permissions exist on any AI infrastructure component, human operators request access just-in-time (sessions ≤4 hours, approval-gated, scoped to the specific archetype component). Model registry, vector-store, orchestrator, and cloud-provider ML platform consoles (SageMaker, Vertex AI, Azure ML, Bedrock) and AI-specific CI/CD UIs all require SSO/SAML/OIDC with MFA; local-account access is disabled for org-domain identities; every human console action (create, update, delete, promote, download, configuration change) is written to an append-only audit log whose access is separated from the archetype operator role. On the network envelope, inference endpoints serving internal consumers use private endpoints / VPC-internal load balancers only, public ingress requires explicit approval, documentation, and WAF coverage; egress from inference-endpoint and model-registry workload identities is allow-listed to declared LLM-provider API domains and own-VPC destinations only, with unexpected outbound traffic to undeclared AI-provider domains raising a shadow-inference-endpoint alert routed to SM-Infrastructure intake; multi-tenant inference clusters enforce per-tenant network namespaces (Kubernetes NetworkPolicy, VPC subnet per tenant, or equivalent) at the infrastructure layer; service-mesh mTLS is enforced on all inference-to-storage and inference-to-registry paths.

B) Harden the compute and supply-chain envelopes. Each archetype workload runs in a dedicated Kubernetes namespace (or cloud-equivalent isolation boundary) with its own service account, default-deny namespace egress, and an explicit NetworkPolicy allow rule for any cross-namespace access. GPU/accelerator nodes enforce a clearing routine between jobs that wipes GPU memory before the next job's container starts; the clearing routine emits a residual-state-clearing event, and a clearing failure is treated as blocking, the node is drained and taken offline until clearing is confirmed. The scheduler enforces node-pool separation by data classification tier: a job tagged Confidential or higher lands only on a dedicated node pool, and untagged jobs are blocked from classified node pools. CPU, memory, and GPU quota limits are set per workload namespace so no unbounded GPU allocations are possible from unregistered identities. On the supply-chain envelope, all container images for AI infrastructure components are signed at build time using Sigstore / cosign / Notary v2 or equivalent, and admission controllers (OPA Gatekeeper, Kyverno, or cloud-native policy) reject unsigned images; an SBOM in SPDX or CycloneDX format is generated at build time for each archetype image, stored in the artifact registry linked to the image digest, and checked against known-vulnerability feeds on every build. Base OS images are patched on a published SLA, critical CVEs ≤7 days, high CVEs ≤30 days. Model artifacts promoted to the registry carry a cryptographic signature and a provenance attestation (training job ID, eval-gate result, approver identity) verified by the registry's promotion gate; AI-specific CI/CD pipeline definitions are version-controlled and signed, and any unsigned or unreviewed pipeline definition touching model promotion or artifact signing is a blocking finding.

C) Harden the egress/DLP envelope. Existing DLP rules are extended to cover patterns specific to AI infrastructure exfiltration: bulk model-weight download from the registry (download of model-checkpoint files exceeding a volume threshold to external destinations), mass-embedding extraction from the vector store (high-volume retrieval or export of embedding vectors to unmanaged destinations), and training-data export from AI CI/CD (bulk export of dataset files from CI/CD artifact stores or pipeline caches); DLP rules alert or block based on the classification of the content being exported. A classification-aware egress policy attached to each archetype's workload identity prevents regulated data (PII, PHI, PCI) from leaving the AI infrastructure boundary without an explicit approval gate and blocks outbound traffic to non-allow-listed destinations; a shadow-model-serving alert fires when a new inference endpoint appears in cloud API discovery that is not in the SM-Infrastructure inventory. The DLP and egress instrumentation produces the network-flow and identity signals that ML-Infrastructure L1 consumes; hardening gaps surfaced here are opened as IM-Infrastructure findings.

Outcome Metrics (L1).

Success Criteria.

• 100% of AI infrastructure archetype components running under workload identity with no long-lived service-account keys in any archetype's runtime configuration; confirmed by IAM audit.
• SSO + MFA enforced on all AI infrastructure consoles; every console action logged to an append-only audit log.
• GPU residual-state clearing enforced and logged on 100% of GPU/accelerator nodes with no clearing failures outstanding.
• 100% of Critical/High-tier AI infrastructure container images signed and SBOM-tracked; unsigned images rejected at the deployment gate; signed model artifacts required for registry promotion.
• DLP rules for AI-infra-specific exfiltration patterns deployed and active; classification-aware egress policy enforced on all archetype workload identities.

Maturity Level 2

Objective: Calibrate hardening depth per the SM-Infrastructure L2 risk tier (Critical / High / Medium / Low), apply zero-trust AI infrastructure access for Critical-tier, enforce infrastructure-layer per-tenant isolation, and tune supply-chain controls to SLSA L3+ for Critical-tier.

Activities.

A) Tier-conditional hardening calibration. Publish and enforce a hardening tier-treatment matrix aligned to the SM-Infrastructure L2 risk-tier rubric. Critical: per-component workload identity with OIDC token rotation ≤1 hour and JIT-only human admin with no standing access; a dedicated VPC / VNet endpoint with no public ingress and service-mesh mTLS on all paths; a dedicated GPU node pool with clearing enforced and logged and no cross-tenant scheduling; an HSM-rooted CMK per archetype rotated ≤30 days; SLSA L3+ supply-chain provenance with a base-image patch SLA ≤7 days for critical CVEs; a registry promotion gate enforcing signature and SLSA L3 provenance with JIT approval-gated download; content-inspection DLP on model-weight downloads and embedding extractions; and infrastructure-layer per-tenant isolation. High: per-component workload identity scoped to declared resources; private endpoints with WAF for any public ingress; a dedicated GPU pool with clearing enforced; a KMS CMK per archetype rotated ≤90 days; SLSA L2 with signed images, SBOM, and a base-image patch SLA ≤14 days; standard AI-infra DLP; infrastructure-layer per-tenant isolation preferred with app-layer minimum. Medium: per-component workload identity, private endpoints preferred, a shared GPU pool with namespace isolation, a shared KMS CMK rotated ≤180 days, signed images with SBOM, standard DLP, app-layer isolation. Low: the L1 baseline. Each SM-Infrastructure archetype record carries its tier's hardening status; gaps between required and actual controls are open IM-Infrastructure findings, and the matrix is enforced at provisioning and re-run on tier change.

B) Zero-trust AI infrastructure access for Critical-tier. For Critical-tier inference endpoints, model registries, GPU fleet management consoles, orchestrator control planes, and vector-store admin interfaces there are no standing admin permissions, all access is just-in-time (sessions ≤4 hours, approval-gated, scoped to the specific component and action), and standing access of any kind is a blocking finding at the next IR-Infrastructure review. Encryption keys for Critical-tier model artifacts, inference-endpoint storage, GPU-fleet job outputs, and vector-store embedding indices are managed under a dedicated HSM-rooted CMK (AWS CloudHSM, Azure Dedicated HSM, GCP Cloud HSM, or equivalent), not shared across archetype components or tenants. CI/CD pipelines for Critical-tier components and model promotion workflows produce SLSA L3+ provenance attestations from hermetically sealed builds, verified by the deployment admission controller before any Critical-tier component is deployed. Critical-tier inference clusters and model-registry backends run in a dedicated VPC or VNet with no shared routing with non-Critical-tier workloads; VPC endpoints replace any public internet egress path, and VPC flow logs are retained at full fidelity for the tier's longest applicable regulatory window.

C) Infrastructure-layer per-tenant isolation and adaptive tightening. Critical-tier inference endpoints and vector stores serving multiple tenants enforce tenant boundaries at the infrastructure layer, a dedicated Kubernetes namespace per tenant with NetworkPolicy default-deny, a dedicated node pool per tenant, or a separate inference cluster per tenant; application-layer routing without infrastructure-layer isolation is not sufficient for Critical-tier. Each tenant's embeddings in the vector store and each tenant's model artifacts in the registry are encrypted under a separate CMK; shared-key architectures for Critical-tier multi-tenant stores are a blocking finding. Per-tenant isolation is verified by the IR-Infrastructure implementation review (annual minimum for Critical-tier) and confirmed by an ST-Infrastructure isolation test wired into CI. ML-Infrastructure detection signals (shadow-inference-endpoint detection, GPU clearing failure, vector-store mass-extraction) and IM-Infrastructure incident patterns (post-incident hardening gaps) are wired to a human-approved adaptive-tightening pipeline: signals generate tightening proposals, proposals are reviewed by the security platform engineering team before deploy, the change log is machine-readable, and downstream teams are notified within 24 hours.

Outcome Metrics (L2).

Success Criteria.

• 100% of Critical-tier archetype components with dedicated VPC + HSM-rooted CMK + JIT-only human admin access.
• ≥90% of Critical-tier build and model-promotion pipelines producing SLSA L3+ provenance attestations verified at deployment.
• ≥90% of Critical-tier multi-tenant inference and vector-store components with infrastructure-layer per-tenant isolation confirmed by IR review and ST isolation test.
• Tier-hardening matrix published and enforced at provisioning and on tier change; SM-Infrastructure inventory records show hardening status per tier; gaps are open IM-Infrastructure findings; adaptive-tightening pipeline operational from ML and IM signals.

Maturity Level 3

Objective: Express all EH-Infrastructure controls as Terraform / Pulumi / Helm IaC modules, drive adaptive policy tightening from ML-Infrastructure detections and IM-Infrastructure incidents, auto-provision tier-appropriate hardening for new components, and contribute AI infrastructure hardening baselines to CNCF, OpenSSF AI, and sector ISACs.

Activities.

A) Hardening-as-code: IaC for all EH-Infrastructure controls. Express every EH-Infrastructure control as a version-controlled, parameterized, forkable IaC module in a module registry: an identity-envelope module for workload-identity binding per archetype, JIT access policy, SSO enforcement on AI-infra consoles, and audit-log pipeline wiring; a network-envelope module for VPC / VNet private-endpoint configuration, NetworkPolicy default-deny templates, service-mesh mTLS configuration, and egress allow-list rules; a compute-envelope module for namespace isolation templates (ResourceQuota, LimitRange, NetworkPolicy), GPU node-pool configuration with a clearing-enforcement DaemonSet, classification-aware node-selector and taint/toleration definitions, and cgroup quota enforcement; a supply-chain module for the Sigstore / cosign signing pipeline, SBOM generation, SLSA provenance generation, and admission-controller signature and SBOM verification policy parameterized by tier (SLSA L2 for High, SLSA L3+ for Critical); and an egress/DLP module expressed as configuration-as-code for the CASB/DLP platform in use. Modules are version-pinned, and module updates notify consuming archetype teams with a required-remediation flag. A drift-detection pipeline runs hourly against all deployed archetype configurations; low-risk drift (configuration noise, metadata changes) is auto-remediated, while high-risk drift (a workload identity replaced with a static key, a public endpoint opened on an inference cluster, an unsigned image deployed, a GPU clearing DaemonSet removed) triggers a human-review alert within 2 business days and opens an IM-Infrastructure finding.

B) Adaptive policy tightening from ML-Infrastructure and IM-Infrastructure signals. Wire ML-Infrastructure detection signals and IM-Infrastructure incident patterns to a human-approved adaptive-tightening pipeline. ML-Infrastructure signals: a GPU residual-state clearing failure trend produces a node-drain-and-clearing-audit proposal; a vector-store mass-extraction pattern produces a retrieval-rate-limit tightening proposal and an egress-policy narrowing proposal; a shadow-inference-endpoint detection produces an egress-block proposal and an SM-Infrastructure intake alert. IM-Infrastructure signals: a post-incident review identifying a hardening gap produces a hardening-baseline update proposal, and a Critical-tier incident involving a compromised supply-chain component produces a SLSA-level upgrade proposal for the affected tier. Proposals are human-reviewed by a security platform engineer before deploy; the change log is machine-readable; downstream archetype teams are notified within 24 hours of a tightening change that affects their component's hardening profile. Hardening changes that reflect a new threat pattern are fed back to the TA-Infrastructure archetype threat library and to the SR-Infrastructure requirements pack as candidate new requirements, the adaptive loop is bidirectional.

C) Contribute hardening baselines and auto-provision new components. Contribute anonymized AI infrastructure hardening baselines to industry: Kubernetes workload-identity patterns for AI inference, a GPU residual-state clearing reference implementation, and NetworkPolicy templates for AI-archetype isolation to CNCF TAG Security; signed-artifact pipeline templates (cosign + SLSA provenance + admission-controller policy) for the model registry and AI CI/CD to the OpenSSF AI Infrastructure Working Group; and sector-relevant hardening advisories covering inference-endpoint access control, model-registry supply-chain controls, and GPU residual-state management to sector ISACs (FS-ISAC, H-ISAC, IT-ISAC AI working groups). Target ≥2 substantive contributions per year, maintained upstream, with internal practice aligned to the published external version. Auto-provisioning fires on SM-Infrastructure inventory registration: when a new AI infrastructure archetype component is registered, the IaC automation provisions its tier-appropriate hardening profile within 24 hours, there is no manual hardening backlog, and a tier-change signal triggers a hardening-profile upgrade.

Outcome Metrics (L3).

Success Criteria.

• ≥90% of EH-Infrastructure controls expressed as authoritative IaC; drift detected continuously; ≥70% of low-risk drift auto-remediated; high-risk drift human-reviewed within 2 business days.
• Adaptive-policy pipeline operational with ML-Infrastructure and IM-Infrastructure signal sources; every change traceable to a source signal; downstream teams notified within 24 hours.
• New AI infrastructure archetype components auto-provisioned with tier-appropriate hardening within 24 hours of SM-Infrastructure registration.
• ≥2 industry hardening baseline contributions per year (CNCF TAG Security, OpenSSF AI, sector ISACs) with documented adoption.

Common Pitfalls

Level 1. - Workload identity is configured for inference endpoints but not for the AI CI/CD pipeline runner, the runner that promotes model artifacts to the registry uses a long-lived service-account key stored as a CI/CD secret, and a supply-chain compromise of the runner gives persistent registry write access. - GPU residual-state clearing is documented in the node configuration spec but the clearing DaemonSet is not deployed, clearing runs only on OS reboot, and tenant A's inference job leaves tensor residuals that tenant B's job reads at the start of the next session. - The model registry requires SSO on the web console but the registry API endpoint accepts static-token authentication, an attacker who obtains a token bypasses SSO entirely because the SSO enforcement is a UI control, not a policy control. - DLP rules are a copy of the generic "sensitive data" template with no AI-infra patterns, bulk model-weight downloads and mass-embedding extractions go undetected because the engine does not recognize high-dimensional float arrays or checkpoint file extensions as exfiltration signals.

Level 2. - HSM-rooted keys are provisioned for the Critical-tier model registry but the GPU fleet's job-output storage still uses the platform default key, an attacker who compromises the GPU storage reaches fine-tuned checkpoints whose inference-endpoint counterpart is under HSM protection, so the key-separation benefit is incomplete. - SLSA L3+ is declared for Critical-tier but the hermetic build requirement is not enforced, the CI/CD runner makes an outbound call to fetch a dependency at build time, the build is not hermetic, and the SLSA L3 claim fails attestation verification. - The JIT access policy is published for Critical-tier but the tooling to enforce it is not wired to the cloud IAM provider, engineers continue using standing API tokens for the orchestrator control plane, and the policy exists in the matrix but not in the IAM configuration. - The tier-hardening matrix is enforced only at initial provisioning, not on tier changes, when a Medium-tier inference cluster is re-tiered to Critical after a contract change, it continues to operate with Medium-tier controls because the provisioning automation does not re-run.

Level 3. - IaC coverage is declared at ≥90% but the registry counts modules with an IaC stub rather than modules whose IaC is the authoritative deployed source, live GPU node-pool configuration hand-patched after a CUDA emergency diverges from the IaC, and auto-remediation reverts the CUDA patch. - The adaptive-policy pipeline is wired to ML-Infrastructure detections but not to IM-Infrastructure incidents, post-breach hardening opportunities identified in IR post-incident reviews never convert to tightening proposals. - Industry hardening baselines are contributed to CNCF but not maintained upstream, internal practice advances to a new clearing DaemonSet for next-generation accelerators while the CNCF reference artifact reflects the previous-generation implementation, and external adopters file issues against stale guidance. - The auto-provisioning trigger reads a stale tier field, a Critical-tier inference cluster registered with a temporary Medium-tier designation during intake receives Medium-tier hardening, and the corrected tier 24 hours later does not trigger an upgrade because the pipeline does not watch tier-change events.

Practice Maturity Questions

Level 1. 1. Does every AI infrastructure archetype component in the SM-Infrastructure inventory (across all seven archetypes, inference endpoint, model registry, GPU fleet, orchestrator, vector-store, AI CI/CD, feature store) run under a dedicated workload identity with no long-lived service-account keys, and do all AI infrastructure consoles require SSO + MFA with every console action written to an append-only audit log? Evidence: IAM audit × SM-Infrastructure inventory reconciliation; IdP configuration audit; append-only audit-log sample. 2. Are GPU/accelerator nodes enforcing residual-state clearing between jobs with clearing events logged so that any clearing failure drains the node within 4 hours, and are all Critical/High-tier AI infrastructure container images signed, SBOM-tracked, and rejected at the deployment gate if unsigned, with signed model artifacts required for registry promotion? Evidence: node configuration audit × clearing-event telemetry; artifact registry signing report; registry promotion-gate policy export. 3. Are DLP rules tuned for AI-infra-specific exfiltration (bulk model-weight download, mass-embedding extraction, training-data export from CI/CD) deployed and active, with classification-aware egress policy enforced on archetype workload identities and inference endpoints blocked from unauthorized public ingress? Evidence: DLP management console policy export; egress-policy configuration per workload identity; cloud network policy audit.

Level 2. 1. Are 100% of Critical-tier archetype components running under a dedicated VPC with an HSM-rooted CMK per archetype, JIT-only human admin with no standing access (≤4-hour sessions, approval-gated), and SLSA L3+ provenance attestations verified at deployment, confirmed by IAM audit and IR-Infrastructure review? Evidence: network + KMS policy audit × SM inventory; IAM audit telemetry; CI/CD provenance registry; IR review records. 2. Are ≥90% of Critical-tier multi-tenant inference endpoints and vector stores enforcing per-tenant isolation at the infrastructure layer (dedicated namespace + NetworkPolicy + per-tenant CMK), confirmed by IR-Infrastructure implementation reviews and ST-Infrastructure isolation tests wired into CI? Evidence: IR findings × SA pattern conformance; ST isolation-test results in CI. 3. Is a tier-hardening matrix published and enforced at provisioning and on tier change, with SM-Infrastructure inventory records showing hardening status per tier, gaps tracked as open IM-Infrastructure findings, and an adaptive-tightening pipeline operational from ML-Infrastructure and IM-Infrastructure signals? Evidence: published tier-treatment matrix; provisioning-gate configuration; SM inventory hardening-status records; adaptive-tightening change log.

Level 3. 1. Are ≥90% of EH-Infrastructure controls expressed as authoritative IaC (not stubs) in a version-controlled module registry, with drift detected continuously, ≥70% of low-risk drift auto-remediated with a machine-readable change log, and high-risk drift human-reviewed within 2 business days? Evidence: IaC module registry inventory; drift-detection telemetry; auto-remediation rate; change-log export. 2. Is the adaptive-policy pipeline operational, with ML-Infrastructure detections and IM-Infrastructure incidents generating human-approved policy-tightening proposals on a tracked cadence, every change traceable to a source signal, and downstream archetype teams notified within 24 hours? Evidence: adaptive-policy change log with ML/IM source references; human-approval records; downstream-team notification log. 3. Does the program contribute ≥2 AI infrastructure hardening baselines per year to industry bodies (CNCF TAG Security, OpenSSF AI Infrastructure, sector ISACs) with documented adoption, and are new AI infrastructure archetype components auto-provisioned with their tier-appropriate hardening profile within 24 hours of SM-Infrastructure inventory registration? Evidence: contribution log with upstream adoption references; auto-provisioning telemetry tied to SM registration events.

24. Issue Management (IM)

Practice Overview

Objective: Run a single unified backlog and a single tier-calibrated incident playbook for every AI infrastructure issue, findings from TA-Infrastructure threat snapshots, SR-Infrastructure gaps, DR-Infrastructure conditions, IR-Infrastructure drift, ST-Infrastructure failures, ML-Infrastructure detections, and external advisories, with named owners, tier-aware SLAs, AI-infrastructure-specific containment plays, and regulatory SLA tracking that never misses a notification window because of organizational diffusion.

Description: IM-Infrastructure is the clearinghouse for everything the other Infrastructure-domain practices produce. Every TA-Infrastructure threat-snapshot row carrying residual risk, every SR-Infrastructure REM accepted gap with an owner and expiry, every DR-Infrastructure approve-with-conditions item, every IR-Infrastructure drift finding, every ST-Infrastructure test failure, every ML-Infrastructure detection that fires, and every external advisory (CVEs for AI-infra components, cloud-provider security bulletins, CNCF security advisories, ATLAS updates for AI infrastructure TTPs) flows into a single prioritized backlog with named owners, tier-calibrated SLAs, and an unambiguous incident playbook. The playbook contains AI-infrastructure-specific containment plays, inference-endpoint compromise and cross-tenant breach containment, model-registry tamper containment, GPU resource-hijack and residual-state-leakage containment, orchestrator control-plane breach containment, vector-store cross-tenant-bleed and mass-extraction containment, AI CI/CD supply-chain compromise containment, and shadow-inference-endpoint containment. Pre-established escalation paths and pre-established vendor-coordination channels for Critical tier cover the CISO, Privacy/Legal, the executive sponsor, and regulator routing. Every Critical or blocker incident receives a post-incident review whose outputs flow back to SA-Infrastructure, SR-Infrastructure, EG-Infrastructure, and ML-Infrastructure.

Context: Without a unified backlog, AI infrastructure issues scatter across platform Jira projects, cloud-security queues, SRE incident channels, and ML-platform alert dashboards. TA-Infrastructure residual risks age without remediation owners. IR-Infrastructure drift findings sit in a spreadsheet that nobody updates between annual reviews. An ML-Infrastructure GPU clearing failure fires on a Friday and routes to an on-call SRE who does not recognize it as a security-relevant event. An orchestrator control plane is compromised and the first signal is customer-visible workflow misbehavior two days later. The GDPR Art. 33 72-hour clock starts at the moment the organization becomes aware of a personal-data breach, not when the responsible team finishes triaging the inference-endpoint request logs. EU AI Act Art. 73 imposes serious-incident reporting on Annex III high-risk systems hosted on the infrastructure. IM-Infrastructure closes these gaps with a single backlog, one triage rubric, AI-infrastructure-specific incident classes named in advance, and a regulatory SLA tracker covering GDPR Art. 33, EU AI Act Art. 73, HIPAA, NYDFS Part 500, PCI-DSS, FedRAMP IR, and ISO/IEC 27035 that escalates automatically as clocks approach expiry.

Maturity Level 1

Objective: Operate a single unified AI infrastructure issue backlog with a standard triage rubric, an AI-infrastructure-specific incident playbook covering the seven primary infrastructure incident classes, and regulatory SLA tracking for GDPR Art. 33, EU AI Act Art. 73, HIPAA, NYDFS Part 500, PCI-DSS, FedRAMP IR, and ISO/IEC 27035.

Activities.

A) Stand up the AI infrastructure issue backlog and triage rubric. One backlog with standardized metadata per issue: source (TA threat-snapshot residual risk / SR REM accepted gap / DR approve-with-conditions item / IR drift finding / ST test failure / ML detection alert / External, CVE for an AI-infra component, cloud-provider security bulletin, CNCF security advisory, ATLAS update, sector ISAC advisory); affected component(s) linked to the SM-Infrastructure inventory with archetype, tier, and owning team; severity (Critical / High / Medium / Low anchored to AI-infrastructure-specific axes); a named owner from the SM-Infrastructure inventory with an escalation path to the program sponsor; an SLA target; an evidence link to the originating artifact; and a regulatory flag indicating whether the issue carries a notification obligation. The AI-infrastructure severity rubric: Critical means active cross-tenant data access through an inference endpoint or vector store, confirmed GPU residual-state leakage between tenants, an orchestrator control-plane compromise with confirmed workflow execution under attacker control, a model-registry compromise with an unsigned artifact promoted to production, a personal-data breach through AI infrastructure processing that triggers GDPR Art. 33, or regulated data confirmed in transit through a shadow inference endpoint. High means a confirmed control failure in a production AI infrastructure component with potential for harm if not contained (an unsigned model artifact in production without confirmed breach, a vector-store query bypassing retrieval policy without confirmed exfiltration, a GPU clearing failure with single-tenant impact, a shadow inference endpoint detected with no confirmed regulated-data transit). Medium covers confirmed gaps in non-production components or production components with compensating controls active, an SR REM accepted-gap past expiry with no renewal, an IR drift finding on a Medium-tier component, or a base-image critical CVE not yet patched within SLA. Low captures informational items, a Low-tier component logging-baseline gap, and an SBOM missing for a non-Critical component. Published SLAs: Critical acknowledge ≤4 hours / contain ≤48 hours / root-cause ≤30 days; High ack ≤24 hours / contain ≤7 days / root-cause ≤45 days; Medium ack ≤48 hours / remediate ≤14 days; Low ack ≤5 business days / remediate ≤30 days; SLAs are per-tier calibrated at L2 per the SM-Infrastructure L2 matrix. Triage cadence: daily for Critical and new High; weekly for Medium; monthly aging review for the full backlog.

B) Publish the AI-infrastructure-specific incident playbook. Publish playbook entries for the seven primary AI infrastructure incident classes; each entry names trigger conditions, pre-assigned roles (infrastructure deployer-duty owner, cloud-security on-call, Privacy/Legal contact, executive-sponsor escalation path), step-by-step containment, artifacts to collect, evidence-capture instructions, closure criteria, and SLA targets. Inference-endpoint compromise / cross-tenant breach containment: on an ML-Infrastructure cross-tenant access detection, disable the affected inference endpoint or vector-store query path via feature flag or network policy, assess scope, perform a lineage audit of all affected tenants, evaluate the GDPR Art. 33 trigger, route to Privacy/Legal immediately, rotate access credentials, and apply infrastructure-layer per-tenant isolation remediation if absent. Model-registry tamper containment: on an unsigned-artifact or unapproved-promotion detection (ATLAS AML.T0010), freeze all model promotions to manual-approval-only mode, roll back to the last known-good model version in all affected inference endpoints, audit promotions in the past 30 days, rotate registry credentials and model-signing keys, re-verify SLSA provenance, and file a supply-chain incident report with the appropriate ISAC. GPU resource-hijack / residual-state-leakage containment: on a clearing-failure event or an ST residual-state test finding, drain affected nodes immediately, audit the clearing configuration for root cause, assess which workloads ran on the affected nodes and in what order, evaluate GDPR Art. 33 and sector cloud notification obligations, remediate the clearing configuration, and verify clearing before returning to production. Orchestrator control-plane breach containment: on a workflow-injection detection (step-principal mismatch) or workflow-integrity test failure, kill all active workflows, rotate orchestrator credentials and API tokens, audit agent-state events for the affected window, assess and where needed roll back downstream-system writes, review the workflow definition for tampered steps, and evaluate GDPR Art. 33 and EU AI Act Art. 73. Vector-store cross-tenant-bleed / mass-extraction containment: on an extraction-pattern detection or a DLP bulk-embedding-export alert, disable the vector-store query path for the affected principal or tenant, assess scope, apply a classification-gated query allow-list, evaluate GDPR Art. 33 for embedding-inversion risk, and notify affected tenants per SLA. AI CI/CD supply-chain compromise containment: on a pipeline-integrity failure or external CI/CD advisory, freeze all AI CI/CD pipelines to manual-approval-only mode, audit pipeline runs in the past 30 days against the declared service-account allow-list, replay the eval suite against artifacts promoted in the affected window, re-verify signatures and SBOMs, rotate runner credentials and signing keys, and assess a supply-chain notification to the sector ISAC. Shadow-inference-endpoint containment: on a shadow-endpoint detection or an egress allow-list alert, apply an egress block on the identified endpoint, identify the owning team and component, route the component through SM-Infrastructure intake, conduct a data-flow assessment, and evaluate GDPR Art. 33 and EU AI Act Art. 73 if regulated data transited an LLM-provider endpoint without a valid DPA.

C) Track regulatory SLAs and run post-incident reviews. The regulatory SLA tracker is live with named obligations and automated escalation as deadlines approach. GDPR Art. 33: a 72-hour supervisory-authority notification window after the controller becomes aware of a personal-data breach, with the clock starting on the first internal alert that constitutes awareness; named owner Privacy/Legal; the backlog record is flagged with the clock-start time and a daily status update is required until the notification is filed or the clock expires. EU AI Act Art. 73: serious-incident reporting for an Annex III high-risk system hosted on the infrastructure, on the timeline set by the implementing act; named owner Privacy/Legal plus executive sponsor. HIPAA: a 60-day discovery-to-notification ceiling for AI infrastructure processing PHI; named owner Privacy/Legal. NYDFS Part 500: 72-hour notification to the Superintendent for material cybersecurity events; named owner CISO plus Privacy/Legal. PCI-DSS: cardholder-data breach notification for AI infrastructure components in the cardholder data environment. FedRAMP IR: incident reporting to the FedRAMP ISSO and JAB within 1 hour of detection for high-severity incidents; named owner Cloud Security / FedRAMP ISSO. ISO/IEC 27035: the procedural baseline for all AI infrastructure incident response; named owner CISO / Infrastructure Security. Every Critical or blocker incident receives a post-incident review within 14 days of containment covering what happened (root cause, initiation path, controls that failed or were absent), what caught it (which ML detection, IM source, or external report surfaced it first and whether this was the expected detection path or a gap), what did not catch it (controls that should have detected or prevented it but did not), and update outputs to SA-Infrastructure (a pattern-update request if an architectural gap was exploited), SR-Infrastructure (a requirements-pack update if a missing or vague requirement was exploited), EG-Infrastructure (a training-content update if the incident indicates a literacy gap), and ML-Infrastructure (a detection-update request, new detection, tuned query, or sharpened existing query). All four update outputs must be populated for Critical incidents; post-incident review outputs are tracked as IM-Infrastructure issues of type "improvement" and age against the same process-metric cadence as other issues.

Outcome Metrics (L1).

Success Criteria.

• Single AI infrastructure issue backlog operational with standardized metadata; AI-infrastructure-specific severity rubric published.
• Seven AI-infrastructure-specific playbook entries (inference-endpoint compromise / cross-tenant breach, model-registry tamper, GPU resource-hijack / residual-state leakage, orchestrator control-plane breach, vector-store cross-tenant-bleed / mass-extraction, AI CI/CD supply-chain compromise, shadow inference endpoint) published with pre-assigned roles, containment plays, evidence-capture steps, and SLA targets; each exercised in at least one tabletop in the last 12 months.
• Regulatory SLA tracker live covering GDPR Art. 33, EU AI Act Art. 73, HIPAA, NYDFS Part 500, PCI-DSS, FedRAMP IR, and ISO/IEC 27035; 100% adherence in the last 90 days.
• Post-incident review loop wired to SA-Infrastructure, SR-Infrastructure, EG-Infrastructure, and ML-Infrastructure; every Critical/blocker incident produces a review within 14 days with named update outputs per downstream practice.

Maturity Level 2

Objective: Calibrate incident response depth per the SM-Infrastructure L2 risk tier, operate dedicated 24/7 on-call coverage and pre-staged escalation for Critical-tier infrastructure components, auto-flow post-incident review outputs to SA/SR/EG/ML practice backlogs, and activate cross-domain coordination when an Infrastructure-domain incident implicates the Software, Data, or Processes domains.

Activities.

A) Tier-calibrated incident playbook and on-call. Extend the L1 playbook entries with tier-specific activation criteria and on-call coverage. Critical tier: full IM activation, the CISO or delegate plus Privacy/Legal plus the infrastructure deployer-duty owner plus executive-sponsor notification; ≤1 hour acknowledgement; ≤4 hours containment-action initiated; 24/7 on-call coverage with a named AI infrastructure incident responder in each on-call rotation; pre-staged communication templates (internal, customer-facing, regulatory) reviewed quarterly; and a dedicated infra-on-call rotation briefed with the current Critical-tier component list and their active detection set. High tier: a scoped response team, the Infrastructure Security lead plus Privacy/Legal if regulated data is involved plus the deployer-duty owner; ≤4 hours acknowledgement; ≤24 hours containment-action initiated; business-hours on-call with an after-hours escalation path. Medium tier: standard response; ≤1 business day acknowledgement; queue-based triage. Low tier: tracked in the queue with aggregated weekly handling. Tier-movement in the SM-Infrastructure inventory auto-triggers an IM configuration update, when a component is re-tiered to Critical, the on-call path, playbook variant, and SLA targets are updated within 14 days.

B) Post-incident review auto-flow integration. Wire IM-Infrastructure's post-incident review outputs to downstream practice backlogs via a defined integration: an SA-Infrastructure pattern-update request auto-creates an architecture-backlog ticket with the IM incident reference linked; an SR-Infrastructure requirements-pack update request auto-creates a pack-backlog ticket with the requirements-pack version and failing requirement row linked; an EG-Infrastructure training-content update request auto-creates a training-backlog ticket with the affected population segment and incident summary linked; an ML-Infrastructure detection-update request auto-creates a detection-registry update ticket with the detection name, current query, and proposed change linked. The SLA for downstream updates: Critical-tier post-incident review outputs must be accepted or rejected by the downstream practice owner within 14 days, and accepted updates are treated as High-severity issues in the receiving practice's backlog. The program sponsor reviews post-incident review quality quarterly, are update outputs substantive (a concrete change to a pattern, pack, curriculum, or detection) or nominal (a note saying "consider reviewing")?

C) Cross-domain coordination protocol. Publish a cross-domain coordination protocol that activates when an Infrastructure-domain AI incident implicates another domain. Infrastructure → Software: an inference-endpoint compromise exposes a Software-domain artifact's prompt/completion logs or model version, activating Software-domain EH and IM alongside Infrastructure-domain containment, with a named Software-domain IM contact on file. Infrastructure → Data: a GPU residual-state leak or vector-store mass-extraction exposes Data-domain training corpus or inference-input content, activating Data-domain IM alongside the Infrastructure-domain residual-state-leakage or mass-extraction play, with a named Data-domain IM contact on file. Infrastructure → Processes: an orchestrator control-plane compromise causes unauthorized writes to a business-process workflow, activating the Processes-domain business-continuity coordinator alongside the Infrastructure-domain orchestrator-breach play, with a named Processes-domain contact on file. Cross-domain activations share a single status board, a single IC from the primary impacted domain, coordinated remediation tracking, and a joint post-incident review spanning all affected domains; Infrastructure-incident-driven SA/SR/EG/ML updates auto-flow across all affected domains via the integration from Activity B.

Outcome Metrics (L2).

Success Criteria.

• Critical-tier MTTA ≤1 hour; MTTC ≤4 hours; 24/7 on-call coverage with a documented rotation including a current Critical-tier component briefing and rehearsed escalation paths for GPU clearing failure and shadow endpoint.
• Post-incident review auto-flow integration live; 100% of Critical-tier review outputs auto-routed to SA/SR/EG/ML backlogs; ≥90% of downstream practice owners responding within 14 days.
• Cross-domain coordination protocol published and used for 100% of multi-domain AI infrastructure incidents; named cross-domain contacts for Software, Data, and Processes verified quarterly.
• Tier-movement in the SM-Infrastructure inventory auto-triggers IM configuration updates within 14 days for Critical re-tiers and 30 days for other tiers.

Maturity Level 3

Objective: Contribute incident patterns and playbook templates to CNCF, OpenSSF AI, MITRE ATLAS, AVID, and sector ISACs, execute pre-authorized automated containment for defined low-severity high-confidence detections, and benchmark MTTR against industry peers with deltas linked to investment proposals.

Activities.

A) Industry-coordinated incident sharing and contribution. Participate in sector-ISAC AI incident-sharing programs (FS-ISAC AI working group, H-ISAC, IT-ISAC, sector-specific): consume ISAC AI incident feeds and integrate relevant advisories into the IM-Infrastructure external-advisory source, and contribute anonymized incident classification (incident type, archetype affected, ATLAS tactic tag, containment play used, MTTR achieved) on a per-incident-class basis with a target of ≥4 ISAC contributions per year. Contribute to AI infrastructure incident-taxonomy standards: to CNCF TAG Security, AI infrastructure incident severity-anchor definitions, playbook template schemas for the seven AI infrastructure incident classes, and Kubernetes-specific containment runbook patterns; to the OpenSSF AI Infrastructure Working Group, supply-chain incident response playbooks for model-registry compromise and CI/CD pipeline integrity failure; to AVID, AI infrastructure vulnerability entries for novel incident classes discovered in production (GPU residual-state leakage vectors, orchestrator injection surfaces, vector-store extraction patterns) with a target of ≥2 AVID entries per year; and to MITRE ATLAS, incident-derived technique observations or mitigation entries for AI infrastructure TTPs (cross-tenant access, model supply-chain compromise, orchestrator workflow injection) with a target of ≥1 ATLAS contribution per year.

B) Pre-authorized automated runbook decisioning. Define and publish a pre-authorization policy for automated containment actions, vetted by Privacy/Legal and the executive sponsor, covering the actions that may execute without human triage delay when a detection fires at a defined confidence threshold. The pre-authorized list includes an egress block for a first-time-detected shadow inference endpoint on non-Critical-tier components, a GPU node drain on a residual-state clearing failure for Medium-tier or lower nodes (drain plus clearing-audit trigger, no workload restart until a human confirms clearing succeeded), a vector-store retrieval-policy block for a principal exceeding the mass-extraction threshold on a non-Critical-tier store, and a pipeline execution freeze for Low/Medium-tier AI CI/CD pipelines on a pipeline-integrity-failure detection. Pre-authorized actions for Critical-tier components require human confirmation within 15 minutes; the action fires after that window if no confirmation arrives (timer-based fallback) with executive notification at fire time. All pre-authorized actions produce a full audit-log entry in the IM-Infrastructure backlog, a human-review ticket auto-created at execution time, and a notification to the component's deployer-duty owner; the pre-authorization policy is reviewed quarterly by Privacy/Legal and the executive sponsor, and any automated action that produces an unexpected outcome triggers an out-of-cycle review of the threshold.

C) MTTR benchmarking. Establish MTTR benchmarks from ISAC AI incident data exchanges, BSIMM-style observational data on AI infrastructure incident response at comparable organizations, MITRE ATLAS practitioner community data, and peer roundtables. Publish a quarterly MTTR benchmark brief to the program sponsor covering MTTR per incident class (cross-tenant breach, model-registry compromise, GPU residual-state leakage, orchestrator compromise, vector-store mass-extraction, CI/CD pipeline compromise, shadow inference endpoint), MTTR per tier, and the delta trend versus benchmark. Where MTTR is above benchmark, root-cause is mapped to a specific practice gap (a missing detection, an unclear playbook, on-call latency) with a budget-linked improvement proposal.

Outcome Metrics (L3).

Success Criteria.

• ≥4 ISAC contributions per year, ≥2 AVID entries per year, ≥1 ATLAS AI infrastructure contribution per year; all anonymized, legally vetted, maintained, and tracked for external adoption.
• ≥3 pre-authorized automated containment actions live, vetted by Privacy/Legal and the executive sponsor, producing 100% audit records plus human-review tickets; pre-authorization policy reviewed quarterly with zero unauthorized executions.
• Quarterly MTTR benchmark brief published; Critical-tier MTTR at or below benchmark for ≥4 of 7 incident classes; deltas above benchmark linked to specific practice gaps and investment proposals.

Common Pitfalls

Level 1. - The "single backlog" is created but ML-Infrastructure detection alerts continue routing to the SRE on-call Slack channel and GPU clearing failures are treated as platform-reliability events, the backlog captures DR and IR findings but misses the runtime signals that are often the first indicator of an active infrastructure attack. - Triage rubric severity anchors use generic cloud-security axes, a GPU residual-state clearing failure between tenants is triaged Low because "no service disruption," and the cross-tenant exposure is not recognized as the severity driver. - Playbook entries are published for model-registry tamper and shadow inference endpoint but roles are not pre-assigned, on the first live registry compromise the team spends the first hour deciding whether infrastructure security or the ML platform team owns the promotion freeze, not freezing it. - External CVE advisories for AI infrastructure components (vLLM, Triton, Weaviate, Apache Airflow in the ML pipeline) are not routed to IM-Infrastructure, they arrive in the cloud-security advisory feed and sit unprocessed because the component is not in that team's scope.

Level 2. - Critical-tier activation criteria are vague, a GPU residual-state clearing failure on a Critical-tier node is initially triaged as a platform-reliability issue and sits in the SRE queue for 6 hours while the GDPR Art. 33 clock runs from the moment the ML detection fired. - The post-incident review auto-flow integration is wired but downstream practice backlogs treat the auto-created tickets as nominal, the SR-Infrastructure team closes the ticket as "acknowledged" without updating the requirements pack, and the cross-tenant isolation gap recurs in the next inference-cluster deployment. - The cross-domain coordination protocol exists on paper but no IC is pre-designated for Infrastructure → Data incidents, the first vector-store mass-extraction that also constitutes a Data-domain breach produces ownership confusion as both domains wait for the other to confirm the GDPR Art. 33 clock start. - 24/7 on-call coverage is implemented but the on-call briefing is stale, a new inference cluster promoted to Critical-tier during a compliance re-assessment is not in the briefing, and on-call responders do not know its escalation path or clearing-failure play.

Level 3. - ISAC participation is limited to consuming feeds, contributions are absent, influence over AI infrastructure incident taxonomy diminishes, and feed quality degrades without reciprocal first-party intelligence. - Pre-authorized automated containment fires on a Critical-tier inference endpoint because the confidence threshold was set too loosely, a false positive from the mass-extraction detection triggers an egress block on a Critical-tier production cluster serving regulated data because the pre-authorization policy had no Critical-tier exception check. - The MTTR benchmark brief cites benchmarks from organizations with fundamentally different AI infrastructure portfolio scale, "we are at benchmark" is true but the benchmark set was chosen to flatter rather than stretch. - AVID entries are submitted once and never updated, GPU residual-state leakage vectors evolve as new accelerator architectures are deployed, and the org's entry reflects a CUDA-based clearing pattern that no longer applies to the next-generation accelerators now in the fleet.

Practice Maturity Questions

Level 1. 1. Is there a single AI infrastructure issue backlog with standardized metadata (source, affected component linked to the SM-Infrastructure inventory, severity rubric anchored to AI-infrastructure-specific axes, owner, SLA, regulatory flag, evidence link) capturing ≥95% of issues from all source practices (TA, SR, DR, IR, ST, ML, external CVEs, CNCF advisories, ATLAS updates)? Evidence: backlog audit cross-referenced against per-practice source queues for the last 90 days. 2. Is the AI infrastructure incident playbook published with seven named AI-infrastructure-specific incident classes (inference-endpoint compromise / cross-tenant breach, model-registry tamper, GPU resource-hijack / residual-state leakage, orchestrator control-plane breach, vector-store cross-tenant-bleed / mass-extraction, AI CI/CD supply-chain compromise, shadow inference endpoint), each with pre-assigned roles, containment plays, evidence-capture steps, and SLA targets, and has each class been exercised in at least one tabletop in the last 12 months? Evidence: published playbook; tabletop exercise records covering all seven classes. 3. Is the regulatory SLA tracker live covering GDPR Art. 33 (72h), EU AI Act Art. 73, HIPAA (60d), NYDFS Part 500 (72h), PCI-DSS, FedRAMP IR (1h high-severity), and ISO/IEC 27035 with 100% adherence in the last 90 days, and does every Critical/blocker incident produce a post-incident review within 14 days with named update outputs flowing to SA-Infrastructure, SR-Infrastructure, EG-Infrastructure, and ML-Infrastructure? Evidence: SLA tracker export; post-incident review records with downstream-practice update tickets.

Level 2. 1. Is a tier-calibrated incident playbook operational with Critical-tier MTTA ≤1 hour and MTTC ≤4 hours, 24/7 on-call coverage with a documented rotation including a current Critical-tier component briefing and rehearsed escalation paths for GPU clearing failure and shadow endpoint, and tier-movement in the SM-Infrastructure inventory automatically triggering IM configuration updates within 14 days for Critical re-tiers? Evidence: IM telemetry showing MTTA/MTTC distributions; on-call rotation registry with briefing; auto-update log for tier-movement events. 2. Is a post-incident review auto-flow integration live routing Critical-tier review outputs to SA/SR/EG/ML practice backlogs with ≥90% of downstream practice owners responding within 14 days, and is sponsor review of output quality occurring quarterly to distinguish substantive changes from nominal acknowledgements? Evidence: integration telemetry; downstream backlog aging report; quarterly sponsor review notes. 3. Is a cross-domain coordination protocol published and used for 100% of multi-domain AI infrastructure incidents with named cross-domain contacts for Software, Data, and Processes verified quarterly, a single IC from the primary impacted domain, and joint post-incident reviews spanning all affected domains? Evidence: published protocol; cross-domain contact registry with quarterly verification log; joint post-incident review records.

Level 3. 1. Does the program contribute ≥4 anonymized AI infrastructure incident-classification entries per year to sector ISACs, ≥2 entries per year to AVID, and ≥1 contribution per year to MITRE ATLAS AI infrastructure tactic documentation, with all contributions maintained current, legally vetted, and tracked for external adoption? Evidence: contribution log with submission dates and upstream adoption references. 2. Are ≥3 pre-authorized automated containment actions live (shadow-endpoint egress-block, GPU node drain on clearing failure, vector-store retrieval rate-limit, or AI CI/CD pipeline freeze classes), vetted by Privacy/Legal and the executive sponsor, producing 100% audit records plus human-review tickets, with the pre-authorization policy reviewed quarterly and any unexpected outcome triggering an out-of-cycle review? Evidence: pre-authorization policy; automation execution log with audit records and human-review tickets; quarterly review minutes. 3. Is a quarterly MTTR benchmark brief published to the sponsor comparing MTTR per incident class and per tier against ISAC-sourced and peer-sourced benchmarks with Critical-tier MTTR at or below benchmark for ≥4 of 7 incident classes and deltas above benchmark linked to specific practice gaps and investment proposals? Evidence: quarterly benchmark briefs for the last 12 months with benchmark sources and investment-proposal references.

25. Monitoring & Logging (ML)

Practice Overview

Objective: Establish the logging baseline per AI infrastructure archetype, operate a small high-signal detection set targeted at the top threats from TA-Infrastructure, and produce the evidence trail that proves EU AI Act Art. 12 deployer-duty logs, GDPR processor obligations, and applicable cloud-security regulatory requirements on demand inside a published SLA.

Description: ML-Infrastructure captures the signals produced by the infrastructure that hosts and serves AI systems, inference endpoints / model-serving clusters, model registries, GPU/accelerator fleets, orchestrator / control planes, vector-store infrastructure, AI-specific CI/CD, and feature stores / online serving caches. For each archetype it specifies the exact events to capture (inference request/response events, registry access events, GPU utilization and residual-state events, orchestrator control-plane events, network-flow events, IaC change events, and identity events), the retention window required to satisfy the longest applicable regulation, and the export path that supports auditor review. On top of the logging baseline it operates a bounded, purposeful detection set, each detection tied to a TA-Infrastructure archetype threat, each with a named owner, a defined query, an SLA, and an active tuning record. The resulting log corpus is the primary evidence artifact for the regulatory compliance obligations that apply to AI-hosting infrastructure, including EU AI Act Art. 12 high-risk-system logging, sector cloud regulations (FedRAMP, ISO/IEC 27001 A.12.4), and GDPR processor obligations.

Context: Logging AI infrastructure is not the same as logging classic compute infrastructure. An inference-endpoint request event requires principal identity, model version, data-classification label, token counts, latency, error code, and region alongside the HTTP status code. A GPU job event must carry the workload classification, the residual-state-clearing confirmation, and anomalous-utilization flags, not just CPU and memory metrics. A model-registry upload event must capture the signing-verification result, the promotion approval chain, and the SLSA provenance attestation reference. A vector-store query event must carry the tenant ID, the query hash (not the raw query text where regulated data may be present), the retrieved document IDs, and classification labels. None of this exists by default in cloud-native logging unless someone has explicitly instrumented the archetype's event schema. ML-Infrastructure makes that schema explicit, per archetype, from day one, so the organization is not reconstructing an evidence trail from incomplete telemetry the first time a regulator or incident demands it. ML-Infrastructure is also the upstream feed for IM-Infrastructure: detections route directly to the unified backlog, and post-incident review outputs return as detection-update requests.

Maturity Level 1

Objective: Establish the per-archetype logging baseline for all seven AI infrastructure archetypes, operate a small high-signal detection set targeting the top TA-Infrastructure threats, and produce an on-demand evidence trail satisfying EU AI Act Art. 12, applicable sector cloud regulations, and GDPR processor obligations within a published SLA.

Activities.

A) Establish the per-archetype logging baseline. Define and instrument the minimum event schema for each archetype in the SM-Infrastructure inventory. Every event record carries an event-id / correlation-id, principal (workload identity or human identity), timestamp, archetype tag, region, and classification tier, plus the archetype-specific fields, with PII scrubbing applied at the logging layer before records reach long-term storage where applicable. For the inference endpoint / model-serving cluster: request/response events with request-id, principal, model name and version, data-classification label, input and output token counts, latency, error code, region, and tenant-id; admin events for configuration change, scaling, and model swap (from-version, to-version, approver); and rate-limit / abuse events. For the model registry: registry access events (principal, artifact-id, action, download, read-metadata, list), upload events (artifact-id, uploader, hash, SLSA provenance reference, classification), promotion events (from-environment, to-environment, approver, eval-gate-result reference, signature-verification result), deletion events, and signature-verification events. For the GPU / accelerator fleet: job-schedule events (job-id, workload principal, classification, node-pool, node-id), residual-state-clearing events (node-id, prior job-id, clearing method, result), and GPU utilization / anomalous-utilization events. For the orchestrator / control plane: workflow-execution events, step-principal events (workflow-id, step-id, executing principal, tool or action invoked), control-plane API audit events for all mutations, and agent-state events. For vector-store infrastructure: query events (query-id, principal, tenant-id, query hash, retrieved document IDs, classification labels, retrieval-policy-decision result), ingest events, and retrieval-policy-decision events. For AI-specific CI/CD: pipeline-run events, eval-gate-decision events, promotion events, and signature-verification events; IaC change events (module, change type, requestor) are captured here and across archetypes. For the feature store / online serving cache: read and write events with classification labels and skew-detection events. Network-flow events (egress to declared and undeclared destinations), admin-audit events (IAM changes, network-policy changes, encryption-key rotation, region-config changes), and identity events (SSO sign-ins to AI-infra consoles, workload-identity token issuance, JIT access grants) are captured across all archetypes. Retention meets or exceeds the longest applicable requirement (EU AI Act Art. 12 high-risk-system logs ≥6 months; GDPR Art. 30 per data class and processing purpose; FedRAMP IR ≥90 days; ISO/IEC 27001 A.12.4 per the org's ISMS statement; HIPAA where applicable ≥6 years), with the longest window governing where several apply; the JSON or structured export path is tested at least annually with an on-demand pull SLA ≤24 hours; admin-audit and deployer-duty evidence tiers use write-once or append-only storage with access-control separation between infrastructure operations teams and log-store administrators.

B) Operate a small high-signal detection set. The L1 target is ≤12 detections, each tied to a TA-Infrastructure archetype threat with an owner, a detection query, an SLA (time-to-IM-ticket), and a last-tuned date; the false-positive rate is tracked per detection with a monthly tuning review. The core set: cross-tenant access attempt (a request event on a multi-tenant inference endpoint or vector store carries a principal matching tenant A while retrieval-policy-decision logs show access to tenant B's documents or model versions, fires on any mismatch between principal tenant-id and retrieved-resource tenant-id); model swap without approval (a model-swap event on an inference endpoint or a registry promotion event with no approver principal recorded or no matching eval-gate-decision event, fires on any model-version flip without an auditable approval chain); GPU residual-state clearing failure (a residual-state-clearing event with result = failure, fires immediately, the node should be drained, and routes to IM-Infrastructure as Critical); unsigned model artifact promoted to production (a registry promotion event where the signature-verification result is failure or absent); vector-store extraction pattern (a principal's query event count or retrieved-document count exceeds the archetype's declared operational profile by a configurable multiple, default 10×, within a rolling window, fires as a mass-extraction alert); CI/CD pipeline integrity failure (a signature-verification event on a pipeline artifact with result = failure, or a pipeline-run event where the triggering principal is not in the declared CI/CD service-account allow-list); orchestrator workflow injection (a step-principal event where the executing principal for a step does not match the declared service account for that step type in the workflow definition reference); and shadow inference endpoint detected (a cloud API discovery event surfaces a new inference service endpoint that does not appear in the SM-Infrastructure inventory, fires on first-seen detection per endpoint-identity pair). Each detection routes to the IM-Infrastructure backlog on fire; median detection-to-ticket time targets ≤1 hour for Critical-tier archetype components.

C) Produce and drill the deployer-duty evidence trail. ML-Infrastructure is the primary evidence source for the PC-Infrastructure compliance map; wire the log store to the compliance requirements. For EU AI Act Art. 12 high-risk-system logging: for every infrastructure archetype component assessed as hosting an Annex III high-risk AI system or a customer-facing decision-affecting output, confirm that request/response events, admin events, and identity events are captured and retained at the required window, and produce a deployer-duty evidence view for each such component. For applicable sector cloud regulations (FedRAMP IR, ISO/IEC 27001 A.12.4, NIST AI RMF MANAGE): infrastructure log completeness and retention are mapped to the active regulatory set in the PC-Infrastructure priority compliance map, and gaps between the required event schema and the deployed logging baseline are open IM-Infrastructure findings. For GDPR processor obligations (Art. 30 records of processing): for any AI infrastructure component processing personal data, inference endpoints serving user inputs, vector stores holding PII-containing embeddings, CI/CD pipelines processing training datasets with personal data, the request and ingest events with classification labels and tenant identifiers constitute the operational records of processing, and the log-store retention policy is linked to the Art. 30 record for each component. A quarterly deployer-duty drill pulls the deployer-duty evidence package for one randomly selected production archetype component per archetype within the published SLA (≤24 hours from request to assembled package); drill results are recorded and gaps route to IM-Infrastructure.

Outcome Metrics (L1).

Success Criteria.

• Per-archetype logging baseline published and instrumented for ≥90% of production AI infrastructure components, covering inference request/response events, registry access events, GPU utilization and residual-state events, orchestrator control-plane events, network-flow events, IaC change events, and identity events; PII scrubbing applied before long-term storage.
• ≤12-detection high-signal set live (core 8: cross-tenant access, model swap without approval, GPU clearing failure, unsigned model promotion, vector-store extraction, CI/CD integrity failure, orchestrator workflow injection, shadow inference endpoint), each with owner, detection query, SLA, and a monthly tuning record; false-positive rate tracked per detection.
• Retention meets the longest applicable regulatory window for every production component; export path tested at least annually.
• EU AI Act Art. 12, applicable sector cloud regulations, and GDPR processor-obligation evidence-trail wiring documented; quarterly deployer-duty drill executed inside the ≤24-hour SLA.

Maturity Level 2

Objective: Calibrate logging depth and the detection set to the SM-Infrastructure L2 tier rubric, integrate ML-Infrastructure feeds into the SIEM for cross-archetype correlation, and operate a quarterly detection-tuning loop fed by IM-Infrastructure post-incident reviews and ST-Infrastructure findings with anomaly-detection baselines for Critical and High-tier components.

Activities.

A) Tier-calibrated logging depth. Apply the SM-Infrastructure L2 tier-treatment matrix to logging configuration. Critical: a full request/response event corpus (including request content or content hash) retained for the longest regulatory window; full admin, identity, and supply-chain event corpora retained; all detections tuned to the component; and per-tenant isolation enforced at the log store so Critical-tier component logs are partitioned from other tier logs. High: a full request and admin event corpus retained, identity events at full fidelity, and core detections active. Medium: request-event summaries (no content; tokens, latency, and error retained) for the regulatory window, standard admin events, and the shadow-endpoint and clearing-failure detections active. Low: the baseline logging schema only with the shadow-endpoint detection only. For every Critical-tier component the ML-Infrastructure log store is the primary source for PC-Infrastructure compliance evidence bundles, completing inside the PC-Infrastructure L2 staleness threshold (ML logging-baseline validation ≤30 days for Critical-tier). Retention-tier calibration reconciles with SM-Infrastructure inventory tier changes, when a component is re-tiered, logging depth is updated within 14 days for a Critical re-tier and 30 days for other tiers.

B) SIEM integration and cross-archetype correlation. Ingest all tier-appropriate ML-Infrastructure log feeds into the SIEM and author and maintain at least three cross-archetype correlation rules. Registry-to-endpoint pivot: a registry promotion event for artifact-id X correlates with a model-swap event on an inference endpoint within the same time window where the swap was not pre-approved in the change calendar, fires a unified incident. Identity pivot on supply-chain compromise: a CI/CD pipeline integrity failure (an unsigned pipeline execution) correlates with a subsequent model promotion event from the same pipeline-id within the same session window, escalates to Critical regardless of tier. Vector-store mass-extraction plus JIT access anomaly: a vector-store extraction-pattern detection correlates with a JIT access grant to the vector-store admin interface from the same or a related principal in the same time window. Cross-archetype correlation alerts route to IM-Infrastructure at the tier of the highest-tier component involved, with links to the individual archetype findings preserved so correlation aids detection without harming triage.

C) Detection tuning loop and anomaly baselines. Operate a quarterly detection review cycle. IM-Infrastructure post-incident reviews that touch a logging or detection gap generate detection-update requests (a new detection, a tuned query, or a retired false-positive rule). ST-Infrastructure test findings not caught by the current detection set generate detection-gap findings routed to ML-Infrastructure. External advisory updates (MITRE ATLAS new techniques, CNCF security advisories, cloud-provider security bulletins, ATLAS updates for AI infrastructure TTPs) are assessed quarterly, and each applicable update either adds a candidate detection or updates an existing detection's query. A monthly anomaly-baseline refresh for Critical and High-tier components rebuilds the normal-behavior baseline (request volume, retrieval volume, GPU utilization distribution, model-swap frequency) from the previous 30-day window, with the anomaly threshold auto-tuning to maintain the target false-positive rate. Detections that have not fired a true positive in 90 days or that exceed a 20% false-positive rate are reviewed for retirement at the quarterly cycle.

Outcome Metrics (L2).

Success Criteria.

• Tier-calibrated logging depth applied to 100% of the SM-Infrastructure inventory with current tier assignments; Critical-tier full-corpus retention confirmed; calibration auto-updated on re-tier within 14 days.
• SIEM integration live with ≥3 cross-archetype correlation rules active.
• Quarterly detection tuning loop operating from IM-Infrastructure post-incident and ST-Infrastructure finding inputs with ≥1 net change per cycle.
• ≥90% of Critical/High-tier components with anomaly-detection baselines refreshed monthly; false-positive rate tracked and trending down.
• ML logging-baseline validation element fresh (≤30 days) for all Critical-tier components in PC-Infrastructure compliance evidence bundles.

Maturity Level 3

Objective: Express detections as code deployed through CI/CD, apply anomaly detection to the request, access, and utilization corpora for Critical and High-tier components, and contribute anonymized detection signatures and telemetry schemas to CNCF observability, OpenSSF AI, MITRE ATLAS, and sector ISACs.

Activities.

A) Detection-as-code. Every detection in the set is a version-controlled, tested artifact in source control with the detection query plus metadata (owner, SLA, ATLAS-tactic tag, false-positive threshold, last-test-result). A detection CI/CD pipeline triggers a test suite (unit tests over synthetic log data, integration tests against a log-replay environment) before production deployment, and detection deployment runs through the same change-management pipeline as the AI infrastructure IaC rather than being applied ad hoc in the SIEM console. Detection coverage is automatically checked on SM-Infrastructure inventory change events: when a new archetype component is registered or a component is re-tiered to Critical, the automation verifies that the required detection set is active for that component and opens a gap finding within 24 hours if not.

B) Anomaly detection on AI infrastructure corpora. Apply anomaly models to the request, access, and utilization corpora for Critical and High-tier archetype components. Request-volume anomaly on inference endpoints identifies sessions or service accounts whose request-volume or token-count distribution is a statistical outlier from normal operational profiles (abuse patterns, prompt-bomb campaigns, scraping sessions). Retrieval-distribution anomaly on vector stores identifies query sessions whose retrieved-document distribution shifts from baseline on a rolling window (potential systematic extraction of a specific document corpus or tenant's data). Model-swap frequency anomaly on the model registry identifies promotion frequency that deviates from the established baseline (multiple unscheduled model swaps in a short window suggesting supply-chain tampering). GPU utilization anomaly identifies node-utilization patterns that deviate from the baseline for the registered workload (potential cryptomining, an unauthorized training job, or resource hijacking). Anomaly model outputs feed the same detection-to-IM-ticket pipeline as rule-based detections, anomaly severity is tagged to the component's tier, and anomaly models are retrained monthly, retraining excludes attacker-session logs from past incidents to avoid baseline poisoning.

C) Contribute detection signatures and telemetry schemas. Contribute OpenTelemetry semantic conventions for AI infrastructure event types, inference-endpoint request spans, model-registry promotion traces, GPU-job traces, vector-store query spans, orchestrator workflow traces, to the CNCF observability working group in OTel-compatible format. Contribute detection-pattern examples for supply-chain events (unsigned model promotion, CI/CD pipeline integrity failure) and inference-infrastructure events (shadow endpoint, cross-tenant access) to the OpenSSF AI Infrastructure Working Group as reference detection modules. For each detection that corresponds to an ATLAS tactic/technique, propose or validate an AML.M00xx mitigation entry (detection-based mitigation type), prioritizing cross-tenant access, model swap without approval (ML supply-chain compromise), orchestrator workflow injection, and GPU residual-state leakage. Share anonymized, generalized detection signatures for AI infrastructure threats with sector ISACs (FS-ISAC, H-ISAC, IT-ISAC AI working groups). Target ≥2 telemetry-standard contributions per year and ≥12 ISAC detection signatures per year; all contributions are anonymized, legally vetted, and maintained rather than point-in-time submissions.

Outcome Metrics (L3).

Success Criteria.

• ≥90% of the detection set expressed as version-controlled, CI/CD-deployed artifacts; detection changes reviewed and deployed through the same change pipeline as the AI infrastructure IaC; detection coverage auto-verified for 100% of new or re-tiered SM-Infrastructure inventory entries within 24 hours.
• ≥90% of Critical/High-tier components running anomaly detection on the request, access, and utilization corpora with anomaly models retrained monthly.
• ≥2 telemetry-standard contributions per year to the CNCF observability working group or OpenSSF AI Infrastructure; ≥12 anonymized detection signatures per year to sector ISACs; ≥2 MITRE ATLAS AML.M00xx detection-mitigation entries proposed or validated.

Common Pitfalls

Level 1. - The logging baseline is defined for inference endpoints and the model registry but the GPU fleet, orchestrator, and vector-store archetypes are left on generic cloud monitoring, residual-state clearing failures, workflow-injection events, and retrieval-policy decisions are invisible until an incident forces forensic reconstruction from incomplete telemetry. - Model-registry upload and promotion events are logged at the HTTP level (status code plus endpoint) but not at the artifact level, the "who downloaded what model when" audit trail required for supply-chain incident investigation does not exist. - Vector-store query events log the raw query text instead of a query hash when regulated data may be present, the log store becomes a secondary repository of regulated data with weaker access controls than the primary data store. - The detection set includes GPU clearing failure and shadow endpoint but not model swap without approval, a silent model-version flip on a Critical-tier inference endpoint goes undetected until output-integrity regression surfaces downstream.

Level 2. - Tier-calibrated logging is configured at deployment time but not maintained, when an inference cluster is re-tiered from Medium to Critical the logging depth is not updated, and full corpora are absent when the first Critical-tier incident fires. - SIEM correlation rules are built once and never validated, a cross-archetype correlation rule that has not fired in 90 days may be broken (the log format changed after a Kubernetes upgrade) rather than evidence that no correlatable events occurred. - Anomaly baselines are established at cluster launch and never refreshed, normal usage evolves as models are swapped and traffic patterns change, and stale baselines produce false-positive spikes that overwhelm the IM team. - The detection tuning loop exists on paper but IM and ST feedback never feeds into the review cycle, the same false-positive GPU-utilization alert remains in the set for quarters because the quarterly process has no dedicated infrastructure-security owner.

Level 3. - The detection-as-code pipeline is deployed but detection tests use synthetic log data that does not resemble production infrastructure log formats, tests pass in CI and detections fail silently in production after a log-schema change in the cloud provider's managed service. - Anomaly models are retrained on the full log corpus including attacker-session logs from past incidents, a poisoned baseline teaches the model to treat past GPU residual-state clearing failures as normal operational events. - Contributed telemetry schemas are published as point-in-time artifacts and then diverge from internal practice, external adopters build against v1.0 OpenTelemetry semantic conventions while the org operates v1.3 internally and trust erodes. - ISAC detection signatures are generalized to the point of uselessness, partner organizations cannot implement cross-tenant access or vector-store extraction detections without reconstructing the tenant-id and retrieval-volume context removed for anonymization.

Practice Maturity Questions

Level 1. 1. Has a per-archetype logging baseline been published specifying the minimum event schema, fields, retention window, and export path for each AI infrastructure archetype in the SM-Infrastructure inventory (inference endpoint, model registry, GPU fleet, orchestrator, vector store, AI CI/CD, feature store), and has compliance of each production component been measured against it within the last quarter? Evidence: published baseline; logging configuration audit cross-referenced against the SM-Infrastructure inventory. 2. Is a high-signal detection set of ≤12 detections active, each with a named owner, detection query, SLA, and last-tuned date, including cross-tenant access, model swap without approval, GPU residual-state clearing failure, unsigned model artifact promotion, vector-store extraction pattern, CI/CD integrity failure, orchestrator workflow injection, and shadow inference endpoint, with false-positive rates tracked per detection and monthly tuning reviews occurring? Evidence: detection registry export; monthly tuning-review records; false-positive-rate trend per detection. 3. Has the evidence trail for EU AI Act Art. 12, applicable sector cloud regulations, and GDPR processor obligations been wired to the ML-Infrastructure log store, and has a quarterly deployer-duty drill confirmed that the evidence package for a randomly selected production component can be assembled within the ≤24-hour SLA? Evidence: documented wiring of the log store to compliance requirements; quarterly drill records for the last 12 months with assembly times.

Level 2. 1. Is tier-calibrated logging depth applied per the SM-Infrastructure L2 tier-treatment matrix, Critical-tier components retaining full event corpora at the longest regulatory window, Low-tier components receiving baseline only, and is this calibration automatically updated when a component is re-tiered? Evidence: log-store retention audit × SM-Infrastructure inventory tier assignments; re-tier auto-update log. 2. Is the SIEM ingesting ML-Infrastructure log feeds with ≥3 cross-archetype correlation rules active (covering at minimum registry-to-endpoint pivot, identity pivot on supply-chain compromise, and vector-store mass-extraction plus JIT access anomaly), and is a quarterly detection tuning cycle operating from IM-Infrastructure post-incident and ST-Infrastructure finding inputs? Evidence: SIEM rule registry; correlation-alert sample; quarterly detection change log. 3. Are ≥90% of Critical/High-tier components running anomaly-detection baselines with behavioral profiles refreshed monthly and false-positive rates tracked and trending down, and is the ML logging-baseline validation element completing inside the ≤30-day staleness threshold for all Critical-tier components in PC-Infrastructure compliance evidence bundles? Evidence: detection telemetry showing baseline-refresh cadence; false-positive-rate trend; PC-Infrastructure compliance evidence bundle freshness report.

Level 3. 1. Are ≥90% of detections expressed as version-controlled, CI/CD-deployed code artifacts with automated test coverage against realistic synthetic log data, and is detection coverage auto-verified for 100% of new or re-tiered SM-Infrastructure inventory entries within 24 hours of the inventory change event? Evidence: detection registry × source control; CI test results; automation telemetry for inventory-change events. 2. Are ≥90% of Critical/High-tier components running anomaly detection on the request, access, and utilization corpora with anomaly models retrained monthly on production log data (excluding attacker-session logs from past incidents) and anomaly-model alerts feeding the IM-Infrastructure incident backlog through the same detection-to-ticket pipeline as rule-based detections? Evidence: anomaly model registry with monthly retraining records; lineage-tracking export; IM-Infrastructure backlog showing anomaly-sourced tickets. 3. Has the program contributed ≥2 telemetry-standard artifacts per year to the CNCF observability working group or OpenSSF AI Infrastructure and ≥12 anonymized detection signatures per year to sector ISACs, and has it proposed or validated ≥2 MITRE ATLAS AML.M00xx detection-mitigation entries, with contributions maintained current and external adoption tracked? Evidence: contribution log with submission dates, upstream adoption references, and maintenance records.

Part IV, Maturity Assessment Workbook

26. How the assessment works

Scope. A single assessment covers all 12 practices in the Infrastructure domain, with 3 questions per maturity level per practice, 108 questions total. The assessment measures the organization's ability to secure the infrastructure that hosts and serves the AI/HAI systems the organization operates, inference endpoints and model-serving clusters, model registries, GPU and accelerator fleets, orchestrator and control planes, vector-store infrastructure, AI-specific CI/CD pipelines, and feature stores or online serving caches.

Cumulative levels. Maturity levels are cumulative. A practice cannot be at Level 2 unless it is at Level 1; it cannot be at Level 3 unless it is at Level 2. Score Level 1 questions before answering Level 2 questions for the same practice. This is not optional, the gate is by design.

Answers. Each question accepts one of three answers: Yes (fully implemented, evidence-backed, sustained over time, requires an artifact, telemetry pull, or process record the assessor has actually seen), Partial (partially implemented, or implemented but not sustained, or evidence is incomplete, counts as half credit), or No (not implemented, or implemented inconsistently to the point that no evidence supports it).

Evidence. Every "Yes" requires a citation in the Evidence box. "It is in the IaC repo" is not evidence. "Terraform module ai-infra/inference-endpoint v2.3, conformance-test run dated Y, IAM audit reconciliation export Z, cloud-provider asset-API listing" is.

Honesty. The assessment is for the program, not for the assessor. A "No" honestly recorded is more useful than a "Yes" that does not survive auditor scrutiny.

Cadence. Run the full assessment at least annually. Run a Level 1 self-check quarterly during the first year of program operation.

Roles. The assessment is led by the AI/HAI Infrastructure Assurance program lead working with the cross-functional working group that includes CISO and VP Infrastructure / Head of Platform Engineering co-sponsorship, the Cloud Platform lead, MLOps and ML Platform engineering, SRE, Cloud Architecture, Privacy/Legal, and FinOps. The assessor should be independent of day-to-day program operations, a peer assessor from another team or function works well; an external assessor works better. The program lead should not assess their own program. Working group members from Platform/SRE and ML Platform provide IaC, IAM-audit, and conformance-test evidence; Cloud Architecture provides reference-pattern evidence; Privacy/Legal provides compliance-map evidence; FinOps provides GPU-spend and concentration-risk evidence.

Scope boundary. This assessment covers only Infrastructure-domain practices, the compute and platform layer that AI/HAI systems run on. It does not assess "AI doing infrastructure security." The same 12 practices applied to the Software, Data, Vendors, Processes, and Endpoints domains are assessed in their own handbooks. Do not conflate Infrastructure-domain answers with answers about the software artifacts hosted, the data flowing through, or what vendors provide.

27. Scoring methodology

Two scoring approaches are supported. Use the simplified scoring for self-assessments and quarterly check-ins. Use the precise scoring for formal audits and external benchmarking.

Simplified scoring (recommended for self-assessment)

For each practice:

Level 1 achieved (all 3 Level 1 questions = Yes): 1.0 point
Level 2 achieved (all 3 Level 2 questions = Yes, AND Level 1 achieved): +1.0 (total 2.0)
Level 3 achieved (all 3 Level 3 questions = Yes, AND Level 2 achieved): +1.0 (total 3.0)

A "Partial" answer counts as half toward the level, but the level is only achieved when all three questions are at full Yes. Partial credit shows up in the precise score.

Precise scoring (recommended for formal audits)

For each practice, with Y = Yes (1.0), P = Partial (0.5), N = No (0):

L1_score = (sum of L1 answers) / 3
L2_score = (sum of L2 answers) / 3 × L1_score
L3_score = (sum of L3 answers) / 3 × L2_score

Practice Score = L1_score + L2_score + L3_score    (max 3.0)

The L2 and L3 multipliers enforce the cumulative rule, a practice cannot earn full L2 credit if L1 is incomplete.

Domain rollup.

Domain Maturity = (sum of all 12 Practice Scores) / 12    (max 3.0)

Maturity bands.

• 0.0 – 0.9, Ad-hoc. No AI/HAI Infrastructure Assurance program in operational use; AI/HAI infrastructure is provisioned without governance.
• 1.0 – 1.9, Foundational. L1 in place across most practices; inventory and provisioning gate operational; some L2 progress.
• 2.0 – 2.9, Comprehensive. L2 calibrated by risk tier across most practices; continuous validation for Critical/High instances; some L3 contributions.
• 3.0, Industry-Leading. L3 automation, benchmarking, and contribution sustained across all practices.

Worked example, precise scoring

Suppose the TA-Infrastructure practice scores as follows:

L1_score = 2.5 / 3 = 0.833
L2_score = (1.5 / 3) × 0.833 = 0.500 × 0.833 = 0.417
L3_score = (0.0 / 3) × 0.417 = 0.0

TA Practice Score = 0.833 + 0.417 + 0.0 = 1.25 / 3.0

Interpretation: the practice is solidly in the Foundational band, with a partial L2 story. The cumulative multiplier correctly suppresses L2 credit because L1 is not complete.

28. The questionnaire

The 108 questions follow. Each question has the same workbook layout: question text, answer field, evidence box, and notes box. Practice and level headings are repeated so the workbook is usable as a printout or as a standalone assessment instrument. Every question asks whether the organization secures the infrastructure that hosts and serves AI/HAI systems, never whether AI performs an infrastructure-security function.

28.1 Strategy & Metrics (SM)

SM Level 1.

Q-SM-L1-1. Is there a published AI/HAI Infrastructure Assurance program charter with a named executive sponsor (CISO co-sponsored by the VP Infrastructure / Head of Platform Engineering), a cross-functional working group (Security, Platform/SRE, Cloud Architecture, ML Platform, AI/ML Engineering, Privacy/Legal, FinOps), and clear decision rights for provisioning approval, block, exception, and go-live across all seven infrastructure archetypes (inference endpoint / model-serving cluster, model registry, GPU / accelerator fleet, orchestrator / control plane, vector-store infrastructure, AI-specific CI/CD, feature store / online serving cache)?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SM-L1-2. Does a single AI/HAI infrastructure inventory exist, seeded from cloud-provider asset APIs, Kubernetes workload signals, IaC repos, model-registry APIs, cloud-spend / GPU-spend signals, egress logs to AI provider domains, and vector-store listings, covering all seven archetypes, with ≥90% coverage of discovered infrastructure instances within 12 months?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SM-L1-3. Are the L1 outcome metrics baselined and reported quarterly to the executive sponsor, inventory coverage (≥90%), shadow-AI-infra ratio (≤15% and trending down), AI Infrastructure Standards and GPU AUP attestation coverage (≥95% of platform and SRE headcount), AI/HAI infrastructure instances in production with a named owning team (100%), and known data-exposure events from AI/HAI infrastructure?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

SM Level 2.

Q-SM-L2-1. Is every AI/HAI infrastructure instance in the inventory assigned a risk tier based on an auditable rubric covering the seven dimensions, tier of AI/HAI software hosted, multi-tenancy isolation present, customer exposure, compute scale and concentration, data classification of data passing through, decision-affecting use hosted (EU AI Act Annex III / GDPR Art. 22), and geographic scope?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SM-L2-2. Is there a published tier-treatment matrix driving differential program intensity across PC, TA, SR, SA, DR, IR, ST, EH, ML, and IM, with ≥95% of Critical-tier infrastructure instances receiving full-scope treatment (per-tenant isolation, HSM/KMS-rooted encryption, egress allowlisting, least-privilege IAM, semi-annual IR, full ST battery) in the last 12 months?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SM-L2-3. Does the quarterly shadow AI infra scoreboard report per tier and per archetype, with Critical-tier unsanctioned infrastructure in production explicitly tracked at zero, and does tier-movement get logged with rationale and reviewed by the program sponsor, including FedRAMP / regional compliance gating for Critical-tier instances in applicable contexts?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

SM Level 3.

Q-SM-L3-1. Does inventory and tier assignment auto-update from live cloud-provider API events, IaC state events, Kubernetes admission-webhook telemetry, model-registry events, GPU-spend deltas, and egress-log anomalies, with a published data-quality SLO, and is ≥80% of curation handled automatically with exception-based human review?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SM-L3-2. Does the program publish a semi-annual external-benchmarking brief comparing the program against at least five peer-comparable metrics via CNCF / OpenSSF AI / FinOps Foundation / sector ISACs / the ML-platform community, and does it drive program investment decisions?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SM-L3-3. Does the program contribute at least four substantive, anonymized artifacts per year to the AI/HAI infrastructure security ecosystem (CNCF, OpenSSF AI, FinOps Foundation, MITRE ATLAS, NIST AI RMF, CSA AI Safety Initiative, sector ISACs), and does the executive/board ROI narrative cite external benchmarks?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.2 Policy & Compliance (PC)

PC Level 1.

Q-PC-L1-1. Have the three priority AI/HAI infrastructure policies been published and formally approved, AI Infrastructure Standards Policy (per-archetype baselines for encryption, isolation, region/residency, observability minimums), GPU / Accelerator Acceptable Use Policy (who can run what, on which fleet, with what data classification), and AI Infra Intake / Provisioning Gate Policy, and is there a one-page priority compliance map tracing each requirement (EU AI Act Art. 15/12, GDPR Art. 32/44–49/33, ISO/IEC 42001, ISO/IEC 27001 A.5/A.8, SOC 2 CC6/CC7/CC8, sector-specific) to the specific policy that carries it?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-PC-L1-2. Is the provisioning gate operational with a per-archetype artifacts checklist, a published intake SLA (triage ≤5 BD; provisional approval ≤10 BD for Low-tier), and an amnesty path, and does ≥85% of AI/HAI infrastructure reaching production in the last 12 months have a gate record (100% for Critical/High-tier)?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-PC-L1-3. Are ≥95% of platform/SRE headcount covered by a current-year AI Infrastructure Standards AUP acknowledgment, and does every customer-facing or regulated-data-processing AI/HAI infrastructure instance in production have a named infrastructure owner logged in the SM-Infrastructure inventory?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

PC Level 2.

Q-PC-L2-1. Have the three priority policies been extended with tier-specific addenda (per the SM-Infrastructure L2 rubric), and do Critical instances carry explicit CISO plus VP Infrastructure sign-off at provisioning with a live compliance evidence bundle covering TA snapshot, SR REM, SA pattern confirmation, DR decision, IR attestation, ST evidence, ML logging-baseline, infrastructure-owner record, and FedRAMP / regional compliance evidence where applicable?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-PC-L2-2. Is a compliance evidence bundle continuously maintained for every Critical/High instance with staleness inside tier-specific targets, and can a regulatory or auditor inquiry be satisfied with provenance-complete artifacts within 5 business days?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-PC-L2-3. Is an exception register operated with named owners, compensating controls, and expiry dates, reviewed monthly, with Critical-tier missing provisioning artifacts treated as blocking findings (no amnesty), and sector-specific evidence bundles (HIPAA / PCI-DSS / FedRAMP as applicable) complete for in-scope instances?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

PC Level 3.

Q-PC-L3-1. Does a continuous attestation pipeline auto-update evidence bundles from IaC state events, cloud-provider provisioning events, Kubernetes admission-webhook records, and runtime configuration signals, with attestation currency ≤24 hours latency and ≤3 BD on-demand evidence-pack generation, and is ≥99% of Critical/High instances continuously attested?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-PC-L3-2. Does the program operate a quarterly, telemetry-driven policy-refresh cycle (ML-Infrastructure detection trends + IM-Infrastructure incident learnings + regulatory-motion tracker + tier-movement data) with a versioned changelog where 100% of changes are traceable to a named signal or regulatory update?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-PC-L3-3. Does the program contribute at least two substantive public comments or standards artifacts per year on AI/HAI infrastructure policy topics (CNCF, OpenSSF AI, FinOps Foundation, EU AI Act Art. 15 implementing guidance, NIST AI RMF Playbook, FedRAMP Emerging Technology, sector regulators), with documented external recognition?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.3 Education & Guidance (EG)

EG Level 1.

Q-EG-L1-1. Have all platform engineers, SREs, and cloud architects provisioning or operating AI/HAI infrastructure completed a current-year AI infrastructure literacy course covering the seven in-scope archetypes, GPU fleet operational risk, IaC-for-AI differences, region/residency for AI serving infrastructure, observability minimums, and the provisioning gate, with ≥95% completion and content updated within 30 days of any policy or archetype change?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EG-L1-2. Has the practitioner population (platform security engineers, SRE on-call leads, cloud architects performing AI infrastructure reviews) completed role-based training covering inference-endpoint attack surface (ATLAS AML.T0015/AML.T0024), model-registry supply-chain attacks (ATLAS AML.T0010), GPU-fleet IAM hardening, vector-store hardening, orchestrator control-plane security (EA/AGH/TM/RA), AI-specific CI/CD attacks, and IaC review patterns for all seven archetypes, with completion gated on intake-approval permissions and calibration drift ≤1 tier step and ≤2 risk misclassifications per sample for two consecutive quarters?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EG-L1-3. Is a shadow-AI-infra awareness campaign running with at least monthly content, a visible amnesty path linked from the AUP and intake form, and measurable attribution of intake submissions and amnesty disclosures to campaign channels, with disclosures rising in Q1–Q2 after launch then declining as the sanctioned-archetype program grows?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

EG Level 2.

Q-EG-L2-1. Is there a scenario library of ≥30 anonymized real infrastructure intake cases powering practitioner training across the org's in-scope archetypes, with paired calibration exercises showing Critical-tier drift ≤1 tier step and ≤1 risk misclassification per sample for two consecutive quarters?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EG-L2-2. Have cloud-provider-specific engineering tracks (AWS / GCP / Azure AI infrastructure as applicable) been delivered to ≥1 practitioner per Critical/High-tier infrastructure instance, with team-level training coverage tracked in the SM-Infrastructure inventory?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EG-L2-3. Are shadow-AI-infra campaigns running on a seasonal, behavior-driven cadence with pre-set behavior targets and post-campaign measurement, with ≥70% of campaigns hitting their target, and is ≥80% of training content updated in the last 90 days?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

EG Level 3.

Q-EG-L3-1. Has the practitioner curriculum, anonymized scenario library, and reviewer rubric been published externally (CNCF, OpenSSF AI, CNCF TAG Security, or cloud-provider partner security programs) with documented adoption, citations, forks, or direct acknowledgment, and do contributions loop back into internal content within 30 days?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EG-L3-2. Is a monthly live calibration cadence operating (anonymized infrastructure intake from the live provisioning queue, independent reviewer scoring, drift reported to sponsor), with calibration results feeding the scenario library within 30 days, and do ≥50% of Critical-tier reviewers hold an external AI infrastructure or cloud security credential where one exists?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EG-L3-3. Does the program contribute ≥2 substantive artifacts per year to industry AI infrastructure security certification or curriculum working groups (CNCF / OpenSSF AI / cloud-provider partner programs), and ≥1 MITRE ATLAS TTP contribution or confirmation per year where novel observations exist in own-operated AI/HAI infrastructure?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.4 Threat Assessment (TA)

TA Level 1.

Q-TA-L1-1. Are published, versioned threat models in place for all seven AI/HAI infrastructure archetypes (inference endpoint, model registry, GPU/accelerator fleet, orchestrator/control plane, vector-store infrastructure, AI-specific CI/CD, feature store), each mapping archetype-specific threats to HAI TTPs (EA/AGH/TM/RA), ATLAS tactic IDs, HCT threat roots (BadCode/BadAction/BadPrincipal/BadPermissions), and PC-Infrastructure compliance items, with a named library steward and a documented quarterly refresh cadence?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-TA-L1-2. Does every AI/HAI infrastructure asset entering the SM inventory receive a threat snapshot (delivered within one business day of intake) that documents the applicable archetype(s), asset-specific deltas (workload tier hosted, multi-tenancy isolation model, customer exposure, data classification, geographic scope), top-5 threats with HAI TTP tags, ATLAS tactic IDs, and HCT roots, and gaps for SR/SA follow-up, with 100% of newly Sanctioned assets carrying a snapshot in the last 90 days?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-TA-L1-3. Is there a published shadow-AI-in-infrastructure threat view, reviewed by the program sponsor in the last 12 months, that documents entry vectors (untagged GPU instances, unsanctioned registries, personal-credential-based model deployments), elevated threat scenarios for unreviewed infrastructure assets, and the specific detections (from SM discovery sources) used to surface them?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

TA Level 2.

Q-TA-L2-1. Does every Critical-tier AI/HAI infrastructure asset have a current-year per-asset deep threat model (not an archetype snapshot) covering a cloud-tactic walk using the per-cloud TM template, a full HCT four-root analysis for the asset's current IAM posture and network placement, an abuse-case catalog with named adversary archetypes, and deployer-duty mapping, with a semi-annual refresh cadence and change-driven updates on platform upgrade, new tenant onboarding, or network topology change?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-TA-L2-2. Is external AI infrastructure threat intel (MITRE ATLAS updates, AVID, CNCF AI security advisories, OpenSSF AI, cloud-provider security bulletins) integrated with a quarterly triage cadence and a documented change-log, with intel-to-library update ≤30 days on Critical-impact items?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-TA-L2-3. Does the program run a quarterly red-team-the-library exercise that probes an in-scope AI/HAI infrastructure asset using only library threats and surfaces misses as library gaps, with every gap carrying a named owner and an expiry date, Critical gaps closing within 30 days, and the gap rate trending down quarter over quarter?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

TA Level 3.

Q-TA-L3-1. Does the threat library auto-update from telemetry (ML-Infrastructure detections, IM-Infrastructure incidents) and external feeds (ATLAS, AVID, CNCF, OpenSSF AI, cloud-provider bulletins) via a human-curated auto-proposal pipeline, with ≥60% of changes auto-proposed, a ≤14-day lead time from signal to update, and a machine-readable change-log consumed by downstream SR and ST practices?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-TA-L3-2. Does the program contribute at least four substantive, evidence-backed technical artifacts per year to MITRE ATLAS / AVID / CNCF AI / OpenSSF AI, with at least two externally recognized in a published advisory, standard revision, or community guidance?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-TA-L3-3. Are anonymized archetype threat models published under a permissive license with tracked peer-org adoption, and does the program host or co-host at least one industry tabletop per year (ATLAS practitioner table, CNCF AI security working group, OpenSSF AI chapter, or cloud-provider ISAC AI working group) tied to the library?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.5 Security Requirements (SR)

SR Level 1.

Q-SR-L1-1. Is there a published, versioned AI/HAI Infrastructure Requirements Pack containing a base set (≤20 requirements) plus seven per-archetype deltas, with every requirement tagged to at least one TA-Infrastructure archetype threat and one PC-Infrastructure priority-compliance item, and are reviewers selecting from the pack rather than drafting requirements per asset at intake?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SR-L1-2. Do 100% of new AI/HAI infrastructure assets approved in the last 90 days have a completed Requirements-Evidence Map (REM) on file, with every applicable requirement marked Met / Met-with-compensating-control / Gap-accepted / Not-applicable, each Met row citing specific verifiable evidence (IaC config reference, conformance test result, IAM audit output, SIEM completeness metric), and each Gap-accepted row naming a compensating control with owner and re-review date?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SR-L1-3. Is cross-domain REM linkage operational, with Software-domain REMs referencing the Infrastructure REM of their hosting cluster for base infrastructure categories (identity, isolation, encryption, observability, patch hygiene) rather than re-auditing those controls independently, and is the pack on a quarterly refresh cadence with a named owner?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

SR Level 2.

Q-SR-L2-1. Do 100% of pack requirements carry a quantitative or binary evidence condition, with every SLA (vulnerability remediation days, GPU clearing conformance-test cadence, SIEM completeness percentage, kill-switch response time, RTO/RPO) and binary state (workload-identity-only access confirmed, signed artifacts enforced, dedicated nodes for Critical tier confirmed, rate limits verified) specified, and has all qualitative "reasonable" and "appropriate" language been removed from the pack?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SR-L2-2. Are ≥95% of Critical-tier REMs re-validated against observed reality (IAM audit, GPU isolation conformance test, signed-image admission-controller query, SIEM completeness metric, kill-switch test) in the last 90 days, with validation deltas routed to IM-Infrastructure and no Critical-tier accepted gap aging beyond 60 days without documented escalation?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SR-L2-3. Is the IR-Infrastructure feedback loop operational, with ≥90% of IR findings for requirements covered by the pack triggering a REM row re-review within 5 business days, and the finding not closed until the REM row reflects the current state, and is the per-tier pack overlay enforced at SM intake with Critical-tier assets receiving full depth and Low-tier assets the base pack only?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

SR Level 3.

Q-SR-L3-1. Is the AI/HAI Infrastructure Requirements Pack expressed in a machine-readable schema and enforced via IaC attestation at deploy time, with ≥80% of Critical-tier requirements having automated checks, zero Critical-tier assets deploying to production with a failing REM check, and the schema published under a permissive license with tracked external adoption?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SR-L3-2. Are ≥70% of REM evidence rows auto-validated via IaC, runtime monitoring (ML-Infrastructure), and SIEM signal ingestion, with ≥70% of Critical/High Software-domain CI/CD gates referencing the Infrastructure REM attestation to verify hosting-cluster compliance before the software deploy proceeds?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SR-L3-3. Does the program contribute at least two substantive artifacts per year (machine-readable requirement schema, IaC attestation framework, Kubernetes AI workload isolation requirements) to recognized standards bodies (CNCF AI, OpenSSF AI, NIST AI RMF Playbook, ISO AI security standards work), with contributions publicly documented and traceable to adoption?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.6 Secure Architecture (SA)

SA Level 1.

Q-SA-L1-1. Are seven reference patterns published, one per archetype (inference endpoint, model registry, GPU/accelerator fleet, orchestrator/control plane, vector-store infrastructure, AI-specific CI/CD, feature store), each with a labeled architecture diagram, identity and auth model, isolation spec, logging spec, and explicit row-by-row mapping to SR-Infrastructure requirements and TA-Infrastructure threats with HAI TTP tags, applicable MITRE ATLAS mitigation IDs, and HCT threat roots addressed, accessible within one click of the SM inventory record?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SA-L1-2. Are 100% of inference endpoints and model registries verified (via IAM audit, not only policy declaration) to use workload-identity-only access with no long-lived API keys in service principals, and is the anti-pattern catalog linked from the AI Acceptable Use Policy, the SM intake gate, and EG-Infrastructure training, with each entry tied to a real incident or authoritative case study?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SA-L1-3. Is a repeat-deviation signal operational, such that three deviations in the same direction for the same archetype automatically queue a pattern-update review with SA-Infrastructure ownership, and are ≥85% of active AI/HAI infrastructure assets in the SM inventory classified as "on pattern" or "deviation with review" with no silent deviations?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

SA Level 2.

Q-SA-L2-1. Are the five tier-conditional extended patterns (Critical overlay, High overlay, multi-region, multi-tenant, per-tier IaC modules) published as forkable IaC modules with conformance test suites, and are ≥80% of Critical and High-tier AI/HAI infrastructure assets running on IaC-encoded patterns as confirmed by the IaC and SM inventory registries?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SA-L2-2. Has the anti-pattern catalog been updated from ≥3 real IM-Infrastructure incidents in the last 12 months, with new entries surfaced at intake time rather than stored only in a reference document, and is conformance testing covering 100% of IaC-encoded asset deployments with findings tracked to resolution?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SA-L2-3. Are 100% of Critical-tier assets carrying explicit EU AI Act Art. 9 and Art. 15 control mappings in the pattern documentation, and is the tier-treatment matrix from SM-Infrastructure L2 reflected in the pattern variants (Critical assets get the Critical overlay, High assets get the High overlay, Medium/Low follow the base pattern)?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

SA Level 3.

Q-SA-L3-1. Have ≥5 reference patterns been published as open artifacts under a recognized open license via at least one industry body (CNCF AI, OpenSSF AI, CSA, or equivalent), and have ≥2 of those patterns been cited or forked by recognized industry or sector bodies, with documented adoption evidence and internal practice aligned to the published version?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SA-L3-2. Have ≥2 MITRE ATLAS AML.M00xx mitigation entries been proposed or validated, traceable to specific SA-Infrastructure pattern controls aligned to ATLAS primary tactics TA0006 Persistence, TA0007 Privilege Escalation, and TA0008 Defense Evasion, and is there an active ATLAS practitioner engagement cadence?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SA-L3-3. Is there at least one documented reference to SA-Infrastructure patterns in a regulatory implementing-act, sector guidance document, CNCF AI community document, OpenSSF AI guidance, or published standards text, and is the regulatory and community engagement calendar maintained with active items, target timelines, and evidence of substantive (not declaratory) participation?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.7 Design Review (DR)

DR Level 1.

Q-DR-L1-1. Is there a published, versioned per-archetype AI/HAI Infrastructure Design Checklist, one per SM-Infrastructure archetype, traceable to the applicable SA reference pattern, SR requirements pack, and TA threat snapshot, with the GPU fleet checklist covering residual-state-clearing and classification-aware scheduling, the inference endpoint checklist covering mTLS, per-tenant rate-limit, signed-model, canary, and PII-redaction-at-logging, and the model registry checklist covering signed-artifacts-only and lineage-required?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-DR-L1-2. Do ≥95% of AI/HAI infrastructure components going to production in the last 90 days carry a completed DR decision record (approve / approve-with-conditions / send-back) before provisioning begins, with a two-lane routing model (fast-lane ≤2 BD, full-lane ≤5 BD), named lead reviewers per archetype trained on EG-Infrastructure L1, and a residual-risk list with named owner and expiry in every record?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-DR-L1-3. Are recurring pattern deviations and repeatedly-waived SR requirements automatically queuing SA-Infrastructure pattern-update and SR-Infrastructure pack-update reviews, and does every IM-Infrastructure incident trigger a re-examination of the DR record that approved the affected component?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

DR Level 2.

Q-DR-L2-1. Are 100% of Critical-tier DR reviews conducted as scenario-based walkthroughs, with 3–5 specific threat scenarios sourced from TA-Infrastructure per-component deep models and anonymized IM-Infrastructure incidents, keyed to ATLAS tactics TA0001, TA0004, TA0012, TA0013, with the DR decision tied explicitly to how the proposed design handles each scenario rather than checklist conformance alone?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-DR-L2-2. Is design-drift detection running quarterly for Critical-tier and annually for High-tier, using IaC repository changes, cloud-provider API state, Kubernetes API manifest drift, model-registry events, and CI/CD parameter changes, with 100% of material drifts automatically re-routed to DR for a new review?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-DR-L2-3. Are joint DR-Infrastructure / DR-Software review records on file for 100% of Critical-tier software artifacts integrating with shared AI infrastructure, with an explicit responsibility boundary and shared residual-risk ownership documented in both DR records?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

DR Level 3.

Q-DR-L3-1. Are ≥90% of Critical-tier AI/HAI infrastructure components producing a daily automated attestation signal, checking IaC compliance, cloud-provider API configuration, workload identity state, encryption-key placement, rate-limit configuration, and logging completeness, with deviations auto-opening DR-exception tickets triaged within 3 business days?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-DR-L3-2. Has the program contributed ≥2 substantive review artifacts per year (per-archetype rubrics, scenario templates, pattern-evolution frameworks) to CNCF AI, OpenSSF, or OWASP LLM / Agentic Top 10 infrastructure patterns, with documented adoption and internal practice aligned to the published versions?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-DR-L3-3. Is there a quarterly pattern-evolution review driven by external signals (MITRE ATLAS TA0001/TA0004/TA0012/TA0013, CNCF AI, OpenSSF advisories) and internal signals (IM-Infrastructure incidents, ML-Infrastructure telemetry, ST-Infrastructure findings), with a versioned change log and notification to in-flight DR reviews affected by pattern changes?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.8 Implementation Review (IR)

IR Level 1.

Q-IR-L1-1. Is there a published, per-archetype IR checklist, one per SM-Infrastructure archetype, covering IaC-state-matches-pattern, config-matches-DR, SR REM evidence currency, logging-event production, and per-tenant isolation confirmation, with the GPU fleet checklist requiring a residual-state-clearing test record and a classification-aware scheduling probe, and the inference endpoint checklist requiring mTLS, per-tenant rate-limit, signed-artifact enforcement, and PII-redaction-at-logging verification?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IR-L1-2. Do 100% of new AI/HAI infrastructure components going to production in the last 90 days carry a go-live IR record, and do ≥90% of all active components carry a current-year IR record, with material-change triggers wired to SM-Infrastructure inventory events, Critical / blocker findings resolved before production, and High findings closed within 7 days with evidence linked?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IR-L1-3. Are findings severity-tagged and tracked in IM-Infrastructure with named owners and SLA-bound closure dates, and does every IR finding that reveals stale or inaccurate REM evidence trigger an SR-Infrastructure REM row update before the finding is closed?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

IR Level 2.

Q-IR-L2-1. Are ≥90% of Critical-tier AI/HAI infrastructure components under continuous drift detection, via IaC drift-detection tooling, cloud-provider Config Rules / asset-inventory APIs, admission-controller policy checks, model-registry webhooks, and CI/CD parameter monitoring, with median detection latency ≤7 days and automated finding creation on material deviations?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IR-L2-2. Are vendor admin API probes current for ≥80% of Critical/High-tier managed components on a monthly (Critical) and quarterly (High) cadence, and are 100% of Critical/High-tier components covered by boundary probes (cross-tenant isolation, signing enforcement, rate-limit enforcement, GPU residual-state-clearing, pipeline-gate enforcement) in the current IR cycle?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IR-L2-3. Is tier-cadence adherence ≥95% with Critical-tier findings aged per the SM-Infrastructure L2 tier-treatment matrix SLAs, and is the drift-detection pipeline wired to auto-open IR findings (not just alert dashboards) for all Critical-tier components?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

IR Level 3.

Q-IR-L3-1. Are ≥90% of Critical-tier AI/HAI infrastructure components producing a daily attestation signal across all three dimensions (IaC-pattern compliance, evidence freshness, configuration tolerance), with deviations auto-opening IM-Infrastructure tickets within 1 hour and zero stale-evidence violations for Critical-tier REMs?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IR-L3-2. Has the program published per-archetype configuration baseline schemas to OpenSSF AI, CNCF AI Working Group, or OWASP LLM / Agentic Top 10 infrastructure patterns, with documented adoption and internal practice aligned to the published versions, and is IR reviewer-hours per Critical component per year trending down over two consecutive quarters?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IR-L3-3. Is the post-incident IR feedback loop operational, with IM-Infrastructure post-incident reviews including a mandatory IR-record re-examination step, and ≥1 attestation rule update produced per material incident, ensuring incident learning continuously improves attestation coverage?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.9 Security Testing (ST)

ST Level 1.

Q-ST-L1-1. Is a per-archetype foundational test battery published for all seven AI/HAI infrastructure archetypes, with each test class tied to a TA-Infrastructure archetype threat (HAI TTP + ATLAS tactic ID) and an SR-Infrastructure requirement, defined inputs/outputs/pass-fail criteria, and an evidence artifact, and are 100% of new AI/HAI infrastructure components required to pass the battery before production Sanctioned status is issued?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ST-L1-2. Are six regression corpora (model-extraction, cross-tenant-isolation, GPU-residual-state, workflow-injection, retrieval-extraction, pipeline-signing) versioned in source control, running on a monthly-or-better cadence for Critical/High-tier components, with a named corpus owner and a monthly refresh cadence from internal and external sources, and are ≥90% of Critical/High-tier component changes verified to have triggered the relevant corpus run?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ST-L1-3. Are all test failures routed to IM-Infrastructure within 1 business day with a severity tag and named owner, and does TA-Infrastructure archetype threat coverage by the test battery and corpus reach ≥80% by end of year one?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

ST Level 2.

Q-ST-L2-1. Are 100% of Critical-tier AI/HAI infrastructure components red-teamed at least quarterly, and 100% of High-tier semi-annually, with scope derived from TA-Infrastructure L2 per-component deep threat models, covering model-extraction campaigns, cross-tenant retrieval extraction, GPU residual-state composition, pipeline-tampering, workflow-injection chains, and feature-poisoning detection, with findings routed to IM and remediation tracked?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ST-L2-2. Is per-tier corpus calibration enforced (Critical-tier: all 6 corpora on a monthly cadence; Low-tier: model-extraction corpus on a quarterly cadence), and are ≥90% of Critical/High-severity red-team findings converted to corpus entries within 30 days?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ST-L2-3. Are cross-archetype composition tests (inference endpoint + GPU fleet residual-state, orchestrator + vector-store retrieval-injection, AI-CI/CD + model registry tampering) documented and executed for all Critical-tier composite components, and is per-tier SLA adherence for testing activities ≥90%?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

ST Level 3.

Q-ST-L3-1. Are ≥80% of Critical-tier AI/HAI infrastructure components under continuous automated adversarial testing with daily probe execution, using model-extraction generators, cross-tenant isolation probers, GPU residual-state probers, pipeline-tampering generators, and retrieval-extraction seeders, with novel techniques triaged into the TA-Infrastructure library within 14 days and high-severity automated findings routed to IM within 24 hours?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ST-L3-2. Has the program contributed ≥4 anonymized, legally-vetted findings per year to MITRE ATLAS, AVID, CNCF AI Working Group, or OWASP LLM / Agentic Top 10 infrastructure patterns, with at least one accepted as a new or refined technique, and are all 6 open regression corpora published under a permissive license and maintained upstream?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ST-L3-3. Has the program hosted at least 1 industry-shared red-team exercise per year and participated in ≥2 additional cross-org exercises, with documented cross-org detection-benchmark improvement data from participants?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.10 Environment Hardening (EH)

EH Level 1.

Q-EH-L1-1. Does every AI infrastructure archetype component in the SM-Infrastructure inventory (across all seven archetypes) run under a dedicated workload identity with no long-lived service-account keys, confirmed by IAM audit reconciliation, and do all AI infrastructure consoles (model registry, vector-store, orchestrator, cloud ML) require SSO + MFA with every console action written to an append-only audit log?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EH-L1-2. Are GPU/accelerator nodes enforcing residual-state clearing between jobs with clearing events logged, such that any clearing failure drains the node within 4 hours, and are all Critical/High-tier AI infrastructure container images signed, SBOM-tracked, and rejected at the deployment gate if unsigned, with signed model artifacts required for registry promotion?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EH-L1-3. Are DLP rules tuned for AI-infra-specific exfiltration (bulk model-weight download, mass-embedding extraction, training-data export from CI/CD) deployed and active, with classification-aware egress policy enforced on archetype workload identities, and with inference endpoints blocked from unauthorized public ingress?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

EH Level 2.

Q-EH-L2-1. Are 100% of Critical-tier archetype components running under a dedicated VPC with HSM-rooted CMK per archetype, JIT-only human admin with no standing access (≤4-hour sessions, approval-gated), and SLSA L3+ provenance attestations verified at deployment, confirmed by IAM audit and IR-Infrastructure review?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EH-L2-2. Are ≥90% of Critical-tier multi-tenant inference endpoints and vector stores enforcing per-tenant isolation at the infrastructure layer (dedicated namespace + NetworkPolicy + per-tenant CMK), confirmed by IR-Infrastructure implementation reviews and ST-Infrastructure isolation tests wired into CI?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EH-L2-3. Is a tier-hardening matrix published and enforced at provisioning and on tier-change, with SM-Infrastructure inventory records showing hardening status per tier, gaps tracked as open IM-Infrastructure findings, and an adaptive-tightening pipeline operational from ML-Infrastructure and IM-Infrastructure signals?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

EH Level 3.

Q-EH-L3-1. Are ≥90% of EH-Infrastructure controls expressed as authoritative IaC (not stubs) in a version-controlled module registry, with drift detected continuously, ≥70% of low-risk drift auto-remediated with a machine-readable change log visible to infrastructure and security teams, and high-risk drift human-reviewed within 2 business days?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EH-L3-2. Is the adaptive-policy pipeline operational, with ML-Infrastructure detections and IM-Infrastructure incidents generating human-approved policy-tightening proposals on a tracked cadence, every change traceable to a source signal, and downstream archetype teams notified within 24 hours of a tightening change affecting their component's hardening profile?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EH-L3-3. Does the program contribute ≥2 AI infrastructure hardening baselines per year to industry bodies (CNCF TAG Security, OpenSSF AI Infrastructure, sector ISACs) with documented adoption, and are new AI infrastructure archetype components auto-provisioned with their tier-appropriate hardening profile within 24 hours of SM-Infrastructure inventory registration?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.11 Issue Management (IM)

IM Level 1.

Q-IM-L1-1. Is there a single AI infrastructure issue backlog with standardized metadata (source, affected component linked to SM-Infrastructure inventory, severity rubric anchored to AI-infrastructure-specific axes, cross-tenant breach / GPU residual-state leakage / registry compromise for Critical; confirmed control failure with potential impact for High; and so on, owner, SLA, regulatory flag, evidence link) capturing ≥95% of issues from all source practices (TA, SR, DR, IR, ST, ML, external CVEs, CNCF advisories, ATLAS updates)?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IM-L1-2. Is the AI infrastructure incident playbook published with ≥7 named AI-infrastructure-specific incident classes (cross-tenant breach, model registry compromise, GPU residual-state leakage, orchestrator compromise, vector-store mass-extraction, AI CI/CD pipeline compromise, shadow inference endpoint), each with pre-assigned roles, containment plays, evidence-capture steps, and SLA targets, and has each class been exercised in at least one tabletop in the last 12 months?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IM-L1-3. Is the regulatory SLA tracker live covering GDPR Art. 33 (72h), EU AI Act Art. 73, HIPAA (60d), NYDFS Part 500 (72h), PCI-DSS, FedRAMP IR (1h high-severity), and ISO/IEC 27035, with 100% adherence in the last 90 days, and does every Critical/blocker incident produce a post-incident review within 14 days with named update outputs flowing to SA-Infrastructure, SR-Infrastructure, EG-Infrastructure, and ML-Infrastructure?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

IM Level 2.

Q-IM-L2-1. Is a tier-calibrated incident playbook operational with Critical-tier MTTA ≤1 hour and MTTC ≤4 hours, 24/7 on-call coverage with a documented rotation including a current Critical-tier component briefing and rehearsed escalation paths for GPU clearing failure and shadow endpoint, and does tier-movement in the SM-Infrastructure inventory automatically trigger IM configuration updates within 14 days of a Critical re-tier event?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IM-L2-2. Is a post-incident review auto-flow integration live, routing Critical-tier review outputs to SA/SR/EG/ML practice backlogs, with ≥90% of downstream practice owners responding within 14 days, and the sponsor reviewing output quality quarterly to distinguish substantive changes from nominal acknowledgements?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IM-L2-3. Is a cross-domain coordination protocol published and used for 100% of multi-domain AI infrastructure incidents, with named cross-domain contacts for Software, Data, and Processes domains verified quarterly, a single Incident Commander from the primary impacted domain, and joint post-incident reviews spanning all affected domains?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

IM Level 3.

Q-IM-L3-1. Does the program contribute ≥4 anonymized AI infrastructure incident-classification entries per year to sector ISACs, ≥2 entries per year to AVID, and ≥1 contribution per year to MITRE ATLAS AI infrastructure tactic documentation, with all contributions maintained current, legally vetted, and tracked for external adoption?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IM-L3-2. Are ≥3 pre-authorized automated containment actions live (shadow-endpoint egress-block, GPU node drain on clearing failure, vector-store retrieval rate-limit, or AI CI/CD pipeline freeze classes), vetted by Privacy/Legal and the executive sponsor, producing 100% audit records plus human-review tickets on execution, with the pre-authorization policy reviewed quarterly and any unexpected outcome triggering an out-of-cycle review?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IM-L3-3. Is a quarterly MTTR benchmark brief published to the sponsor, comparing the program's MTTR per incident class and per tier against ISAC-sourced and peer-sourced benchmarks, with Critical-tier MTTR at or below benchmark for ≥4 of 7 incident classes and deltas above benchmark linked to specific practice gaps and investment proposals?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.12 Monitoring & Logging (ML)

ML Level 1.

Q-ML-L1-1. Has a per-archetype logging baseline been published specifying the minimum event schema, fields, retention window, and export path for each AI infrastructure archetype in the SM-Infrastructure inventory (inference endpoint, model registry, GPU fleet, orchestrator, vector store, AI CI/CD, feature store), and has compliance of each production component been measured against it within the last quarter?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ML-L1-2. Is a high-signal detection set of ≤12 detections active, each with a named owner, detection query, SLA, and last-tuned date, including cross-tenant access, model swap without approval, GPU residual-state clearing failure, unsigned model artifact promotion, vector-store extraction pattern, CI/CD integrity failure, orchestrator workflow injection, and shadow inference endpoint, with false-positive rates tracked per detection and monthly tuning reviews occurring?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ML-L1-3. Has the evidence trail for EU AI Act Art. 12, applicable sector cloud regulations, and GDPR processor obligations been wired to the ML-Infrastructure log store, and has a quarterly deployer-duty drill confirmed that the evidence package for a randomly selected production component can be assembled within the ≤24-hour SLA?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

ML Level 2.

Q-ML-L2-1. Is tier-calibrated logging depth applied per the SM-Infrastructure L2 tier-treatment matrix, Critical-tier components retaining full event corpora at the longest regulatory window, Low-tier components receiving baseline only, and is this calibration automatically updated when a component is re-tiered?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ML-L2-2. Is the SIEM ingesting ML-Infrastructure log feeds with ≥3 cross-archetype correlation rules active (covering at minimum registry-to-endpoint pivot, identity pivot on supply-chain compromise, and vector-store mass-extraction plus JIT access anomaly), and is a quarterly detection tuning cycle operating from IM-Infrastructure post-incident and ST-Infrastructure finding inputs?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ML-L2-3. Are ≥90% of Critical/High-tier components running anomaly-detection baselines with behavioral profiles refreshed monthly and FP rates tracked and trending down, and is the ML logging-baseline validation element completing inside the ≤30-day staleness threshold for all Critical-tier components in PC-Infrastructure compliance evidence bundles?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

ML Level 3.

Q-ML-L3-1. Are ≥90% of detections expressed as version-controlled, CI/CD-deployed code artifacts with automated test coverage against realistic synthetic log data, and is detection coverage auto-verified for 100% of new or re-tiered SM-Infrastructure inventory entries within 24 hours of the inventory change event?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ML-L3-2. Are ≥90% of Critical/High-tier components running anomaly detection on request, access, and utilization corpora, with anomaly models retrained monthly on production log data, model versions tracked, and anomaly-model alerts feeding the IM-Infrastructure incident backlog through the same detection-to-ticket pipeline as rule-based detections?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ML-L3-3. Has the program contributed ≥2 telemetry-standard artifacts per year to the CNCF observability working group or OpenSSF AI Infrastructure, and ≥12 anonymized detection signatures per year to sector ISACs, and has it proposed or validated ≥2 MITRE ATLAS AML.M00xx detection-mitigation entries, with contributions maintained current and external adoption tracked?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

29. Practice-level rollup

After completing all 108 questions, fill in the table below. For each practice, count Yes (Y), Partial (P), and No (N) answers per level. Compute the precise score as described in Section 27: L1_score = (Y + 0.5P) / 3; L2_score = (Y + 0.5P) / 3 × L1_score; L3_score = (Y + 0.5P) / 3 × L2_score; Practice Score = L1_score + L2_score + L3_score.

Worked example

The assessment team answers for TA-Infrastructure: L1 Q1 = Y, L1 Q2 = Y, L1 Q3 = P; L2 Q1 = Y, L2 Q2 = P, L2 Q3 = N; L3 all N.

L1_score = (1.0 + 1.0 + 0.5) / 3 = 0.833
L2_score = (1.0 + 0.5 + 0.0) / 3 × 0.833 = 0.417
L3_score = 0.0

TA Practice Score = 0.833 + 0.417 + 0.0 = 1.25 / 3.0

Interpretation: TA-Infrastructure scored L1 = 0.83, L2 = 0.42, L3 = 0.0, yielding a practice maturity of 1.25, solidly Foundational with partial L2. The seven archetype threat models and the per-intake snapshot gate are working; the shadow-AI-in-infrastructure threat view is incomplete; the external intel triage cadence is partial and the red-team-the-library exercise is not yet operational. Roadmap priority: complete the shadow-AI-in-infrastructure threat view (closes the L1 Partial), operationalize external intel triage (L2 Q2), launch the red-team-the-library cadence (L2 Q3). L3 work is premature.

Notes column for assessor. Use the space below to record per-practice observations: which questions were hardest to answer, where evidence was thin, where Partial answers cluster, and what the most actionable next step is.

SM: _________ PC: _________ EG: _________ TA: _________ SR: _________ SA: _________ DR: _________ IR: _________ ST: _________ EH: _________ IM: _________ ML: _________

30. Domain-level rollup

Domain Maturity = (sum of all 12 Practice Scores) / 12 = ____ / 3.0

Maturity band achieved: ☐ Ad-hoc (0.0–0.9) ☐ Foundational (1.0–1.9) ☐ Comprehensive (2.0–2.9) ☐ Industry-Leading (3.0)

Per-Business-Function rollup

A domain is mature when all four Business Functions are at the same band. A domain whose Operations function trails the others has built and verified well but cannot run the program against live infrastructure. A domain whose Verification function trails provisions AI/HAI infrastructure without proof. The most common pattern in early-stage programs is Governance ahead of Building, and both ahead of Verification and Operations, because charters and policies are easier to write than conformance tests are to run and logging baselines are to maintain across a GPU fleet.

Worked example, domain-level rollup

The following shows a plausible result for an organization 18 months into its Infrastructure-domain program.

Domain Maturity = 14.83 / 12 = 1.24 / 3.0

Band: Foundational. This organization has crossed L1 across most practices but has not yet closed L2 for any practice. The Operations and Verification functions are weakest (ST 0.92, ML 0.83 both sub-Foundational), which is typical. The program has a visible inventory and published policies, but the conformance-test battery and logging baselines are not consistently measured across the seven archetypes.

Per-Business-Function summary for this example:

The imbalance is clear: Governance is at 1.61 while Verification (1.06) and Operations (1.03) trail. The program has published good policies and a risk-tier rubric but has not yet instrumented the GPU fleet, model registries, and inference endpoints with conformance testing and logging baselines. The roadmap should front-load ST L1 and ML L1 before deepening Governance to L2.

Strengths

Gaps

Highest-priority remediation areas (top 5)

31. Improvement roadmap template

Use this template to convert assessment findings into a 12-month roadmap. Each entry names a target gap, the practice and level it addresses, the owner, the success metric, and the deadline.

A 12-month roadmap for the Infrastructure domain follows four natural quarters. The sequencing mirrors the dependency graph in HAIAMM v3.0 §9: Governance must be in place before Building can operate; Building must be in place before Verification can produce meaningful results; Operations depends on all three preceding functions.

Quarter 1 (months 1–3). Stabilize L1 across the four Business Functions. Priority practices: SM L1, PC L1, EG L1, TA L1.

Quarter 1 focus: make every AI/HAI infrastructure instance in production visible, named, and governed. The inventory, the charter, the three policies, and the archetype threat library must all exist at L1 before platform teams can self-serve on intake. A shadow-AI-infra discovery sweep, cloud-provider APIs, Kubernetes GPU workloads, IaC repos, model-registry APIs, GPU-spend, egress logs, vector-store listings, should run within the first 30 days so the inventory is seeded from signals rather than declared from memory.

Quarter 2 (months 4–6). Complete remaining L1 practices. Priority practices: SR L1, SA L1, DR L1, IR L1, ST L1, EH L1, IM L1, ML L1; SM L2 risk-tier rubric.

Quarter 2 focus: close the Building and Operations L1 gaps, and begin the L2 calibration work starting with the SM risk-tier rubric, which, per §9.3 of the v3.0 framing, is the prerequisite every other Infrastructure-domain practice needs to move to L2.

Quarter 3 (months 7–9). Operationalize L2 across the Governance and Building functions. Priority practices: PC L2 evidence bundles, TA L2 per-asset deep models, SA L2 IaC-encoded patterns, DR L2 scenario-based walkthroughs, SR L2 quantitative requirements.

Quarter 3 focus: the tier rubric now exists, use it. Compliance evidence bundles for Critical/High instances should be assembling automatically. Per-asset deep threat models for Critical-tier replace archetype snapshots. Design reviews for Critical-tier move to scenario-based walkthroughs. The SR pack sheds all qualitative language and reference patterns become forkable IaC modules.

Quarter 4 (months 10–12). Complete L2 across all 12 practices and prepare L3 entries for selected practices. Priority practices: IR L2 continuous drift detection, ST L2 red-team cadence, EH L2 per-tenant isolation, ML L2 anomaly detection, IM L2 tier-calibrated playbook; begin L3 scope decisions for SM, TA, and EG.

Quarter 4 focus: close the Verification and Operations L2 gaps. Drift detection, red-team cadence, per-tenant isolation, anomaly baselines, and tier-calibrated incident response are the load-bearing L2 capabilities that most programs defer because they require engineering investment across the GPU fleet, inference endpoints, and orchestrators. The L3 scope decisions for SM, TA, and EG can be made now even if the automation work begins in year 2.

Reassessment date (12 months from this assessment): ____

When the next annual assessment runs, compare practice scores to this baseline. The expected trajectory for a program executing this roadmap is: Domain maturity moves from the Foundational band toward the low end of the Comprehensive band (1.6 to 2.0). The Verification and Operations functions move from low-Foundational toward mid-Foundational, closing the conformance-test and logging-baseline gaps across the seven archetypes. The Governance function moves from mid-Foundational to low-Comprehensive. The largest score gains come from practices where the Q1–Q2 L1 foundation was weakest: typically ST, IR, and ML.

Part V, Reference

32. Glossary

AI Infrastructure Standards Policy. The first of the three priority AI/HAI infrastructure policies. Specifies per-archetype security baselines every component must meet before hosting production workloads, encryption, isolation, region/residency, observability minimums.

GPU / Accelerator Acceptable Use Policy. The second priority policy. Enumerates who may run what workloads on what fleet with what data classification, with a disclosure obligation to the SM-Infrastructure inventory and attestation at hire and annually.

AI Infra Intake / Provisioning Gate Policy. The third priority policy. Makes intake mandatory before production provisioning for all seven archetypes, lists the required gate artifacts by archetype, exposes an amnesty path for previously ungated production instances, and names the gate-decision authority.

AI/HAI infrastructure archetype. One of seven categories of compute and platform substrate the organization operates to host and serve AI/HAI systems: inference endpoint / model-serving cluster, model registry, GPU/accelerator fleet, orchestrator/control plane, vector-store infrastructure, AI-specific CI/CD, feature store / online serving cache.

AI/HAI infrastructure inventory. The single source of truth for all AI/HAI infrastructure components the organization operates, owned by the program lead. Seeded from cloud-provider asset APIs, Kubernetes workload signals, IaC repos, model-registry APIs, GPU-spend signals, egress logs, and vector-store listings.

Critical / High / Medium / Low. The four risk tiers introduced at SM-Infrastructure L2. Driven by tier of AI/HAI software hosted, multi-tenancy isolation, customer exposure, compute scale and concentration, data classification of data passing through, decision-affecting use hosted, and geographic scope.

EA, Excessive Agency. One of the four HAI-specific TTPs. In Infrastructure terms, components granted broader IAM or network reach than the workload requires.

AGH, Agent Goal Hijack. One of the four HAI-specific TTPs. In Infrastructure terms, orchestrator control-plane workflow injection redirecting execution under the orchestrator's trusted identity.

HCC, HAIAMM Cloud Controls Taxonomy. Canonical control catalog for cloud infrastructure, cross-mapped to ATLAS mitigations.

HCT, HAIAMM Cloud Threat Taxonomy. Canonical catalog of cloud-infrastructure threats organized under BadCode, BadAction, BadPrincipal, BadPermissions, covering risks ATLAS does not enumerate (standing IAM, identity misuse).

HAI TTPs (EA, AGH, TM, RA). The four AI-specific threat-tactic categories carried throughout HAIAMM v3.0: Excessive Agency, Agent Goal Hijack, Tool Misuse, Rogue Agents.

Model extraction. Reconstruction or approximation of a hosted model's weights or behavior via API queries to the inference endpoint. A primary inference-endpoint threat (ATLAS AML.T0024).

Priority compliance map. A one-page artifact tying each priority regulatory requirement to the specific organizational policy that carries it.

RA, Rogue Agents. One of the four HAI-specific TTPs. In Infrastructure terms, autonomous agents running on the infrastructure drift from intended behavior.

Reference pattern. A vetted "green path" architecture pattern published per AI/HAI infrastructure archetype. Platform teams reach for the pattern first; deviations require design review.

REM, Requirements-Evidence Map. A per-component map that records, for each applicable requirement in the AI/HAI Infrastructure Requirements Pack, whether the requirement is Met, Met-with-compensating-control, Gap-accepted, or Not-applicable, with a citation to evidence.

Residual-state clearing. A mechanism that wipes GPU memory between jobs on shared hardware, preventing cross-tenant residual-state leakage. A primary GPU-fleet control.

Risk-tier rubric. A short table introduced at SM-Infrastructure L2 deriving a deterministic risk tier from auditable inputs. Drives the differential intensity of every downstream practice's L2 and L3 work.

Shadow AI infrastructure. Ungoverned AI infrastructure components, untagged GPU instances, unsanctioned model registries, inference endpoints from personal cloud accounts, AI CI/CD pipelines outside the IaC standard. The program's primary L1 outcome is to make these visible, attributable, and trending down.

Shadow-AI-infra ratio. Unsanctioned AI/HAI infrastructure components in production divided by total components in production. A primary L1 outcome metric. Reported quarterly and trending down; reported per tier at L2.

SLSA (Supply-chain Levels for Software Artifacts). A signed provenance framework. SLSA L2/L3 attestations gate model-registry promotion and CI/CD artifact deployment.

TM, Tool Misuse. One of the four HAI-specific TTPs. In Infrastructure terms, infrastructure tools or APIs invoked for attacker purposes.

Workload identity. Platform-native, short-lived identity for service principals (AWS IAM Roles for Service Accounts, GCP Workload Identity Federation, Azure Managed Identity, Kubernetes service account with OIDC), used in place of long-lived service-account keys.

33. Reference frameworks

This handbook is one of six domain handbooks that, together with a master handbook, constitute HAIAMM v3.0. The frameworks named here are referenced throughout. They are listed by name only; consult the issuing body's current published version when running an assessment.

Maturity-model lineage.

• OWASP SAMM (Software Assurance Maturity Model). HAIAMM borrows SAMM's lifecycle shape (Governance, Building, Verification, Operations) and practice-per-function structure.
• BSIMM (Building Security In Maturity Model). HAIAMM borrows the observational "this is what organizations actually do" posture at higher maturity levels.

AI-governance and cloud-infrastructure frameworks (complementary).

• NIST AI RMF 1.0 + Playbook. The risk-management-framework counterpart to HAIAMM's maturity-model shape; MAP and MANAGE functions align closely to Infrastructure-domain TA/SR and EH/IM/ML work.
• ISO/IEC 42001 (AI Management System). A management-system standard for AI. HAIAMM Infrastructure-domain practices supply the infrastructure operational evidence an ISO 42001 AIMS requires.
• ISO/IEC 27001 / 27002. General ISMS and controls. Annex A.5 supplier relationships, A.8 asset management apply.
• NIST SP 800-53 / SP 800-171 / SP 800-204. Cloud-security control baselines that intersect AI infrastructure.
• CNCF AI Working Group / TAG Security. AI workload security on Kubernetes, HAIAMM contributes and consumes at L3.
• OpenSSF AI. Open Source Security Foundation working group on AI, supply-chain security, signed artifacts, SLSA provenance for ML.
• FinOps Foundation AI Infrastructure SIG. GPU fleet governance and concentration-risk frameworks.

Regulations applicable to AI/HAI infrastructure.

• EU AI Act. Article 15 (accuracy, robustness, cybersecurity), Article 12 (logging), Article 26 (deployer duties), Annex III (high-risk classification), Article 73 (serious-incident reporting).
• GDPR. Article 32 (security of processing), Articles 44–49 (international transfers / region pinning), Article 33 (breach notification).
• SOC 2. CC6 / CC7 / CC8 trust services criteria.
• HIPAA. Safeguards on infrastructure processing PHI.
• PCI-DSS. Controls on infrastructure in the cardholder data environment.
• FedRAMP (where applicable). Cloud-security baseline for US federal and public-sector AI infrastructure.
• Sector-specific. FINRA/SEC model-risk infrastructure obligations, HHS/FDA AI/SaMD infrastructure, NYDFS Part 500.

Threat taxonomies.

• MITRE ATLAS (Adversarial Threat Landscape for AI Systems). Canonical adversarial-ML reference. Infrastructure-domain TA consumes ATLAS technique IDs and contributes back at L3. ATLAS is used throughout this handbook in TA archetype threat models, SR requirements traceability, SA reference patterns (with AML.M00xx mitigation entries), and ST test batteries.
• HAIAMM Cloud Threat Taxonomy (HCT). Cloud-infrastructure threats organized under BadCode / BadAction / BadPrincipal / BadPermissions, covering risks ATLAS does not enumerate (standing IAM, identity misuse). Cross-referenced throughout TA-Infrastructure.
• HAIAMM Cloud Controls Taxonomy (HCC). Canonical control catalog for cloud infrastructure, cross-mapped to ATLAS mitigations.
• OWASP Top 10 for LLM Applications. Threat reference relevant to inference endpoints and orchestrators.

Industry communities.

• CNCF AI Working Group / TAG Security. AI workload security on Kubernetes, HAIAMM contributes at L3.
• OpenSSF AI. Supply-chain security for ML, SLSA provenance, signed-artifact policy for model registries and AI CI/CD.
• FinOps Foundation AI Infrastructure SIG. GPU fleet governance and concentration-risk benchmarks.
• CSA AI Safety Initiative / AI Controls Matrix. Cross-organization AI controls work; HAIAMM contributes the infrastructure controls at L3.
• Sector ISACs. FS-ISAC, H-ISAC, IT-ISAC, and others provide intelligence sharing for AI infrastructure incidents.

HAIAMM canonical companions.

• HAIAMM-v3.0-Framing.md, model master document; canonical definitions for the 12 practices, 6 domains, 3 maturity levels, cell template, dependency graph, through-lines, and authoring rules.
• AI-Attack-Taxonomy.md (HAA), high-impact AI attacks catalog cross-referenced to MITRE ATLAS.
• Cloud-Threat-Taxonomy.md (HCT), cloud-infrastructure threats organized under BadCode / BadAction / BadPrincipal / BadPermissions.
• Cloud-Controls-Taxonomy.md (HCC), controls cross-mapped to ATLAS mitigations.
• Threat-Modeling-Methodology.md, per-system threat-modeling methodology with per-cloud TM templates (AWS, GCP, Azure) referenced by TA-Infrastructure L2.

Threat-tactic categories specific to HAIAMM (reproduced for reference).

• EA, Excessive Agency. Infrastructure components granted broader IAM or network reach than the workload requires.
• AGH, Agent Goal Hijack. Orchestrator workflow injection redirecting execution under the orchestrator's trusted identity.
• TM, Tool Misuse. Infrastructure tools or APIs invoked for attacker purposes.
• RA, Rogue Agents. Autonomous agents running on infrastructure drift from intended behavior.

34. Change log

End of HAIAMM v3.0 Infrastructure Domain Handbook.