> **v3.0 questionnaire.** Source of truth: [`../practices/EH-Infrastructure-OnePager.md`](../practices/EH-Infrastructure-OnePager.md). Canonical subject and through-lines: [`../HAIAMM-v3.0-Framing.md`](../HAIAMM-v3.0-Framing.md) §8.

---

# Environment Hardening (EH) - Infrastructure Domain
## HAIAMM Assessment Questionnaire v3.0

**Practice:** Environment Hardening (EH)
**Domain:** Infrastructure
**Purpose:** Assess organizational maturity in hardening the identity, network, compute, supply-chain, and egress/DLP envelopes for AI/HAI infrastructure hosting inference endpoints, model registries, GPU fleets, orchestrators, vector stores, AI CI/CD, and feature stores

---

## Instructions

- Answer each question honestly based on **current, implemented practices** (not plans or aspirations)
- Each question has two components: **Evidence** (what you did) and **Outcome Metrics** (how well it worked)
- **Scoring uses 4 tiers:** Fully Mature (1.0), Implemented (0.67), Partial (0.33), Not Implemented (0.0)
- **Answer progressively** - Complete all Level 1 questions before Level 2
- **Level progression** - Achieve ALL questions at lower level before advancing
- **Baseline first** - Record current metric values before setting targets

---

## Scoring Methodology

Each question is scored on a 4-tier scale:

| Score | Label | Criteria |
|-------|-------|----------|
| 1.0 | Fully Mature | Evidence complete + ≥3 outcome metrics meet targets |
| 0.67 | Implemented | Evidence complete + 2 outcome metrics meet targets |
| 0.33 | Partial | Evidence partially complete + <2 outcome metrics meet targets |
| 0.0 | Not Implemented | No evidence of the control |

**Level Score** = Average of question scores within the level
**Overall Score** = Weighted average across levels (L1: 50%, L2: 30%, L3: 20%)

---

## 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.

---

### Question 1: Identity and Network Envelope Hardening

**Q1.1:** Does every AI infrastructure archetype component run under a dedicated workload identity with no long-lived service-account keys, with SSO + MFA on all AI infrastructure consoles, JIT for human admin access, and private endpoints for internal inference clusters with egress allowlists scoped to LLM-provider domains and own-VPC only?

**Evidence Required:**
- [ ] Workload identity configuration records for all seven archetypes (inference endpoint/model-serving cluster, model registry, GPU/accelerator fleet job runner, orchestrator/control plane, vector-store infrastructure, AI-specific CI/CD, feature store), platform-native workload identity in use; no static service-account keys
- [ ] Long-lived key discovery scan results confirming zero active long-lived keys in any archetype's runtime configuration
- [ ] IdP configuration records showing SSO/SAML/OIDC enforcement on model registry, vector-store, orchestrator, and cloud ML platform consoles, local account access disabled
- [ ] JIT access configuration for human admin access, ≤4-hour sessions, approval-gated, scoped to specific archetype component; standing admin access is a blocking finding
- [ ] Private endpoint or VPC-internal load balancer configuration for inference endpoints serving internal consumers, public ingress approved and WAF-covered where external service is required
- [ ] Egress allowlist configuration for inference endpoint and model registry workload identities, declared LLM-provider API domains and own-VPC destinations only; shadow-inference-endpoint alert wired for unexpected outbound traffic

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % AI infrastructure archetype components running under workload identity (no long-lived keys) | ___% | ___% | 100% | ☐ | |
| % AI infrastructure consoles (model registry, vector-store, orchestrator, cloud ML) requiring SSO + MFA | ___% | ___% | 100% | ☐ | |
| % inference endpoints with no unauthorized public ingress (private endpoint or approved-WAF-covered only) | ___% | ___% | 100% | ☐ | |
| Long-lived key findings resolved within 30 days of detection | ___% | ___% | 100% within SLA | ☐ | |

**Metric Collection Guidance:**
- **Workload identity coverage**: Reconcile SM-Infrastructure inventory against IAM audit; count archetype components with platform-native workload identity and no static keys. Source: IAM audit × SM-Infrastructure inventory
- **SSO + MFA coverage**: Audit IdP configuration for each AI infrastructure console entry. Source: IdP configuration audit
- **Public ingress coverage**: Audit cloud network policy for inference endpoints; count those without unauthorized public ingress. Source: cloud network policy audit
- **Long-lived key resolution SLA**: Count long-lived key findings resolved within 30 days / total findings. Source: IM-Infrastructure backlog

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No evidence of identity or network envelope hardening)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 2: Compute Envelope and GPU Residual-State Clearing

**Q2.1:** Do GPU/accelerator nodes enforce a clearing routine between jobs, with clearing events logged, any clearing failure draining the node within 4 hours, and are workload-namespace isolation and classification-aware scheduling enforced per archetype?

**Evidence Required:**
- [ ] GPU residual-state clearing routine configuration records (CUDA `cudaMemset` or driver-level scrub, or equivalent for non-CUDA accelerators), clearing runs before the next job's container starts, not only on OS reboot
- [ ] Clearing event telemetry records, a clearing event is logged per job transition; clearing failure triggers node drain and IM-Infrastructure finding within 4 hours
- [ ] Kubernetes namespace or cloud-equivalent isolation boundary configuration per archetype workload, dedicated namespace with its own service account
- [ ] Classification-aware scheduling configuration: node-pool separation by data classification tier; Confidential+ classification jobs run on dedicated node pools; untagged jobs blocked from classified node pools
- [ ] cgroup/quota enforcement records, CPU, memory, and GPU quota limits set per workload namespace; no unbounded GPU allocations from unregistered identities
- [ ] Service-mesh mTLS configuration (Istio PeerAuthentication/AuthorizationPolicy, Linkerd MeshTLSAuthentication, or equivalent) on inference-to-storage and inference-to-registry traffic paths

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % GPU/accelerator nodes with residual-state clearing enforced and logged between jobs | ___% | ___% | 100% | ☐ | |
| GPU clearing failure count, nodes with outstanding clearing failures (target zero) | ___ | ___ | 0 | ☐ | |
| % AI infrastructure archetype workloads in dedicated namespaces with classification-aware node-pool scheduling | ___% | ___% | 100% for Critical/High-tier | ☐ | |
| Unencrypted internal AI-infrastructure traffic paths (missing mTLS) | ___ | ___ | 0 | ☐ | |

**Metric Collection Guidance:**
- **GPU clearing coverage**: Audit GPU node configuration across all nodes in the AI infrastructure fleet; count nodes with clearing DaemonSet deployed and active. Source: node configuration audit × clearing-event telemetry
- **Clearing failure count**: Count nodes with an outstanding clearing failure not yet drained. Source: node management telemetry
- **Namespace isolation coverage**: Review Kubernetes namespace configurations for archetype workloads; verify dedicated namespaces with service account per archetype. Source: cluster configuration audit
- **Unencrypted traffic**: Audit service-mesh configuration for inference-to-storage and inference-to-registry paths; count paths missing mTLS enforcement. Source: service-mesh configuration audit

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No GPU clearing, namespace isolation, or mTLS)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 3: Supply-Chain and Egress/DLP Envelope Hardening

**Q3.1:** Are all AI infrastructure container images signed, SBOM-tracked at build time, and rejected at the deployment gate if unsigned, with DLP rules tuned for AI-infra-specific exfiltration patterns (bulk model-weight download, mass-embedding extraction, training-data export) deployed and active?

**Evidence Required:**
- [ ] Signed container image configuration (Sigstore/cosign, Notary v2, or equivalent) for all archetype container images; signing key managed in secrets vault
- [ ] Deployment admission controller configuration (OPA Gatekeeper, Kyverno, or cloud-native policy) in enforce mode, unsigned images rejected, not just warned
- [ ] SBOM generation configuration (SPDX or CycloneDX format) for each archetype container image at build time; SBOMs stored in artifact registry linked to image digest
- [ ] SCA tool CI configuration checking SBOMs against known-vulnerability feeds; blocking on critical CVEs for Critical-tier components; base-image patch SLA records (critical ≤7 days, high ≤30 days)
- [ ] Signed model artifact configuration in model registry, cosign or equivalent signature + provenance attestation (training job ID, eval-gate result, approver identity); registry promotion gate verifies signature
- [ ] DLP rule configuration covering AI-infra-specific exfiltration: bulk model-weight download from registry (checkpoint files exceeding volume threshold to external destinations), mass-embedding extraction (high-volume retrieval/export from vector store), training-data export from AI CI/CD (bulk dataset file exports)

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % AI infrastructure container images signed and SBOM-tracked at build time | ___% | ___% | 100% for Critical/High-tier; ≥90% overall | ☐ | |
| Unsigned image deployment-gate rejections, policy blocking enforced (not warn mode) | ☐ enforced / ☐ warn |, | enforced | ☐ | |
| Critical CVEs in AI-infra components patched within 7-day SLA | ___% | ___% | 100% within SLA | ☐ | |
| DLP rules tuned for AI-infra-specific exfiltration (model-weight, embedding, training-data) deployed and active | 0 / set | target set | target set defined + deployed | ☐ | |

**Metric Collection Guidance:**
- **Signed image coverage**: Audit artifact registry for AI infrastructure component images; count those with a valid signature and linked SBOM. Source: artifact registry telemetry
- **Gate enforcement mode**: Confirm admission controller is in enforce mode (not audit/warn) by checking controller configuration. Source: admission controller configuration
- **CVE patch SLA**: Count critical CVE findings in AI-infra components patched within 7 days / total critical findings. Source: SCA tool / ticketing system
- **DLP rule deployment**: Confirm AI-infra-specific exfiltration rules are active in DLP management console. Source: DLP management console

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No supply-chain controls or AI-infra DLP)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

## Maturity Level 2

**Objective:** Calibrate hardening depth per SM-Infrastructure L2 tier; 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.

---

### Question 4: Zero-Trust Critical-Tier Access and HSM-Rooted Key Management

**Q2.1:** Are 100% of Critical-tier archetype components running under 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?

**Evidence Required:**
- [ ] Dedicated VPC or VNet configuration for Critical-tier inference clusters and model registry backends, no shared routing with non-Critical-tier workloads; VPC endpoints replacing public internet egress; VPC flow logs retained at full fidelity
- [ ] HSM-rooted CMK configuration for Critical-tier model artifacts, inference-endpoint storage, GPU-fleet job outputs, and vector-store embedding indices (AWS CloudHSM, Azure Dedicated HSM, GCP Cloud HSM, or equivalent), keys non-exportable, not shared across archetypes or tenants
- [ ] JIT access policy records for Critical-tier model registry, GPU fleet management, orchestrator control plane, and vector-store admin, no standing admin permissions; all access ≤4-hour sessions, approval-gated, scoped to specific component
- [ ] SLSA L3+ provenance attestation configuration for Critical-tier CI/CD pipelines and model promotion workflows, hermetically sealed builds; deployment admission controller verifies SLSA L3 attestation before accepting Critical-tier deployment
- [ ] SM-Infrastructure inventory records showing hardening status per tier for each archetype component
- [ ] Tier-hardening gap tracking as open IM-Infrastructure findings

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier archetype components with dedicated VPC + HSM-rooted CMK | ___% | ___% | 100% | ☐ | |
| % Critical-tier archetype components with JIT-only human admin (no standing access) | ___% | ___% | 100% | ☐ | |
| % Critical-tier build and model-promotion pipelines producing SLSA L3+ provenance | ___% | ___% | ≥90% | ☐ | |
| Adaptive-policy tightening proposals from ML/IM signals reviewed and resolved within 5 business days | ___% | ___% | 100% | ☐ | |

**Metric Collection Guidance:**
- **VPC + HSM coverage**: Audit cloud network and KMS/HSM configuration for Critical-tier archetype components. Source: network + KMS policy audit × SM inventory
- **JIT access coverage**: Query IAM audit log for admin access events on Critical-tier consoles; verify all use JIT grants with no standing permissions. Source: IAM audit telemetry
- **SLSA L3+ coverage**: Query CI/CD provenance registry for Critical-tier build and promotion pipelines; count those producing SLSA L3+ attestations. Source: CI/CD provenance registry
- **Tightening proposal resolution SLA**: Count adaptive-policy proposals from ML/IM signals resolved within 5 business days / total proposals. Source: policy change log

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No zero-trust access or HSM-rooted keys for Critical-tier)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 5: Infrastructure-Layer Per-Tenant Isolation for Critical-Tier

**Q2.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 review and ST-Infrastructure isolation tests wired into CI?

**Evidence Required:**
- [ ] Infrastructure-layer per-tenant isolation configuration for Critical-tier multi-tenant inference endpoints: dedicated Kubernetes namespace per tenant with NetworkPolicy default-deny, or dedicated node pool per tenant, or separate inference cluster per tenant
- [ ] Per-tenant CMK configuration in vector store and model registry for Critical-tier, each tenant's embeddings and model artifacts encrypted under a separate CMK; shared-key architecture is a blocking finding
- [ ] IR-Infrastructure implementation review records confirming isolation for Critical-tier multi-tenant components (annual minimum for Critical-tier)
- [ ] ST-Infrastructure isolation test configuration wired into CI for Critical-tier multi-tenant components, isolation regressions detected in CI, not only at annual IR review
- [ ] Enhanced DLP configuration for Critical-tier: content inspection on model-weight downloads and embedding extractions; volume-threshold alerts for mass extraction
- [ ] Tier-treatment matrix document published and enforced at provisioning and on tier change

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier multi-tenant inference/vector-store components with infrastructure-layer per-tenant isolation (confirmed by IR review + ST test) | ___% | ___% | ≥90% | ☐ | |
| Per-tenant CMK enforced for Critical-tier multi-tenant vector store and model registry tenants | ___% | ___% | 100% | ☐ | |
| ST-Infrastructure isolation tests wired into CI for Critical-tier multi-tenant components | ___% | ___% | 100% of Critical-tier multi-tenant components | ☐ | |
| Tier-hardening matrix enforced at provisioning and on tier-change (not only at initial provisioning) | ☐ yes / ☐ no |, | yes | ☐ | |

**Metric Collection Guidance:**
- **Infrastructure-layer isolation coverage**: Review IR-Infrastructure findings for Critical-tier multi-tenant components; confirm ST isolation tests pass. Source: IR findings × SA pattern conformance
- **Per-tenant CMK coverage**: Audit KMS key assignments for Critical-tier multi-tenant vector store and model registry. Source: KMS audit
- **CI isolation test coverage**: Review CI pipeline configurations for Critical-tier multi-tenant components; confirm ST isolation test is present and passing. Source: CI/CD configuration
- **Tier-change enforcement**: Verify provisioning pipeline watches for tier-change events in SM-Infrastructure and re-applies hardening profile. Source: provisioning pipeline configuration

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No infrastructure-layer per-tenant isolation)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 6: Adaptive Tightening from ML-Infrastructure and IM-Infrastructure Signals

**Q2.3:** Is an adaptive-tightening pipeline operational at L2, with ML-Infrastructure detection signals (GPU clearing failures, vector-store mass-extraction, shadow-endpoint emergence) and IM-Infrastructure incident patterns generating human-approved tightening proposals reviewed within 5 business days?

**Evidence Required:**
- [ ] ML-Infrastructure signal wiring: GPU residual-state clearing failure trend → node-drain-and-clearing-audit proposal; vector-store mass-extraction pattern → retrieval-rate-limit tightening proposal + egress-policy narrowing; shadow-inference-endpoint detection → egress-block proposal + SM-Infrastructure intake alert
- [ ] IM-Infrastructure signal wiring: post-incident review records identifying hardening gaps → hardening-baseline update proposals; Critical-tier incident with supply-chain compromise → SLSA-level upgrade proposal
- [ ] Human-approval gate configuration, security platform engineer approval before deploy
- [ ] Machine-readable change log with source signal, approval record, and downstream notification per change
- [ ] Evidence that downstream archetype teams are notified within 24 hours of a tightening change affecting their component
- [ ] Monthly SASE/IAM policy drift audit records; deviations from tier-treatment matrix tracked as IM-Infrastructure findings within 5 business days

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Adaptive-policy tightening proposals from ML-Infrastructure or IM-Infrastructure signals per quarter | 0 | ___ | tracked; growing | ☐ | |
| % proposals reviewed and resolved within 5 business days | ___% | ___% | 100% | ☐ | |
| SASE/IAM policy drift deviations tracked as IM-Infrastructure findings within 5 business days | ___% | ___% | 100% | ☐ | |
| % Critical-tier components whose hardening status in SM inventory is current (reflects actual deployed controls) | ___% | ___% | 100% | ☐ | |

**Metric Collection Guidance:**
- **Tightening proposal count**: Count adaptive-policy proposals generated from ML-Infrastructure or IM-Infrastructure signals per quarter. Source: policy change log
- **Resolution SLA**: Count proposals resolved within 5 business days / total proposals. Source: policy change log × IM backlog
- **Drift finding SLA**: Count SASE/IAM policy drift deviations flagged as IM-Infrastructure findings within 5 business days / total deviations. Source: policy audit × IM backlog
- **Inventory currency**: Review SM-Infrastructure records for Critical-tier components; compare declared hardening status against last IR-Infrastructure review findings. Source: SM-Infrastructure inventory × IR findings

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No adaptive-tightening pipeline at L2)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

## Maturity Level 3

**Objective:** Express all EH-Infrastructure controls as Terraform/Pulumi/Helm IaC modules; implement adaptive policy tightening driven by ML-Infrastructure detections and IM-Infrastructure incidents; and contribute AI infrastructure hardening baselines to CNCF, OpenSSF AI, and sector ISACs.

---

### Question 7: Hardening-as-Code, IaC Modules for All EH-Infrastructure Controls

**Q3.1:** Are all EH-Infrastructure controls expressed as version-controlled, authoritative IaC modules, identity, network, compute, supply-chain, and egress/DLP envelopes, with drift detection running hourly and ≥70% of low-risk drift auto-remediated?

**Evidence Required:**
- [ ] Identity-envelope IaC module: workload-identity binding per archetype (IRSA/Workload Identity/Managed Identity/Kubernetes OIDC), JIT access policy configuration, SSO enforcement on AI-infra consoles, audit-log pipeline wiring; parameterized by archetype and tier
- [ ] Network-envelope IaC module: VPC/VNet private-endpoint configuration, NetworkPolicy default-deny templates, service-mesh mTLS configuration (Istio PeerAuthentication or Linkerd MeshTLSAuthentication), egress allowlist NetworkPolicy or SASE rule
- [ ] Compute-envelope IaC module: Kubernetes namespace isolation template (ResourceQuota, LimitRange, NetworkPolicy), GPU node-pool configuration with clearing-enforcement DaemonSet, classification-aware node-selector and taint/toleration definitions
- [ ] Supply-chain IaC module: Sigstore/cosign signing pipeline component, SBOM generation step (Syft or cdxgen), SLSA provenance generation step, admission-controller policy (Kyverno or OPA Gatekeeper) for signature and SBOM verification; parameterized by tier (SLSA L2 for High, SLSA L3+ for Critical)
- [ ] Egress/DLP IaC module: DLP policy configuration for AI-infra-specific exfiltration patterns; classification-aware NetworkEgress policy per archetype workload identity
- [ ] Drift-detection pipeline running hourly; low-risk drift auto-remediated; high-risk drift (workload identity replaced with static key, public endpoint opened, unsigned image deployed, GPU clearing DaemonSet removed) triggers human-review alert within 2 business days + IM-Infrastructure finding

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % EH-Infrastructure controls expressed as IaC (version-controlled, authoritative deployed source, not stubs) | ___% | ___% | ≥90% | ☐ | |
| IaC drift auto-remediation rate for low-risk findings | ___% | ___% | ≥70% | ☐ | |
| High-risk drift findings human-reviewed within 2 business days | ___% | ___% | 100% | ☐ | |
| New AI infrastructure components auto-provisioned with tier-appropriate hardening within 24h of SM-Infrastructure registration | ___% | ___% | 100% | ☐ | |

**Metric Collection Guidance:**
- **IaC coverage**: Count EH-Infrastructure controls with authoritative IaC (deployed state = IaC spec, not stub) / total EH-Infrastructure controls. Source: IaC module registry
- **Auto-remediation rate**: Count low-risk drift findings auto-remediated / total low-risk drift findings per quarter. Source: remediation telemetry
- **High-risk drift review SLA**: Count high-risk drift findings with human review within 2 business days / total high-risk findings. Source: policy change log × IM-Infrastructure backlog
- **Auto-provisioning SLA**: Compare SM-Infrastructure registration timestamps against IaC provisioning completion within 24h. Source: inventory × IaC provisioning telemetry

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No IaC for EH-Infrastructure controls)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 8: Adaptive Policy Tightening from ML-Infrastructure and IM-Infrastructure Signals

**Q3.2:** Is an adaptive-policy pipeline operational at L3, with ML-Infrastructure detections and IM-Infrastructure incident patterns generating human-approved tightening proposals on a tracked cadence, every change traceable to a source signal, and downstream archetype teams notified within 24 hours?

**Evidence Required:**
- [ ] Adaptive-tightening pipeline wiring ML-Infrastructure signals: GPU clearing failure trend → node-drain-and-clearing-audit proposal; vector-store mass-extraction → retrieval-rate-limit tightening proposal + egress-policy narrowing; shadow-endpoint detection → egress-block proposal + SM intake alert
- [ ] Adaptive-tightening pipeline wiring IM-Infrastructure post-incident review records: hardening gap → hardening-baseline update proposal; supply-chain incident → SLSA-level upgrade proposal
- [ ] Human-approval gate for all proposals (security platform engineer approval before deploy)
- [ ] Machine-readable change log records, source signal (ML detection trend ID or IM incident ID), approval record, downstream notification timestamp per entry
- [ ] Feedback loop to TA-Infrastructure archetype threat library and SR-Infrastructure requirements pack for changes reflecting new threat patterns
- [ ] Signal feed freshness monitoring, ML-Infrastructure and IM-Infrastructure feeds checked weekly; stale feeds (>7 days without processed event) flagged

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Adaptive-policy changes per quarter traceable to ML-Infrastructure or IM-Infrastructure source signal | 0 | ___ | tracked; growing | ☐ | |
| % adaptive-policy proposals human-approved before deploy | ___% | ___% | 100% | ☐ | |
| Downstream archetype teams notified within 24h of tightening change | ___% | ___% | 100% | ☐ | |
| Stale signal feeds (>7 days without processed ML-Infrastructure or IM-Infrastructure event) | ___ | ___ | 0 stale feeds | ☐ | |

**Metric Collection Guidance:**
- **Traceable changes**: Count policy changes in change log with valid source signal reference per quarter. Source: policy change log
- **Human-approval rate**: Count proposals deployed with approval record / total proposals deployed. Source: policy change log
- **Notification SLA**: Count tightening changes with downstream team notification within 24h / total. Source: notification log
- **Signal feed freshness**: Check last-processed timestamp for each ML-Infrastructure and IM-Infrastructure feed. Source: pipeline monitoring

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No adaptive-policy pipeline for EH-Infrastructure)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 9: Industry Hardening Baseline Contributions

**Q3.3:** Does the program contribute ≥2 AI infrastructure hardening baselines per year to industry bodies, CNCF TAG Security, OpenSSF AI Infrastructure Working Group, or sector ISACs, with documented adoption and internal practice aligned with the published version?

**Evidence Required:**
- [ ] Contribution records showing ≥2 substantive submissions per year to CNCF TAG Security, OpenSSF AI Infrastructure Working Group, or sector ISACs (FS-ISAC, H-ISAC, IT-ISAC AI working groups), Kubernetes workload-identity patterns for AI inference, GPU clearing reference implementation, NetworkPolicy templates, signed-artifact pipeline templates
- [ ] Evidence of adoption or citation of contributed baselines by the recipient body (CNCF reference artifact, OpenSSF module, ISAC advisory)
- [ ] Maintenance records showing internal practice stays aligned with the published external version, not diverged
- [ ] Auto-provisioning trigger configuration: SM-Infrastructure registration event fires IaC provisioning workflow within 24 hours; tier-change event triggers hardening-profile upgrade
- [ ] Evidence that at least one new component was auto-provisioned within the 24-hour SLA in the last quarter
- [ ] Quarterly adaptive-policy change log records traceable to ML-Infrastructure detections and IM-Infrastructure incident patterns

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Industry hardening baseline contributions per year | 0 | ___ | ≥2 | ☐ | |
| New AI infrastructure components auto-provisioned with tier-appropriate hardening within 24h of SM-Infrastructure registration | ___% | ___% | 100% | ☐ | |
| Contributed baselines maintained upstream (internal practice aligned with published version) | ☐ yes / ☐ no |, | yes | ☐ | |
| Adaptive-policy change log machine-readable with source signal reference field confirmed | ☐ yes / ☐ no |, | yes | ☐ | |

**Metric Collection Guidance:**
- **Contribution count**: Count published contributions with named recipient body and contribution artifact per calendar year. Source: contribution log
- **Auto-provisioning SLA**: Compare SM-Infrastructure registration timestamps against IaC provisioning completion timestamps; count within 24h / total. Source: inventory × IaC provisioning telemetry
- **Maintenance alignment**: Review most recent version of each contributed baseline; confirm it reflects current internal practice. Source: contribution log × practice review
- **Change log format**: Confirm policy change log is machine-readable (JSON/YAML) with source signal reference field populated on each entry. Source: policy change log audit

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No industry contributions or auto-provisioning)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

## Summary Scorecard

| Level | Question | Score (0.0 / 0.33 / 0.67 / 1.0) |
|-------|----------|----------------------------------|
| L1 | Q1: Identity and Network Envelope | ___ |
| L1 | Q2: Compute Envelope and GPU Residual-State Clearing | ___ |
| L1 | Q3: Supply-Chain and Egress/DLP Envelope | ___ |
| L2 | Q4: Zero-Trust Critical-Tier Access and HSM-Rooted Keys | ___ |
| L2 | Q5: Infrastructure-Layer Per-Tenant Isolation | ___ |
| L2 | Q6: Adaptive Tightening from ML/IM Signals (L2) | ___ |
| L3 | Q7: Hardening-as-Code IaC Modules | ___ |
| L3 | Q8: Adaptive Policy Tightening (L3) | ___ |
| L3 | Q9: Industry Baseline Contributions | ___ |

**L1 Score** (avg Q1–Q3): ___
**L2 Score** (avg Q4–Q6): ___
**L3 Score** (avg Q7–Q9): ___
**Overall Score** (L1×0.5 + L2×0.3 + L3×0.2): ___

---

**Document Version:** HAIAMM v3.0
**Practice:** Environment Hardening (EH)
**Domain:** Infrastructure
**Questionnaire Date:** 2026-05-15
**Author:** Verifhai