Environment Hardening (EH)

Infrastructure Domain - HAIAMM v3.0

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: (1) the identity envelope, workload identity for every infrastructure component (no long-lived service-account keys), JIT for all human admin access, SSO + MFA on cloud consoles, model registry consoles, vector-store consoles, and orchestrator UIs, and an audit log for every console action; (2) the network envelope, private endpoints for internal inference clusters (no public ingress), 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; (3) 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, cgroup and quota enforcement, and per-classification-tier node pools; (4) the supply-chain envelope, signed container images, SBOM for all AI-infra components, base-image patch SLA, signed model artifacts in the registry, signed CI/CD pipeline definitions, and SLSA L3+ for Critical-tier components; (5) the egress/DLP envelope, DLP rules tuned for AI-infra-specific exfiltration: bulk model-weight download from the registry, mass-embedding extraction from the vector store, and training-data export from AI CI/CD pipelines, with classification-aware egress policy preventing regulated content from crossing boundaries 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 attackers who compromise 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 has, IAM, network policies, node configuration, container signing, CI/CD secrets management, for the seven archetypes that make up the AI infrastructure surface.

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

At this level, existing cloud and platform controls are AI-infrastructure-aware. Every archetype component runs under a dedicated workload identity. GPU residual-state clearing is enforced between jobs. Model registry and vector-store consoles require SSO + MFA. Inference endpoints have no public ingress unless explicitly approved. Container images are signed and SBOM-tracked. DLP rules cover bulk model-weight and embedding exfiltration patterns. Every archetype in the SM-Infrastructure inventory has a hardening status record.

Dependencies

• SM-Infrastructure L1 (required): the inventory and archetype taxonomy identify which components exist and which envelope dimensions apply; without the inventory, hardening scope is guesswork.
• PC-Infrastructure L1 (required): the AI Infrastructure Security Policy and priority compliance map define what to enforce at each envelope; tier definitions from SM-Infrastructure L2 drive per-tier hardening depth at L2.
• SA-Infrastructure L1 (required): reference patterns define the "green path", workload-identity model, private-endpoint configuration, node-pool separation, signed-artifact pipeline, that hardening controls must enable for sanctioned workloads and detect deviations from for unsanctioned ones.
• Supports / unblocks: ML-Infrastructure L1 (identity and network signals these controls emit feed monitoring), ST-Infrastructure L1 (tests exercise the hardening controls directly), IM-Infrastructure L1 (infrastructure incidents often originate at the control surfaces hardened here).

Desired Outcomes

• Every AI infrastructure component in production runs under a dedicated workload identity; no shared or long-lived service-account keys in any archetype's runtime configuration.
• Human admin access to model registry, vector-store, orchestrator, and cloud consoles requires SSO + MFA; every console action produces an audit log entry.
• Inference endpoints have no public ingress unless explicitly approved and documented; internal inference clusters use private endpoints only.
• GPU/accelerator nodes enforce residual-state clearing between jobs; no job accesses tensor state from a prior job belonging to a different tenant or classification tier.
• All container images for AI infrastructure components are signed; SBOM generated at build time; unsigned images rejected at the deployment gate.
• DLP rules tuned for AI-specific exfiltration (bulk model-weight download, mass-embedding extraction, training-data export) are deployed and active.

Activities

A) Harden the identity envelope

For every AI infrastructure archetype registered in the SM-Infrastructure inventory, establish and enforce a minimum identity hardening baseline:

• Workload identity (no long-lived keys): every archetype, inference endpoint / model-serving cluster, model registry, GPU/accelerator fleet job runner, orchestrator / control plane, vector-store infrastructure, AI-specific CI/CD, 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, 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 migrated to workload identity within 30 days.
• JIT for human admin access: no standing admin permissions on any AI infrastructure component; human operators request access just-in-time (≤4-hour sessions, approval-gated, scoped to the specific archetype component); JIT access grants are logged and reviewable; standing admin access to any archetype console is a blocking finding.
• SSO + MFA on AI infrastructure consoles: model registry web console, vector-store management console, orchestrator UI, cloud-provider ML platform consoles (SageMaker, Vertex AI, Azure ML, Bedrock), and AI-specific CI/CD UIs all require SSO/SAML/OIDC; local account access is disabled for org-domain identities; MFA always enforced.
• Audit log every console action: every human action taken in a model registry, vector-store, orchestrator, or cloud ML console (create, update, delete, promote, download, configuration change) is written to an append-only audit log; audit log access is separated from the archetype operator role.

B) Harden the network envelope

• Private endpoints for internal inference clusters: inference endpoints serving internal consumers (other services within the VPC) use private endpoints / VPC-internal load balancers only; no public ingress on inference endpoints that do not serve external customers; public ingress requires explicit approval, documentation, and WAF coverage.
• Egress allow-list (LLM-provider domains + own-VPC only): egress from inference endpoint workload identities and model-registry workload identities is allowlisted to declared LLM-provider API domains and own-VPC destinations only; unexpected outbound traffic to undeclared AI-provider domains triggers a shadow-inference-endpoint alert routed to SM-Infrastructure intake.
• Per-tenant network segmentation: inference clusters serving multiple tenants enforce per-tenant network namespaces (Kubernetes NetworkPolicy, VPC subnet per tenant, or equivalent) at the infrastructure layer; application-layer tenant filtering without infrastructure-layer segmentation is not sufficient for Critical-tier.
• Service-mesh mTLS: service-mesh mTLS is enforced on all inference-to-storage and inference-to-registry traffic paths; unencrypted internal AI-infrastructure traffic is a blocking finding.

C) Harden the compute envelope

• Workload-namespace isolation: each archetype workload runs in a dedicated Kubernetes namespace (or cloud-equivalent isolation boundary) with its own service account; cross-namespace access requires an explicit NetworkPolicy allow rule; default-deny namespace egress enforced.
• GPU residual-state clearing: GPU/accelerator nodes enforce a clearing routine between jobs that wipes GPU memory (CUDA cudaMemset or driver-level scrub, or equivalent for non-CUDA accelerators) before the next job's container starts; the clearing routine is logged (residual-state-clearing event per ML-Infrastructure L1 logging baseline); clearing failures are treated as blocking, the node is drained and taken offline until the clearing is confirmed.
• Classification-aware scheduling: the Kubernetes scheduler (or cloud ML scheduler) enforces node-pool separation by data classification tier; a job tagged with a Confidential or higher classification label lands only on a dedicated node pool; untagged jobs are blocked from running on classified node pools.
• cgroup/quota enforcement: CPU, memory, and GPU quota limits are set per workload namespace; no unbounded GPU allocations from unregistered identities; resource-limit enforcement prevents cost-abuse and accidental GPU acquisition by unsanctioned workloads.

D) Harden the supply-chain envelope

• Signed container images: all container images for AI infrastructure components (inference server, model registry, vector-store backend, orchestrator, feature-store, CI/CD runner) are signed at build time using Sigstore / cosign / Notary v2 or equivalent; deployment admission controllers (OPA Gatekeeper, Kyverno, or cloud-native policy) reject unsigned images; the signing key is managed in the secrets vault (not in CI/CD environment variables).
• SBOM for all AI-infra components: a software bill of materials (SBOM) in SPDX or CycloneDX format is generated at build time for each archetype container image; SBOMs are stored in the artifact registry and linked to the image digest; an SCA tool checks SBOMs against known-vulnerability feeds on every build and alerts on critical CVEs; blocking on critical SCA findings for Critical-tier components.
• Base-image patch SLA: base OS images for AI infrastructure components are patched on the following SLA: critical CVEs ≤7 days, high CVEs ≤30 days; automated base-image rebuild pipelines produce patched images; deployment automation rolls out patched images without manual intervention.
• Signed model artifacts in registry: model artifacts promoted to the model registry carry a cryptographic signature (cosign or equivalent) and a provenance attestation (training job ID, eval-gate result, approver identity); the registry's promotion gate verifies the signature before accepting a new model version; unsigned model artifacts are rejected.
• Signed CI/CD pipeline definitions: AI-specific CI/CD pipeline definitions (GitHub Actions workflows, GitLab CI/CD YAML, Tekton pipelines, or equivalent) are stored in version control and signed; any unsigned or unreviewed pipeline definition that touches model promotion or artifact signing is a blocking finding.

E) Harden the egress/DLP envelope

• DLP tuned for AI-infra-specific exfiltration: extend existing DLP rules 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 classification of the content being exported.
• Classification-aware egress policy: regulated data (PII, PHI, PCI) cannot leave the AI infrastructure boundary without an explicit approval gate; an egress policy attached to each archetype's workload identity blocks outbound traffic to non-allowlisted 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.

Outcome Metrics (L1)

Process Metrics (leading)

• Workload-identity migration cadence, long-lived key findings resolved within 30 days of detection; open count tracked weekly.
• JIT access log reviewed monthly; standing access grants exceeding 4-hour time limit trigger an alert and IM finding.
• GPU clearing-failure count, tracked per node; any node with a clearing failure drained within 4 hours; count trending to zero.
• SBOM/SCA cadence, critical CVE findings in AI-infra components reviewed and patched within 7 days; high within 30 days; open count tracked.
• Signed-image rejection rate, deployment gate rejections logged and reviewed daily; legitimate rejections (unsigned third-party base images) tracked separately from policy violations.

Effectiveness Metrics (business value)

• Lateral movement surface reduced, post-incident reviews that identify shared credentials as a contributing factor trending to zero after workload-identity enforcement.
• Shadow-inference-endpoint discovery, new AI inference endpoints detected via egress allow-list alerts and routed to SM intake rather than discovered post-incident.
• Supply-chain incident surface, critical CVEs in AI-infra components patched before exploitation; SBOM enables rapid impact assessment when a new CVE is disclosed for an AI-infra dependency.

Success Criteria

• 100% of AI infrastructure archetype components running under workload identity; 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 append-only audit log.
• GPU residual-state clearing enforced and logged on 100% of GPU/accelerator nodes; no clearing failures outstanding.
• 100% of Critical/High-tier AI infrastructure container images signed and SBOM-tracked; unsigned images rejected at deployment gate.
• 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 SM-Infrastructure L2 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

At this level, hardening is calibrated by risk tier. Critical-tier archetypes, an inference endpoint processing regulated data, a model registry carrying proprietary fine-tuned weights, a GPU fleet running multi-tenant workloads, receive a hardened envelope that would be excessive for Low-tier: dedicated VPC, HSM-rooted keys, JIT-only admin with no standing access, SLSA L3+ supply-chain provenance, and enhanced DLP with content-inspection. Low-tier archetypes stay on the L1 baseline. The tier-treatment matrix drives every hardening decision and is enforced at provisioning.

Dependencies

• EH-Infrastructure L1 (required): baseline identity, network, compute, supply-chain, and egress/DLP envelope controls are the substrate L2 calibration differentiates.
• SM-Infrastructure L2 (required): the tier rubric (Critical / High / Medium / Low) and tier-treatment matrix determine which hardening depth applies to each archetype component; without tier assignments, per-tier calibration has no substrate.
• SA-Infrastructure L2 (required): tier-conditional reference patterns define the "green path" for Critical and High-tier hardened architectures; EH-Infrastructure L2 enforces those patterns at the infrastructure layer.
• Supports / unblocks: ML-Infrastructure L2 (enhanced isolation and logging controls emit signals that ML L2 detections consume), IM-Infrastructure L2 (tier-calibrated incident response depends on tier-calibrated hardening for blast-radius containment).

Desired Outcomes

• Hardening depth is visibly differentiated: Critical-tier archetype components run in a more constrained, more observable envelope than Low-tier; the differentiation is verifiable from the component's configuration record in the SM inventory.
• Critical-tier archetype components use HSM-rooted encryption keys and dedicated VPC/VNet endpoints rather than shared cloud-provider defaults.
• JIT-only admin access is enforced for Critical-tier, no standing admin permissions on model registry, GPU fleet management, orchestrator control plane, or vector-store admin interfaces for Critical-tier.
• SLSA L3+ supply-chain provenance is enforced for all Critical-tier AI infrastructure build and model promotion pipelines.
• ML-Infrastructure L2 detection signals and IM-Infrastructure L2 incident patterns feed adaptive tightening proposals reviewed by the security platform engineering team.

Activities

A) Tier-conditional hardening calibration

Publish a hardening tier-treatment matrix aligned to SM-Infrastructure L2's risk tiers:

Each SM-Infrastructure archetype record carries its tier's hardening status; gaps between required and actual controls are open IM-Infrastructure findings.

B) Zero-trust AI infrastructure access for Critical-tier

• No standing admin access: for Critical-tier inference endpoints, model registry, GPU fleet management consoles, orchestrator control plane, and vector-store admin interfaces, no standing admin permissions; all access is just-in-time (≤4-hour sessions, approval-gated, scoped to the specific component and action); standing access of any kind is a blocking finding at the next IR-Infrastructure review.
• HSM-rooted keys for Critical-tier: 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); keys are not shared across archetype components or tenants.
• SLSA L3+ for Critical-tier: CI/CD pipelines for Critical-tier AI infrastructure components and model promotion workflows produce SLSA L3+ provenance attestations; build artifacts are hermetically sealed; the SLSA provenance attestation is verified by the deployment admission controller before any Critical-tier component is deployed.
• Dedicated VPC for Critical-tier: 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 paths; VPC flow logs are retained at full fidelity for the tier's longest applicable regulatory window.

C) Infrastructure-layer per-tenant isolation

• Critical-tier multi-tenant inference: inference endpoints and vector stores serving multiple tenants at Critical tier enforce tenant boundaries at the infrastructure layer, dedicated Kubernetes namespace per tenant with NetworkPolicy default-deny, or dedicated node pool per tenant, or separate inference cluster per tenant; application-layer routing without infrastructure-layer isolation is not sufficient for Critical-tier.
• Per-tenant CMK in vector store and model registry: 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.
• Isolation verification: per-tenant isolation is verified by the IR-Infrastructure implementation review (annual minimum for Critical-tier) and confirmed by a ST-Infrastructure isolation test wired into CI for Critical-tier multi-tenant components.

D) Adaptive tightening from ML-Infrastructure and IM-Infrastructure signals

• Wire ML-Infrastructure detection signals (shadow-inference-endpoint detection, GPU clearing failure, vector-store mass-extraction) and IM-Infrastructure incident patterns (post-incident hardening gaps) to a human-approved adaptive-tightening pipeline: signals generate tightening proposals; proposals are reviewed by the security platform engineering team before deploy; change log is machine-readable; downstream teams are notified within 24 hours.

Outcome Metrics (L2)

Process Metrics (leading)

• Tier-calibrated hardening gap audit, quarterly; per-component hardening-status deviations from the tier-treatment matrix are open IM-Infrastructure findings within 5 business days.
• JIT access log reviewed monthly; any access grant exceeding 4-hour time limit on Critical-tier components triggers an alert.
• SLSA provenance verification gap, any Critical-tier deployment without a SLSA L3+ provenance attestation is blocked and logged; gap count tracked weekly.
• Per-tenant isolation conformance test wired into CI for Critical-tier multi-tenant components (from SA-Infrastructure L2 IaC conformance test suite).

Effectiveness Metrics (business value)

• Reduced blast radius from compromised components, Critical-tier VPC isolation contains lateral movement; post-incident reviews show no cross-tier blast radius.
• Insider-risk signal quality, HSM-rooted key access logs and JIT access records provide actionable signals to the IM team that standing-access configurations did not produce.
• Supply-chain incident dwell time, SLSA L3+ provenance enables rapid identification of the build pipeline responsible for a compromised component; dwell time from component-compromise to root-cause trending down.

Success Criteria

• 100% of Critical-tier archetype components with dedicated VPC + HSM-rooted CMK + JIT-only 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; SM-Infrastructure inventory records show hardening status per tier; gaps are open IM-Infrastructure findings.

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

At this level, hardening is code. Every EH-Infrastructure control, workload-identity configuration, network policy, GPU node-pool configuration, supply-chain signing pipeline, SBOM generation, DLP rule set, per-tenant isolation module, JIT access policy, is expressed as a version-controlled IaC module in a module registry. Drift is detected continuously; low-risk drift is auto-remediated. Adaptive tightening fires when ML-Infrastructure detection trends or IM-Infrastructure incident patterns signal an emerging risk. Hardening baselines are contributed to CNCF, OpenSSF AI Infrastructure Working Group, and sector ISACs.

Dependencies

• EH-Infrastructure L2 (required): tier-calibrated hardening, HSM-rooted keys, SLSA L3+ supply-chain, and per-tenant isolation must be operational before automation and adaptive tightening are trustworthy.
• ML-Infrastructure L2+ (required): ML-Infrastructure detections (GPU clearing failures, vector-store mass-extraction patterns, shadow-endpoint emergence) are the upstream source for adaptive-policy tightening proposals.
• IM-Infrastructure L2+ (required): post-incident review patterns feed adaptive tightening and drive hardening-baseline updates.
• SM-Infrastructure L3 (alignment): automated inventory signals trigger auto-provisioning of hardening controls for new archetype components; tier-change signals trigger hardening-profile upgrades.

Desired Outcomes

• All EH-Infrastructure controls are reviewable as code; a security engineer can open the IaC module registry and understand exactly what hardening applies to any archetype component without reading a cloud console.
• Drift between deployed configuration and the IaC specification is detected within hours; low-risk drift is auto-remediated; high-risk drift triggers a human-review alert within 2 business days.
• Adaptive tightening is traceable: every policy change has a source signal (ML-Infrastructure detection trend ID or IM-Infrastructure incident ID), a human-approval record, and a downstream notification to affected teams.
• AI infrastructure hardening baselines published by this program are adopted by at least one CNCF or OpenSSF working group artifact or sector ISAC advisory.
• New AI infrastructure archetype components are automatically provisioned with their tier-appropriate hardening controls at SM-Infrastructure inventory registration, not retroactively after a DR or IM finding.

Activities

A) Hardening-as-code: IaC for all EH-Infrastructure controls

Express every EH-Infrastructure control as a version-controlled, forkable IaC module:

• Identity-envelope module: Terraform / Pulumi module for workload-identity binding per archetype (IRSA for AWS, Workload Identity for GCP, Managed Identity for Azure, Kubernetes service-account OIDC binding), JIT access policy configuration, SSO enforcement on AI-infra consoles, and audit-log pipeline wiring; parameterized by archetype and tier.
• Network-envelope module: VPC / VNet private-endpoint configuration, NetworkPolicy default-deny templates, service-mesh mTLS configuration (Istio PeerAuthentication / AuthorizationPolicy or Linkerd MeshTLSAuthentication), egress allow-list NetworkPolicy or SASE rule; parameterized by tier.
• Compute-envelope module: Kubernetes namespace isolation template (ResourceQuota, LimitRange, NetworkPolicy), GPU node-pool configuration with clearing-enforcement DaemonSet, classification-aware node-selector and taint/toleration definitions, cgroup quota enforcement; parameterized by archetype and classification tier.
• Supply-chain module: Sigstore / cosign signing pipeline component (GitHub Actions composite action or Tekton task), SBOM generation step (Syft or cdxgen), SLSA provenance generation step (slsa-github-generator or equivalent), 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 module: DLP policy configuration for AI-infra-specific exfiltration patterns, classification-aware NetworkEgress policy for each archetype workload identity; expressed as configuration-as-code for the CASB/DLP platform in use.

IaC modules version-pinned; 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; high-risk drift (workload identity replaced with static key, public endpoint opened on inference cluster, unsigned image deployed, GPU clearing DaemonSet removed) triggers a human-review alert within 2 business days and 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: GPU residual-state clearing failure trend → node-drain-and-clearing-audit proposal; vector-store mass-extraction pattern → retrieval-rate-limit tightening proposal and egress-policy narrowing proposal; shadow-inference-endpoint detection → egress-block proposal and SM-Infrastructure intake alert.
• IM-Infrastructure signals: post-incident review identifying a hardening gap (e.g., workload identity not enforced on a specific archetype, missing NetworkPolicy on a new namespace) → hardening-baseline update proposal; Critical-tier incident involving a compromised supply-chain component → SLSA-level upgrade proposal for the affected tier.
• Adaptive tightening pipeline: proposals are human-reviewed (security platform engineer approval) before deploy; change log is machine-readable; downstream archetype teams are notified within 24 hours of a tightening change that affects their component's hardening profile.
• Feedback loop to TA-Infrastructure and SR-Infrastructure: 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 potential new requirements.

C) Contribute hardening baselines to industry

• CNCF TAG Security / Security Technical Advisory Group, contribute Kubernetes workload-identity patterns for AI inference, GPU residual-state clearing reference implementation, and NetworkPolicy templates for AI-archetype isolation as CNCF reference artifacts.
• OpenSSF AI Infrastructure Working Group, contribute signed-artifact pipeline templates (cosign + SLSA provenance + admission-controller policy) for model registry and AI CI/CD as OpenSSF reference modules.
• Sector ISACs (FS-ISAC, H-ISAC, IT-ISAC AI working groups), contribute sector-relevant AI infrastructure hardening advisories covering inference-endpoint access control, model-registry supply-chain controls, and GPU residual-state management.
• Target: ≥2 substantive contributions per year; maintained upstream; internal practice aligns with the published external version.
• Auto-provisioning trigger: when a new AI infrastructure archetype component is registered in SM-Infrastructure, the IaC automation provisions its tier-appropriate hardening profile within 24 hours, no manual hardening backlog.

Outcome Metrics (L3)

Process Metrics (leading)

• IaC coverage growth rate, % of EH-Infrastructure controls migrated to IaC month-over-month; target ≥90% before the quarter closes.
• Adaptive-policy pipeline freshness, ML-Infrastructure and IM-Infrastructure signal feeds checked weekly; stale feeds (>7 days without a processed event) flagged.
• Industry contribution pipeline, ≥1 hardening artifact (CNCF reference, OpenSSF module, ISAC advisory) in-flight at any time.
• Drift queue, open high-risk drift findings triaged and human-reviewed within 2 business days; low-risk resolved within 5 business days.

Effectiveness Metrics (business value)

• Reviewer-hours per hardening configuration change drop quarter-over-quarter as IaC and adaptive-policy automation absorb manual review cycles.
• External recognition, CNCF or OpenSSF adoption of contributed AI infrastructure hardening modules; citations in sector ISAC publications.
• Time-to-hardened for new AI infrastructure components decreases from "days after DR finding" to "hours after SM registration" as auto-provisioning operates.
• Incident rate on IaC-encoded deployments lower than on hand-configured deployments, tracked as a rolling 12-month comparison.

Success Criteria

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

Key Success Indicators

Level 1: - 100% of AI infrastructure archetype components running under workload identity (no long-lived service-account keys); confirmed by IAM audit × SM-Infrastructure inventory reconciliation. - SSO + MFA enforced on all AI infrastructure consoles (model registry, vector-store, orchestrator, cloud ML); every console action logged to append-only audit log. - GPU residual-state clearing enforced and logged on 100% of GPU/accelerator nodes; no clearing failures outstanding; any clearing failure drains the node within 4 hours. - 100% of Critical/High-tier AI infrastructure container images signed and SBOM-tracked; unsigned images rejected at deployment gate; DLP rules for AI-infra-specific exfiltration deployed and active.

Level 2: - 100% of Critical-tier archetype components with dedicated VPC + HSM-rooted CMK + JIT-only human admin (no standing access); SLSA L3+ provenance 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; SM-Infrastructure inventory records show hardening status per tier; gaps are open IM-Infrastructure findings; adaptive-tightening pipeline operational from ML and IM signals.

Level 3: - ≥90% of EH-Infrastructure controls expressed as 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; change log machine-readable and traceable. - New AI infrastructure components auto-provisioned with tier-appropriate hardening within 24 hours of SM-Infrastructure registration. - ≥2 industry hardening baseline contributions per year (CNCF, OpenSSF AI, sector ISACs) with documented adoption.

Common Pitfalls

Level 1: - ❌ Workload identity configured for inference endpoints but not for the AI CI/CD pipeline runner, the pipeline runner that promotes model artifacts to the registry uses a long-lived service-account key stored as a CI/CD secret; supply-chain compromise of the runner gives persistent model-registry write access. - ❌ GPU residual-state clearing documented in the node configuration spec but the clearing DaemonSet is not deployed, clearing runs only on OS reboot; tenant A's inference job leaves tensor residuals on the node that tenant B's job reads at the start of the next session. - ❌ Model registry requires SSO on the web console but the registry API endpoint accepts static token authentication, attackers who obtain a token via the vector-store bypass SSO entirely; the SSO enforcement is a UI control, not a policy control. - ❌ Container images are signed but the admission controller that verifies signatures is deployed in warn mode rather than enforce mode, unsigned images deploy to production while the controller logs a warning that nobody reads until an incident surfaces the gap. - ❌ 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 DLP engine does not recognize high-dimensional float arrays or checkpoint file extensions as exfiltration signals. - ❌ Per-tenant network segmentation declared in the architecture but only the default Kubernetes namespace is used for all tenants, a NetworkPolicy on the application layer filters traffic by label selector, but tenant A's pod can still reach tenant B's pod directly because both share the same namespace; the infrastructure-layer isolation does not exist.

Level 2: - ❌ HSM-rooted keys provisioned for Critical-tier model registry but the GPU fleet's job-output storage still uses the platform default key, an attacker who compromises the GPU fleet's storage gets access to fine-tuned model checkpoints whose inference-endpoint counterpart is under HSM protection; the key-separation benefit is incomplete. - ❌ SLSA L3+ 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; the SLSA L3 claim is inaccurate and fails attestation verification. - ❌ JIT access policy 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; the JIT policy exists in the hardening matrix but not in the IAM configuration. - ❌ Tier-hardening matrix exists but 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, the cluster continues to operate with Medium-tier controls because the provisioning automation does not re-run on tier change. - ❌ Per-tenant isolation verified by IR review but the ST isolation test is not wired into CI, isolation regressions introduced by a Kubernetes upgrade or a NetworkPolicy refactor are not caught until the next annual IR review.

Level 3: - ❌ IaC coverage declared at ≥90% but the registry counts modules that have an IaC stub rather than modules whose IaC is the authoritative deployed source, live GPU node-pool configuration was hand-patched after a CUDA version emergency and diverged from the IaC; the drift-detection pipeline fires on the stub's expected state; auto-remediation reverts the CUDA patch. - ❌ Adaptive-policy pipeline wired to ML-Infrastructure detections but not to IM-Infrastructure incidents, post-breach hardening opportunities identified in IR post-incident reviews (e.g., missing NetworkPolicy on a new inference namespace introduced during a scale-out) are never converted to tightening proposals. - ❌ Industry hardening baselines contributed to CNCF but not maintained upstream, internal practice advances (new GPU clearing DaemonSet for next-generation accelerators) while the CNCF reference artifact reflects the previous-generation implementation; external adopters file issues against stale guidance. - ❌ Auto-provisioning trigger fires for new SM-Infrastructure registrations but reads a stale tier field, a Critical-tier inference cluster registered with a temporary Medium-tier designation during intake receives Medium-tier hardening; the tier is corrected in SM-Infrastructure 24 hours later but the hardening-profile upgrade does not trigger because the provisioning 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, 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? 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? 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?

Level 2: 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, confirmed by IAM audit and IR-Infrastructure review? 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? 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?

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 visible to infrastructure and security teams, and high-risk drift human-reviewed within 2 business days? 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? 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?

Document Version: HAIAMM v3.0, 2026-05-14, Verifhai Practice: Environment Hardening (EH) Domain: Infrastructure Last Updated: 2026-05-14 Author: Verifhai