Environment Hardening (EH) - Infrastructure Assessment

Assessment questionnaire for measuring maturity. Answer each question honestly based on current, implemented practices.

v3.0 questionnaire. Source of truth: ../practices/EH-Infrastructure-OnePager.md. Canonical subject and through-lines: ../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

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

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

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

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

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

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

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

Instructions:

Answer based on current practices, not plans
“Yes” requires documented evidence
Complete all Level 1 questions before Level 2
Partial implementation = “No”

↓ Download as Markdown