Security Requirements (SR)

Infrastructure Domain - HAIAMM v3.0

Practice Overview

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

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

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

Maturity Level 1

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

At this level, the organization stops re-deriving requirements per infrastructure review and starts selecting, adapting, and evidencing from a shared pack that every downstream practice inherits.

Dependencies

• TA-Infrastructure L1 (required): requirements derive from the archetype threat library, without the threat library the pack is arbitrary rather than threat-driven.
• PC-Infrastructure L1 (required): requirements inherit policy guardrails and the priority compliance map (EU AI Act Art. 26/9, GDPR Art. 32, ISO/IEC 42001, SOC 2 CC9.2).
• SM-Infrastructure L1 (required): the SM inventory scope and archetype taxonomy define which assets the pack applies to and which archetype deltas are relevant.
• Supports / unblocks: SA-Infrastructure L1 (reference patterns implement the requirements), DR-Infrastructure L1 (design reviews check proposed designs against the pack), IR-Infrastructure L1 (implementation reviews verify REM evidence is accurate), ST-Infrastructure L1 (security tests target the requirements), IM-Infrastructure L1 (findings route to the REM gap register).

Desired Outcomes

• A single AI/HAI Infrastructure Requirements Pack exists; platform engineers, MLOps teams, and security reviewers select from it rather than drafting from scratch at each intake.
• Every AI/HAI infrastructure asset approved for use carries a REM showing which pack requirements are met (by what evidence), which gaps are accepted (with a named owner and expiry date), and which compensating controls are in place.
• EU AI Act Art. 26 deployer duties and ISO/IEC 42001 AIMS controls are traceable to specific infrastructure pack requirements, not hand-waved in narrative.
• A Software-domain artifact's REM links to the Infrastructure REM of the hosting cluster for the base infrastructure categories (identity, isolation, encryption, observability, patch hygiene) rather than re-stating them.
• The pack is versioned, owned, and refreshed quarterly as threats (TA) and compliance expectations (PC) evolve.

Activities

A) Author the base AI/HAI Infrastructure Requirements Pack

The base pack applies to every AI/HAI infrastructure asset the org operates to host or serve AI systems, regardless of archetype. Keep it short (target ≤20 base requirements at L1). Each requirement has: an ID, a statement, a rationale (threat tag from TA-Infrastructure + compliance tag from PC-Infrastructure), an evidence source, a test method, and an acceptance criterion.

Minimum base categories:

• Identity and authentication: workload-identity-only access for all service principals that interact with AI infrastructure (no long-lived access keys on service accounts, instance profiles, or managed identities that reach AI-serving assets); JIT (just-in-time) elevation for human administrator access, no standing administrative access to inference endpoints, model registries, GPU schedulers, or orchestrator control planes; MFA enforced for all human console access to AI infrastructure accounts or projects; service-to-service authentication via workload identity federation (IRSA, GCP Workload Identity, Azure Managed Identity), no shared-credential patterns.
• Isolation: per-tenant network isolation for multi-tenant AI infrastructure (one tenant's inference context, training data, and model weights not reachable from another tenant's workload); per-workload namespace isolation in Kubernetes-hosted AI workloads (inference, training, and orchestration in separate namespaces with network policies); per-classification-tier isolation, Critical-tier workloads (workloads classified Critical per SM-Infrastructure L2) run on dedicated nodes, not on shared compute; all isolation controls verified through documented conformance checks, not assumed from IaC declarations.
• Encryption: encryption at rest with cloud KMS for all AI artifact stores (model registry buckets, vector-store backing storage, feature-store tables, training-data staging zones); encryption in transit with mTLS or TLS 1.2+ for all service-to-service communication within the AI infrastructure; key separation per tenant (separate KMS keys for each tenant's model artifacts and training data in multi-tenant deployments); key rotation schedule documented and enforced.
• Region and data-residency enforcement: region pinning for all AI infrastructure assets that handle personal data or operate under regulatory jurisdiction (workloads cannot silently migrate to out-of-region nodes or to cloud regions outside the defined jurisdiction boundary); cross-region data-transfer gates, data containing personal data or classified as High/Critical cannot leave the declared region boundary without a documented transfer mechanism and approval.
• Observability: AI infrastructure logs (inference-endpoint request/response metadata, model-registry access, GPU-scheduler job logs, orchestrator pipeline execution logs, feature-store access logs, CI/CD build and promotion logs) forwarded to the SIEM and retained to meet the longest applicable regulation; admin-audit logs (console actions, API calls to AI service management planes) captured and retained; identity events (authentication, authorization, role assumptions) captured; metrics (latency, throughput, error rates, GPU utilization) collected and baselined; traces available for distributed AI pipeline debugging.
• Patch and image hygiene: signed container images and model artifacts for all AI infrastructure workloads, unsigned images or artifacts are rejected by the admission controller or deploy hook; base-image policy enforced (approved base images only; CUDA, PyTorch, vLLM, and other ML framework images from the approved internal registry mirror); vulnerability SLA per severity: Critical CVE remediation within 14 days of publish; High within 30 days; Medium within 90 days; no exceptions without a documented compensating control and named owner.
• Quotas, rate limits, and abuse detection: inference endpoints protected by per-consumer rate limits (throttle before serving-cluster saturation); per-tenant resource quotas on GPU/TPU scheduling (no single tenant can consume the full fleet); abuse-detection layer on inference endpoints (anomalous query volume, query patterns consistent with model-extraction probes, prompt-flood signatures); alerts routed to IM-Infrastructure with defined triage SLA.
• Backup, recovery, and RTO/RPO: model registry contents backed up with a recovery objective appropriate to the workload tier (Critical: RTO ≤4 hours, RPO ≤1 hour; High: RTO ≤24 hours, RPO ≤4 hours); vector-store index recoverable to a known-good snapshot within the RTO; backup integrity tested at documented cadence (minimum quarterly); recovery procedures documented and tested.
• Failure-mode design: degraded-mode operation documented for inference-endpoint provider outage, model-registry unavailability, and GPU-fleet capacity exhaustion, no silent failure that produces misleading output or unrecorded inaction; kill-switch or circuit-breaker mechanism at the inference-endpoint and orchestrator layers (tested at least quarterly); fallback model or graceful degradation path defined for Critical-tier workloads.
• Disclosure: where the infrastructure hosts customer-facing AI/HAI features subject to EU AI Act Art. 50 transparency obligations, the infrastructure's logging and metadata capabilities must support the deployer-duty evidence trail required by Art. 26; this requirement links to the Software-domain REM for the artifact hosted on this infrastructure.

Every base requirement is tagged to: at least one TA-Infrastructure archetype threat and at least one item from the PC-Infrastructure priority compliance map.

B) Author per-archetype requirement deltas

On top of the base pack, each archetype carries a short delta (typically 3–8 additional requirements) reflecting the threat-specific obligations from TA-Infrastructure's archetype threat models.

Deltas to ship at L1:

• Inference endpoint / model-serving cluster: per-consumer authentication for all inference requests, no unauthenticated inference endpoints; per-tenant authentication (each consumer presents a token scoped to their tenant before receiving inference output); rate-limit and abuse-detection requirements: per-consumer quota defined and enforced at the serving layer; model-version pinning: a caller cannot be silently moved to a different model version or model family without passing the eval gate; request/response metadata logging with PII redaction (full prompt and completion text are not logged unless a documented lawful basis covers that data class, metadata only by default); region-pinned serving for workloads under jurisdictional data-residency requirements; signed model artifacts only, inference endpoint rejects any model artifact that lacks a verified signature from the approved signing key.
• Model registry: workload-identity-only writes, no long-lived API key or personal credential can push a model artifact; write access restricted to a named write-list of approved principals (CI/CD service accounts that have passed the eval gate); signed model artifacts: every artifact pushed to the registry is signed at push time; lineage tracked back to the training job that produced the artifact (training-job ID, dataset version, eval-gate result, signing key identifier); access control by classification, model artifacts classified as Critical or High require a review approval record in the promotion log before they can be promoted to a production-facing registry path; immutable promotion log: once a model artifact is promoted to production, the promotion record is append-only and cannot be modified or deleted.
• GPU / accelerator fleet: workload-namespace isolation: training, fine-tuning, and inference jobs from different tenants run in separate Kubernetes namespaces with network policies preventing lateral movement; GPU residual-state clearing between jobs: a documented and verified clearing mechanism runs between every job on shared GPU hardware; for Critical-tier workloads: dedicated nodes, no shared GPUs for workloads classified Critical under SM-Infrastructure L2 (this is a binary requirement, not a best-effort recommendation); scheduler-side data-classification awareness: the job scheduler enforces node affinity rules so that jobs with a Critical or High data classification cannot be co-located with lower-classification jobs on the same node; egress allow-list on all training and inference namespaces.
• Orchestrator / control plane: signed workflow definitions: pipeline and workflow definitions are signed at merge time; the orchestrator verifies signatures before executing any workflow step; workflow-step authentication: each step of a pipeline executes under a step-specific principal (not a single ambient orchestrator credential); per-step principal: the orchestrator enforces that no step can acquire permissions beyond those pre-declared for that step; agent-state confidentiality: the orchestrator's state backend (used to persist agent memory, tool-call history, and goal state) is encrypted at rest with a tenant-specific key; control-plane API authenticated, rate-limited, and audited: all management API calls are logged to the SIEM.
• Vector-store infrastructure: per-tenant index partitioning: tenant A's embedded chunks are stored in a namespace physically or logically separate from tenant B's; classification-labeled per chunk: every indexed chunk carries a classification label; retrieval API enforces classification-based access control; access control by principal: the embedding query interface requires authentication, no anonymous or unauthenticated retrieval; query-pattern observability: retrieval query logs are collected and baselined; anomalous retrieval patterns (high-volume extraction behavior, queries consistent with corpus enumeration) generate alerts routed to IM-Infrastructure.
• AI-specific CI/CD: signed pipeline definitions: CI/CD pipeline configurations are stored in version control and signed at merge; SLSA-style provenance for model and dataset artifacts: every model artifact produced by the CI/CD pipeline carries a signed provenance attestation (training-job ID, dataset version, build environment hash, signing key); eval gate as a required check: no model artifact can be promoted to the production registry without a passing eval-gate result on file; promotion-policy enforced: the promotion workflow enforces that required approvals (eval gate, named reviewer sign-off for Critical-tier) are present before the artifact is promoted; secrets vault for all credentials used in pipeline steps, no API keys, registry credentials, or cloud credentials in pipeline configuration files or environment variables.
• Feature store / online serving cache: offline/online skew monitoring: a documented monitoring mechanism detects and alerts when the feature distribution served at inference time diverges from the distribution used at training time; access control: the feature query API requires authentication; feature reads are scoped to the minimum feature set required for the stated model use case; feature-lineage tracking: every feature in the store has a documented source pipeline, last-updated timestamp, and classification label; rollback on poisoning: a rollback procedure exists to restore the feature store to a known-good snapshot if feature-poisoning is detected; the procedure is documented and tested at minimum annually.

C) Wire the pack into the SM intake gate and establish cross-domain REM linkage

Every infrastructure asset approved for use carries a REM. Structure: - Each applicable pack requirement (base + archetype delta) marked: Met / Met-with-compensating-control / Gap-accepted / Not-applicable (with justification for N/A). - Each Met row cites specific evidence: IaC configuration reference, admission-controller policy, secrets-scanner CI result, GPU isolation conformance test result, SIEM log forwarding confirmation, backup test record, kill-switch test result, or signed-image attestation. - Each Gap-accepted row names a compensating control, a named owner, a re-review date (maximum 90 days at L1), and the residual-risk rationale accepted by the named sponsor. - REM is stored with the SM inventory record for the infrastructure asset and linked from the intake ticket.

Cross-domain REM linkage: when a Software-domain artifact's REM is authored, the Software REM references the Infrastructure REM of the hosting cluster for base infrastructure categories (identity, isolation, encryption, observability, patch hygiene) rather than re-auditing those controls independently. The link is: Software artifact REM row references Infrastructure asset REM row, which references the evidence artifact. This eliminates redundant evidence collection and ensures Software and Infrastructure reviews are anchored to the same ground truth.

Material changes (new tenant onboarded, network topology change, platform major version upgrade, workload-tier reclassification) trigger REM re-review before the change takes effect.

Outcome Metrics (L1)

Process Metrics (leading)

• Pack review cadence, quarterly refresh recorded; changes change-logged.
• REM turnaround, median ≤3 business days from threat snapshot (TA) to REM completion.
• Reviewer consistency, calibration on sample REMs produces ≤2 row-level diffs across independent reviewers.
• Material-change trigger rate, % of platform changes that trigger a REM re-review vs. changes that ship without triggering one.

Effectiveness Metrics (business value)

• Requirements reused vs. invented, ≥80% of REM rows reference the pack unchanged; zero rows invented per-intake from scratch.
• Audit readiness, EU AI Act Art. 26 deployer-duty inquiries answered via Infrastructure and Software cross-linked REMs without re-collection.
• Downstream reuse, SA, DR, IR, ST artifacts cite REM rows directly rather than re-deriving requirements independently.

Success Criteria

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

Maturity Level 2

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

At this level, every requirement in the pack is either measurable (with a specific SLA) or binary (with an explicit evidence condition). REM rows are validated against observed reality for Critical/High-tier assets. Accepted-gap aging is managed per tier. The IR-Infrastructure feedback loop ensures that implementation review findings update the REM pack.

Dependencies

• SR-Infrastructure L1 (required): base pack, archetype deltas, and REM template must be established before quantitative refinement is meaningful.
• SM-Infrastructure L2 (required): the risk-tier rubric (Critical / High / Medium / Low, based on workload tier hosted, multi-tenancy isolation, customer-exposure, compute scale/concentration, data classification, decision-affecting use, geographic scope) determines which assets receive full per-tier treatment.
• TA-Infrastructure L2 (required): per-asset deep threat models inform per-asset requirement adjustments for Critical-tier assets.
• Supports / unblocks: SA-Infrastructure L2, DR-Infrastructure L2, IR-Infrastructure L2 (each inherits the quantitative per-tier pack), ST-Infrastructure L2 (tests validate pack SLAs directly).

Desired Outcomes

• Every requirement in the pack carries a specific, testable condition, a concrete SLA in hours, days, or percentage, or a binary evidence condition, with all qualitative language removed.
• REM rows for Critical and High-tier assets are re-validated against observed reality at least quarterly (Critical) and semi-annually (High).
• Accepted-gap backlog aging managed per tier: no Critical-tier gap stays open beyond 60 days without documented escalation.
• Per-tier pack differentiation is visible and enforced.
• IR-Infrastructure findings feed REM auto-revalidation, a finding in IR triggers a REM row re-review for the affected requirement within 5 business days.

Activities

A) Quantitative and binary requirement pack

For every requirement in the base pack and each archetype delta, replace qualitative language with measurable or binary conditions:

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

B) Per-tier requirement depth

Publish a per-tier pack overlay aligned to the SM-Infrastructure L2 tier-treatment matrix:

• Critical tier: full base pack + all applicable archetype deltas; dedicated-node isolation required (binary, enforced by scheduler policy); executive sign-off required (named sponsor sign-off on the completed REM before Sanctioned status is issued); accepted-gap aging SLA of 60 days maximum before mandatory escalation; EU AI Act Art. 26 deployer-duty checklist as a discrete appendix to the REM; re-validation of all Critical-tier REM evidence quarterly; IR-Infrastructure auto-revalidation cadence: every IR finding for a Critical-tier asset triggers a full REM re-validation run within 5 business days.
• High tier: full base pack + applicable archetype deltas; REM required; accepted-gap aging SLA of 90 days; re-validation of REM evidence semi-annually; IR findings trigger targeted REM row re-validation.
• Medium tier: base pack + applicable archetype deltas; REM required; accepted-gap aging SLA of 120 days; re-validation annually.
• Low tier: base pack only; REM required; fast-track process (abbreviated evidence citations acceptable); re-validation at annual review.

C) REM auto-revalidation cadence and IR feedback loop

Critical-tier REMs re-validated quarterly; High-tier semi-annually. Validation method: select a stratified sample of REM rows per asset (at least one row per base category), verify each cited evidence artifact against current observable reality: - Workload-identity enforcement: re-run IAM audit; confirm zero long-lived keys. - GPU residual-state clearing: re-run conformance test; confirm clearing mechanism operational. - Signed-image enforcement: query the admission controller; confirm zero unsigned-image exceptions. - SIEM log completeness: query log-completeness metric; confirm ≥99% forwarding SLA met. - Kill-switch: re-run test; confirm ≤5-minute halt.

Validation deltas routed to IM-Infrastructure as findings with severity tags and remediation SLAs matching the asset's tier.

IR-Infrastructure feedback loop: every IR finding for a requirement covered by the pack generates a REM row re-review flag; the finding is not closed until the REM row reflects the current state (Met, Gap-accepted, or Compensating control documented).

Outcome Metrics (L2)

Process Metrics (leading)

• Pack change-log, ≥1 substantive update per quarter reflecting new TA threats or PC compliance updates.
• REM validation sampling calendar, no missed quarters for Critical; no missed semi-annual cycle for High.
• Accepted-gap escalation SLA met, no gap hits escalation threshold without prior notification to the named owner.
• IR-to-REM feedback loop active, % of IR findings linked to a REM row re-review (expected: rising as the loop matures).

Effectiveness Metrics (business value)

• Time-to-regulator-inquiry drops as Infrastructure and Software cross-linked REM evidence is pre-assembled.
• Audit pass rate on AI infrastructure controls, external auditors (SOC 2, ISO 42001) find cross-linked REM evidence sufficient without supplemental interviews.
• Incident rate on REM-validated assets lower than on assets without current REM.

Success Criteria

• 100% of pack requirements carry a quantitative or binary evidence condition; all qualitative language removed.
• ≥95% of Critical-tier REMs re-validated against observed reality in the last 90 days.
• Accepted-gap backlog inside aging targets per tier; no Critical-tier gap past 60 days without documented escalation.
• 100% of Critical-tier assets carry full EU AI Act Art. 26 deployer-duty checklist evidence in their REM.
• IR-Infrastructure feedback loop operational; ≥90% of IR findings trigger a REM row re-review within 5 business days.

Maturity Level 3

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

At this level, the requirements pack and REM become machine-processable. IaC deployments attest that an infrastructure asset satisfies its REM at deploy time, a deploy that fails a Critical-tier REM requirement is blocked at the pipeline gate. The pack is published as a referenceable artifact adopted by CNCF AI working groups, OpenSSF AI, and the NIST AI RMF Playbook reference pack ecosystem. Machine-readable Infrastructure REM attestations are consumable by Software-domain CI/CD gates.

Dependencies

• SR-Infrastructure L2 (required): quantitative pack and continuous validation must be mature before automation is trustworthy.
• PC-Infrastructure L3 (required): compliance-evidence automation substrate is the substrate that SR L3 IaC gates consume.
• ML-Infrastructure L2+ (required): runtime signals (log completeness, kill-switch test results, GPU isolation conformance) are evidence sources that REM auto-validation reads.

Desired Outcomes

• An IaC deployment to production fails if a Critical-tier REM requirement is unmet, compliance is enforced at deploy time, not audited afterward.
• REM evidence is largely auto-validated; human review goes to novel clauses, edge-case N/A justifications, and accepted-gap escalations.
• The pack is referenced and adopted outside the organization, CNCF AI, OpenSSF AI, and standards bodies cite or adopt the schema.
• Infrastructure REM attestations are consumed by Software-domain CI/CD gates, creating a verified dependency chain from software artifact to hosting infrastructure.

Activities

A) Machine-readable pack and IaC attestation at deploy

Express the Requirements Pack (base + archetype deltas) in a structured schema (JSON or YAML) where each requirement has: an ID, a machine-readable evidence type (iac-config-check / log-query / test-result-reference / runtime-signal / manual-attestation), an acceptance predicate, and a tier applicability field.

At IaC deploy time for Critical and High-tier assets: - Automated checks run against the asset's REM: workload-identity-only access confirmed via IAM audit; signed-image policy confirmed via admission-controller configuration; SIEM forwarding confirmed via log-completeness signal; GPU isolation confirmed via scheduler-policy configuration; kill-switch mechanism confirmed via test result within defined age. - Checks that pass write a signed attestation to the REM record. - Checks that fail block the deploy for Critical-tier assets; emit a warning and auto-route a finding to IM-Infrastructure for High-tier. - Infrastructure REM attestations are published as machine-readable artifacts that Software-domain CI/CD pipelines can reference, a software artifact's CI/CD gate can verify that its hosting cluster's Infrastructure REM is currently passing before the software deploy proceeds.

B) Automated REM-evidence validation from runtime signals

Subscribe the REM validation pipeline to: - ML-Infrastructure monitoring, log-completeness signal, GPU isolation conformance signal, rate-limit enforcement signal. - IM-Infrastructure incident records, post-incident reviews that touch a pack requirement trigger auto-flagging of the relevant REM rows. - SM inventory change events, a tier upgrade auto-triggers a full REM re-validation run under the new tier's requirements depth.

Human review reserved for: novel requirement types not yet in the structured schema; accepted-gap escalations; asset-specific clauses outside the standard archetype deltas.

C) Standards contribution

Contribute to: - CNCF AI working groups, machine-readable infrastructure requirement schema for AI workload security; Kubernetes AI workload isolation requirements; GPU namespace isolation best practices. - OpenSSF AI, supply-chain security requirements for AI CI/CD pipelines; SLSA-compatible provenance requirements for model artifacts; signed-artifact policy for ML registries. - NIST AI RMF Playbook reference packs, submit practitioner commentary on MEASURE and MANAGE function infrastructure requirement language grounded in REM experience. - ISO/IEC 27090 / AI security standards successor work, submit concrete, testable AI infrastructure security requirements as candidate clause language.

Target: minimum 2 substantive contributions per year; legally vetted and anonymized.

Outcome Metrics (L3)

Process Metrics (leading)

• Structured-schema coverage, % of requirements expressed in machine-readable form (target: growing toward 100% of Critical/High-tier requirements).
• Automation error-rate monitored, false-positive and false-negative gate failures tracked.
• Contribution pipeline ≥2 in-flight at any given time.
• Pack published version freshness, public version aligned with internal version (no version lag exceeding one quarter).

Effectiveness Metrics (business value)

• Reduced time-to-production for compliant infrastructure assets, the IaC gate replaces manual REM review cycles.
• Zero Critical-tier infrastructure deployments with unmet REM requirements reaching production.
• Software-domain deploys inherit verified infrastructure compliance via the cross-domain attestation chain.
• Industry recognition as a contributor to AI infrastructure security requirements standards.

Success Criteria

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

Key Success Indicators

Level 1: - AI/HAI Infrastructure Requirements Pack published: base set (≤20 requirements) plus seven per-archetype deltas (inference endpoint, model registry, GPU/accelerator fleet, orchestrator/control plane, vector-store infra, AI-specific CI/CD, feature store), every requirement tagged to a TA-Infrastructure archetype threat and a PC-Infrastructure priority compliance item. - 100% of new AI/HAI infrastructure assets approved in the last 90 days have a completed REM on file, every applicable requirement marked Met / Met-with-compensating-control / Gap-accepted / Not-applicable, each Met row citing specific evidence, each Gap-accepted row naming a compensating control, owner, and re-review date. - ≥90% of active AI/HAI infrastructure assets in the SM inventory carry a current-year REM; accepted-gap backlog median age inside ≤90 days. - Cross-domain REM linkage operational: Software-domain REMs reference the Infrastructure REM of their hosting cluster for base infrastructure categories. - Named pack owner and quarterly refresh cadence operating.

Level 2: - 100% of pack requirements carry a quantitative or binary evidence condition; all qualitative language removed. - ≥95% of Critical-tier REMs re-validated against observed reality (IAM audit, GPU isolation conformance test, signed-image admission-controller query, SIEM completeness metric, kill-switch test) in the last 90 days. - No Critical-tier accepted gap open beyond 60 days without documented escalation; no High-tier gap beyond 90 days. - IR-Infrastructure feedback loop operational; ≥90% of IR findings trigger a REM row re-review within 5 business days.

Level 3: - Machine-readable Requirements Pack and REM schema published under permissive license with tracked adoption; ≥80% of Critical-tier requirements have IaC attestation at deploy time. - ≥70% of REM evidence rows auto-validated via IaC, runtime monitoring, and SIEM signal. - Zero Critical-tier assets deploying to production with a failing REM check; ≥70% of Critical/High Software CI/CD gates referencing Infrastructure REM attestation. - ≥2 substantive standards contributions per year.

Common Pitfalls

Level 1: - ❌ The base pack is authored with 40+ requirements at L1, reviewers cannot complete a REM in ≤3 business days; rows are skipped, producing REMs that are structurally complete but evidentially hollow. - ❌ GPU residual-state clearing is in the GPU-fleet delta on paper but the evidence source is "team asserts it's configured", no conformance test, no test date, no test result; the control is nominal. - ❌ Cross-domain REM linkage is discussed in documentation but never wired, Software REMs re-audit all infrastructure categories independently; duplicate reviews consume reviewer bandwidth and produce inconsistent findings. - ❌ Pack requirements are tagged to compliance frameworks on paper but never tested at evidence-review time, REM rows reference "EU AI Act Art. 26" but cite no actual IaC configuration or conformance test result; the traceability is nominal. - ❌ Material-change trigger is not defined, new tenants onboarded, platform major version upgrades, and workload-tier reclassifications ship without triggering a REM re-review; the REM drifts from the actual asset configuration within weeks. - ❌ Downstream practices (SA, DR, IR, ST) ignore the REM and re-derive requirements independently, the pack exists but provides zero actual reuse.

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

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

Practice Maturity Questions

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

Level 2: 1. Do 100% of pack requirements carry a quantitative or binary evidence condition, with every SLA (vulnerability remediation days, GPU clearing conformance test cadence, SIEM completeness percentage, kill-switch response time, RTO/RPO) and binary state (workload-identity-only access confirmed, signed artifacts enforced, dedicated nodes for Critical tier confirmed, rate limits verified) specified, and has all qualitative language been removed? 2. Are ≥95% of Critical-tier REMs re-validated against observed reality (IAM audit, GPU isolation conformance test, signed-image admission-controller query, SIEM completeness metric, kill-switch test) in the last 90 days, with validation deltas routed to IM-Infrastructure and no Critical-tier accepted gap aging beyond 60 days without documented escalation? 3. Is the IR-Infrastructure feedback loop operational, with ≥90% of IR findings for requirements covered by the pack triggering a REM row re-review within 5 business days, and the finding not closed until the REM row reflects the current state?

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

Document Version: HAIAMM v3.0 Practice: Security Requirements (SR) Domain: Infrastructure Last Updated: 2026-05-14 Author: Verifhai