Secure Architecture (SA)

Infrastructure Domain - HAIAMM v3.0

Practice Overview

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

Description: SA-Infrastructure ships a catalog of reference patterns, one per AI/HAI infrastructure archetype, showing how to establish identity, isolate tenants, encrypt data at rest and in transit, log activity, enforce region pinning, sign artifacts, and implement kill-switch and fallback mechanisms for infrastructure that hosts AI systems. Each pattern covers scope, identity and auth model, traffic path and isolation controls, logging specification, controls mapped to SR-Infrastructure requirements, and threats mitigated (tagged to HAI TTPs and MITRE ATLAS). The catalog is accompanied by an anti-pattern list derived from real incidents. Teams use the reference pattern as the starting point; deviations require design review. At L2, patterns are encoded as IaC modules (Terraform / Pulumi / Helm) with per-tier conditional controls. At L3, patterns are published as open artifacts adopted by CNCF AI working groups, OpenSSF AI, and contributed to the MITRE ATLAS mitigation library.

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

Maturity Level 1

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

At this level, architecture becomes prescriptive rather than advisory for AI infrastructure assets. Reference patterns are named, versioned, and the first thing a platform team reaches for when provisioning an inference endpoint, a model registry, a GPU fleet, an orchestrator, a vector store, an AI CI/CD pipeline, or a feature store. The anti-pattern catalog names the mistakes that reliably produce incidents.

Dependencies

• SR-Infrastructure L1 (required): patterns implement the base + archetype requirement packs; without the pack, pattern controls are stylistic choices rather than requirement-backed decisions.
• TA-Infrastructure L1 (required): threat library drives which controls appear in each pattern and which threats each pattern claims to mitigate.
• PC-Infrastructure L1 (required): patterns operationalize AI Acceptable Use and Infrastructure Policy constraints.
• SM-Infrastructure L1 (required): inventory shows which archetypes the org actually operates; patterns are authored for that archetype list.
• Supports / unblocks: DR-Infrastructure L1 (design reviews use the pattern as the baseline), IR-Infrastructure L1 (implementation reviews check pattern adherence), EH-Infrastructure L1 (hardening targets the pattern's surface areas), ST-Infrastructure L1 (security tests target the pattern's controls).

Desired Outcomes

• Every team provisioning an AI/HAI infrastructure asset finds a documented reference pattern within one click of the SM inventory record.
• Each pattern is concrete enough to implement: labeled architecture diagram, isolation model, identity and auth spec, logging points, controls with SR traceability, and named threats mitigated.
• Known anti-patterns, the architectural mistakes that have produced real incidents, are named, explained, and linked to the reference pattern that replaces them.
• Deviations from reference patterns are visible and reviewed, not accidental or silent.
• Architecture decisions carry explicit traceability to SR-Infrastructure requirements and TA-Infrastructure threats.

Activities

A) Publish reference architectures per AI/HAI infrastructure archetype

Publish one pattern per archetype the org actually operates. Each pattern is concise (≤3 pages), includes a labeled architecture diagram, and covers the same structural elements so teams know what to expect.

Pattern skeleton (every archetype): - Scope, what the pattern covers and what it explicitly does not. - Identity and auth model, workload identity for service principals; JIT elevation for human admin access; no long-lived keys; per-tenant token scoping. - Isolation model, per-tenant network isolation; per-workload namespace isolation; per-classification-tier node isolation for Critical workloads. - Traffic path, ingress and egress controls; allowlisted destinations; API-gateway or load-balancer placement; mTLS or TLS 1.2+ enforcement. - Logging specification, what events are logged; retention period; SIEM forwarding; exportability for regulatory requests. - Controls mapped to SR-Infrastructure requirements, explicit row-by-row mapping; gaps acknowledged. - Threats mitigated, which TA-Infrastructure archetype threats the pattern addresses, which remain residual; HAI TTP tags (EA / AGH / TM / RA); MITRE ATLAS mitigation IDs where applicable; HCT threat roots addressed (BadCode / BadAction / BadPrincipal / BadPermissions).

Archetype reference patterns:

Inference endpoint pattern. Workload-identity-backed serving: the inference service uses a workload identity (IRSA / GCP Workload Identity / Azure Managed Identity), no long-lived API key; per-tenant authentication: every inference consumer presents a token scoped to their tenant before receiving output; mTLS between the API gateway and the serving cluster; rate-limit and abuse-detection layer at the API gateway (per-consumer quota defined; anomalous query volumes and model-extraction probe patterns trigger alerts); full request/response metadata logging with PII redaction (prompt and completion text not retained unless a documented lawful basis is in place, metadata only by default: consumer identity, timestamp, model version, latency); region-pinned deployment: the serving cluster does not accept workloads or route traffic outside the declared region boundary without explicit approval; signed model artifacts only: the serving cluster's admission hook rejects any model artifact lacking a signature from the approved signing key; canary deployment and rollback playbook: new model versions are deployed to a canary slice before full promotion; a rollback procedure is tested at least quarterly. Threats mitigated: model extraction via inference API (AML.T0024, rate limiting + abuse detection), cross-tenant isolation breach (per-tenant auth + mTLS), model swap / silent version flip (signed artifacts + canary + rollback), denial-of-service / prompt flood (rate limit + abuse detection). HAI-TTP: TM (rate limiting mitigates model extraction), EA (workload identity scope minimization). ATLAS: TA0013 Exfiltration mitigated by rate limit and abuse detection; TA0006 Persistence mitigated by signed artifacts and version pinning.

Model registry pattern. Workload-identity-only writes: the registry's write interface accepts only tokens issued to approved workload identities (CI/CD service accounts that have passed the eval gate); no long-lived API keys or personal credentials can push a model artifact; signed model artifacts: every artifact is signed at push time using the org's approved signing key; lineage tracked back to training job: each artifact record includes the training-job ID, dataset version, eval-gate result, and signing key identifier; access control by classification: model artifacts classified as Critical or High require a review approval record in the promotion log before promotion to the production-facing registry path; immutable promotion log: the promotion record is append-only and cannot be modified or deleted; read access scoped to the minimum required for the consumer (inference-endpoint service accounts get read-only access to their declared model path only; no broad read across all model paths). Threats mitigated: unauthorized model upload (AML.T0010, workload-identity-only writes + allowlist), model artifact tampering (signed artifacts + immutable log), credential theft for registry access (no long-lived keys), deletion/rollback abuse (append-only promotion log + access control). HAI-TTP: RA (signed artifacts and lineage prevent model behavior from drifting due to unauthorized substitution). ATLAS: TA0006 Persistence mitigated by signed artifacts and lineage; TA0007 Privilege Escalation mitigated by write-list enforcement.

GPU / accelerator fleet pattern. Workload-namespace isolation: training, fine-tuning, and inference jobs from different tenants run in separate Kubernetes namespaces; network policies enforce that cross-namespace traffic is blocked; GPU residual-state clearing between jobs: a device-level clearing mechanism (device reset, memory zeroing, or equivalent) runs between every job; conformance-tested at minimum quarterly; for Critical-tier workloads: dedicated nodes, jobs carrying a Critical data classification are assigned to dedicated node groups via node affinity rules; no Critical-tier job is scheduled on a shared node; scheduler-side data-classification awareness: the job-scheduling layer is aware of the workload's classification and enforces the appropriate node affinity policy; egress allow-list on all training and inference namespaces: outbound connections from GPU namespaces are permitted only to declared destinations (model registry, training-data store, telemetry collector), no unrestricted internet egress. Threats mitigated: cross-tenant residual-state leakage (residual-state clearing + namespace isolation), scheduler abuse (namespace isolation + node affinity enforcement), training-job hijack (namespace isolation + egress allowlist), GPU-firmware persistence (dedicated nodes for Critical workloads reduce blast radius). HAI-TTP: RA (residual-state clearing prevents cross-tenant data contamination). ATLAS: TA0010 Collection mitigated by residual-state clearing and namespace isolation; TA0006 Persistence mitigated by dedicated nodes and clearing.

Orchestrator / control plane pattern. Signed workflows: pipeline and workflow definitions are stored in version control and signed at merge; the orchestrator verifies signatures before executing any workflow; workflow-step authentication: each step executes under a step-specific workload identity scoped to the minimum resources required for that step; no step inherits the orchestrator's full credential set; per-step principal: the orchestrator enforces that each step's workload identity is pre-declared and immutable for the run; agent-state confidentiality: the orchestrator's state backend (agent memory, tool-call history, goal state) is encrypted at rest with a key scoped to the pipeline run or tenant; control-plane API authenticated, rate-limited, and audited: the management API requires workload-identity authentication; all API calls are logged to the SIEM; no anonymous or unauthenticated access to the orchestrator control plane. Threats mitigated: orchestrator credential abuse (workload-identity-only access + per-step principal), workflow injection (signed workflows + signature verification), agent-state tampering (state confidentiality + encryption), control-plane API abuse (authenticated + rate-limited + audited API). HAI-TTP: AGH (signed workflows prevent injection of hostile steps), EA (per-step principal prevents privilege accumulation across steps). ATLAS: AML.T0051 analog at workflow level mitigated by signed workflows; TA0007 Privilege Escalation mitigated by per-step principal.

Vector-store pattern. Per-tenant index partitioning: tenant A's embedded chunks are stored in a namespace physically or logically separate from tenant B's; the retrieval query interface enforces namespace scoping, a query authenticated as tenant A cannot return chunks from tenant B's namespace; classification-labeled per chunk: every indexed chunk carries a classification label; the retrieval API enforces classification-based access control, a consumer authenticated at Low classification cannot retrieve chunks labeled High or Critical; access control by principal: the embedding query interface requires authentication via workload identity; no anonymous or unauthenticated retrieval; query-pattern observability: retrieval query logs are collected, baselined, and monitored; anomalous patterns (high-volume extraction behavior consistent with corpus enumeration or embedding inversion) generate alerts; injection defense: documents ingested into the vector store are validated against a prompt-injection canary list; the retrieval API returns chunks with provenance metadata (source, classification, last-verified date) that consumers can inspect. Threats mitigated: unauthorized read of corpus (per-tenant partitioning + access control), embedding extraction at scale (rate limit + query-pattern monitoring), indexer abuse (ingest validation + canary detection), retrieval-policy bypass (namespace enforcement + classification-based access control). HAI-TTP: AGH (injection defense mitigates indexer abuse as a precursor to retrieval-delivered injection). ATLAS: AML.T0024 Exfiltration mitigated by rate limit and monitoring; TA0010 Collection mitigated by per-tenant partitioning.

AI CI/CD pattern. Signed pipeline definitions: CI/CD pipeline configurations are stored in version control and signed at merge; the pipeline runner verifies the signature before executing any step; SLSA-style provenance for model and dataset artifacts: every model artifact produced by the pipeline carries a signed provenance attestation (training-job ID, dataset version, build environment hash, signing key); eval gate as required check: no model artifact can be promoted to the production model registry without a passing eval-gate result on file, the promotion workflow enforces this as a non-bypassable gate; promotion-policy enforced: for Critical-tier artifacts, a named reviewer sign-off is required in addition to the eval-gate result before promotion is permitted; secrets vault: all credentials used in pipeline steps (model-registry push credentials, cloud-provider credentials, dataset-store access keys) are retrieved at runtime from the approved secrets vault, no credentials in pipeline configuration files, environment variables, or container images; dependency pinning and scanning: all ML dependencies (Python packages, container base images, model checkpoints from external sources) are pinned to specific versions and scanned for known vulnerabilities before use; no dependency fetched from an unverified external source. Threats mitigated: training-pipeline supply-chain compromise (AML.T0010, signed pipeline definitions + dependency scanning + SLSA provenance), poisoned-dependency injection (dependency pinning + scanning), model-promotion bypass (eval gate + promotion policy), eval-gate spoofing (promotion policy requires named reviewer sign-off for Critical-tier in addition to automated gate), build-time SSRF (secrets vault pattern eliminates credential exposure). HAI-TTP: RA (signed artifacts and eval gate prevent rogue model behavior from reaching production). ATLAS: TA0003 Initial Access mitigated by signed pipelines and dependency scanning; TA0008 Defense Evasion mitigated by eval gate and promotion policy.

Feature store / online serving cache pattern. Offline/online skew monitoring: a monitoring mechanism collects the feature distribution served at inference time and compares it to the distribution used at training time; anomalous skew above a defined threshold generates an alert and triggers a human review gate; access control: the feature query API requires authentication via workload identity; feature reads are scoped to the minimum feature set declared for the model's use case, no broad access to all features in the store; feature-lineage tracking: every feature has a documented source pipeline, last-updated timestamp, classification label, and lineage version; the lineage record is queryable and stored alongside the feature definition; rollback on poisoning: a rollback procedure exists to restore the feature store to a known-good snapshot within the defined RTO; the procedure is documented, tested annually, and the rollback invocation path is accessible without requiring the compromised serving layer. Threats mitigated: feature poisoning (offline/online skew monitoring + access control), online/offline-skew abuse (skew monitoring + alert), unauthorized feature read (workload-identity-scoped access control). HAI-TTP: RA (skew monitoring detects model behavior drift driven by feature poisoning). ATLAS: AML.T0020 Poison Training Data analog at feature layer mitigated by skew monitoring and rollback.

B) Publish the anti-pattern catalog

Name, describe, and prohibit the AI/HAI infrastructure architectural patterns that reliably produce incidents. Each anti-pattern entry includes: description, why it is dangerous, real-incident flavor (industry or first-party), and the reference pattern element that replaces it.

L1 anti-pattern set:

• Shared GPUs for regulated workloads, training or fine-tuning jobs containing regulated personal data (PII, PHI, financial records) co-scheduled with unrelated workloads on shared GPU nodes; residual-state from the regulated job is accessible to a subsequent tenant. Replaced by: GPU fleet pattern dedicated-node isolation for Critical-tier workloads + residual-state clearing.
• World-readable model registry, model registry storage bucket or API endpoint with public-read or all-authenticated-users access; any principal with cloud credentials can pull model weights, including fine-tuned models trained on regulated data. Replaced by: model registry pattern scoped read access + workload-identity-only writes.
• Unsigned model artifacts in production, inference endpoints serve model artifacts that were never signed; there is no mechanism to detect if a model artifact was tampered with between registry push and serving. Replaced by: model registry pattern signed artifacts + inference endpoint pattern admission-hook signature verification.
• Control-plane API without auth, orchestrator or MLOps control plane management API reachable via HTTP without authentication; any network-adjacent principal can list pipelines, trigger runs, or exfiltrate pipeline secrets. Replaced by: orchestrator pattern authenticated + rate-limited + audited control-plane API.
• Vector store without per-tenant partitioning, retrieval store serving multiple tenants from a single namespace; a query from one tenant returns chunks belonging to other tenants; classified content is accessible to lower-privilege consumers. Replaced by: vector-store pattern per-tenant index partitioning + classification-based access control.
• CI/CD with hardcoded credentials, model-registry push tokens, cloud-provider credentials, or dataset-store access keys embedded in pipeline configuration files, container image layers, or environment variables; any principal who can read the pipeline definition or container image can extract the credentials. Replaced by: AI CI/CD pattern secrets vault for all credentials.
• Inference endpoint without rate limits, inference endpoints serving production traffic without per-consumer quotas; a single compromised consumer or a model-extraction probe can exhaust GPU capacity for all consumers or reconstruct model weights via high-volume queries. Replaced by: inference endpoint pattern rate-limit + abuse-detection layer.
• Long-lived admin credentials for registry and orchestrator, human administrators access model registries, orchestrator control planes, and GPU schedulers using long-lived personal access tokens or service account keys; a credential compromised on a developer laptop yields durable access to production AI infrastructure. Replaced by: all patterns' workload-identity-only access + JIT human admin elevation.

C) Integrate patterns into the intake/inventory flow and establish the deviation-review path

Reference patterns are only useful if platform teams encounter them at the right moment, when they are provisioning or modifying an AI/HAI infrastructure asset.

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

Outcome Metrics (L1)

Process Metrics (leading)

• Pattern review cadence, quarterly refresh with change-log maintained.
• New-archetype lead time, new pattern published within 30 days of the first intake in a new archetype category.
• Deviation-review SLA, ≤5 business days from deviation request to decision.
• Anti-pattern catalog linked from the AI Acceptable Use Policy and the SM intake gate.

Effectiveness Metrics (business value)

• Build lead time, time-to-production for a team provisioning new AI/HAI infrastructure via the reference pattern decreases after patterns land and the green path is clear.
• Avoided-incident stories, documented cases where the pattern (e.g., residual-state clearing, signed artifacts, per-tenant partitioning) blocked or contained a real risk before it reached production.
• Pattern reuse rate, % of new assets using the pattern unchanged vs. deviating; rising reuse indicates the pattern is fit for purpose.

Success Criteria

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

Maturity Level 2

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

At this level, architecture moves from "single-path reference" to "production-scale reference set." Tier-conditional patterns apply: Critical-tier assets receive dedicated-node isolation IaC, kill-switch infrastructure, and data-residency enforcement; High-tier assets receive monitoring and logging IaC modules; patterns are encoded as Terraform / Pulumi / Helm so platform teams fork rather than handcraft; multi-region, multi-tenant, and multi-tier complexity are all covered. The anti-pattern catalog evolves from real IM-Infrastructure findings.

Dependencies

• SA-Infrastructure L1 (required): base reference patterns and anti-pattern catalog are the substrate L2 extends.
• SR-Infrastructure L2 (required): quantitative and tier-calibrated requirements drive the L2 pattern controls.
• TA-Infrastructure L2 (required): per-asset and per-tier deep threat models surface the controls each L2 pattern must cover.
• SM-Infrastructure L2 (required): risk-tier rubric determines which tier-conditional pattern variant applies to each asset.
• IM-Infrastructure L1+ (required): incidents feed anti-pattern additions and drive pattern evolution.

Desired Outcomes

• Platform teams provisioning Critical or High-tier AI/HAI infrastructure have a production-grade pattern to fork rather than a reference diagram to interpret.
• Tier-conditional pattern variants are explicit: Critical gets dedicated-node isolation IaC, kill-switch IaC, and data-residency variant; High gets monitoring and logging IaC modules; Medium and Low follow the base pattern.
• Anti-pattern catalog reflects real IM-Infrastructure incidents, not only theoretical harms.
• Pattern drift is detectable: IaC-encoded patterns enable conformance testing; assets using old or hand-modified patterns are flagged.
• Architecture evidence for Critical-tier assets is sufficient to support EU AI Act Art. 9 risk management, Art. 15 accuracy/robustness/cybersecurity, and ISO/IEC 42001 AIMS documentation obligations.

Activities

A) Tier-conditional pattern extensions

Publish extended pattern variants calibrated to SM-Infrastructure L2's tier-treatment matrix. The base L1 patterns remain; L2 adds tier-specific overlays and variants:

• Critical-tier overlay (applies to any archetype at Critical tier): dedicated-node isolation IaC (Terraform/Pulumi module that provisions a dedicated node group with node affinity rules enforced at the scheduler layer; Critical-tier GPU nodes are tainted to prevent non-Critical workloads from scheduling); kill-switch IaC (infrastructure-level process termination for the inference endpoint and orchestrator control plane, tested quarterly with the test result written to the REM); data-residency enforcement variant (region pinning at the API-gateway and networking layers; cross-region failover preserves residency; GDPR Art. 44–49 international-transfer mechanism selection step included as a required decision gate in the IaC module); EU AI Act Art. 9 and Art. 15 controls explicitly mapped in the pattern; technical-documentation artifact template auto-populated from the IaC module to support EU AI Act Art. 11 documentation duties.
• High-tier overlay: monitoring and logging IaC modules included in the fork (pre-wired SIEM log-forwarding pipeline for inference-endpoint, model-registry, GPU-scheduler, orchestrator, and vector-store events; standard detections from ML-Infrastructure L2 pre-wired; alert routing to the SIEM and IM-Infrastructure).
• Multi-region pattern: residency enforcement for global deployments (region pinning at API-gateway layer; cross-region failover with residency preservation; cross-region data-flow legal basis under GDPR Art. 44–49 confirmed as a required step; data-classification awareness preserved across regions).
• Multi-tenant pattern for shared infrastructure: per-tenant namespace isolation at the Kubernetes, network, and storage layers; per-tenant KMS key for model artifacts and vector-store data; per-tenant IAM scope for service principals; tenant-isolation conformance test wired into CI.
• Per-tier IaC modules (Terraform / Pulumi / Helm): Critical-tier inference endpoint module, Critical-tier model registry module, Critical-tier GPU fleet module, Critical-tier orchestrator module, each as a forkable IaC module with a conformance test suite.

B) Patterns-as-IaC with conformance test suites

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

C) Incident-informed anti-pattern catalog refresh

• Every IM-Infrastructure incident classified to an anti-pattern (existing or new); classification recorded in the IM finding.
• Catalog refreshed monthly from IM-Infrastructure findings; new anti-patterns surfaced to teams at intake time.
• Quarterly review: if three or more assets have deviated from a pattern in the same direction, the pattern is queued for update.
• Anti-patterns originating from Critical-tier incidents are escalated to the SM working group for a pattern-update sprint within 30 days.

Outcome Metrics (L2)

Process Metrics (leading)

• Pattern refresh cadence, at least one substantive pattern change per quarter, change-logged.
• Anti-pattern review cadence, monthly from IM-Infrastructure findings.
• IaC pipeline health monitored, module-update notification and drift-detection pass tracked.
• Tier-treatment matrix adherence check, quarterly reconciliation of Critical/High asset list against IaC-encoded pattern adoption.

Effectiveness Metrics (business value)

• Provisioning time-to-production drops for teams building Critical/High-tier infrastructure that fork IaC modules rather than handcraft configurations.
• Incident rate on IaC-encoded deployments lower than on hand-crafted deployments, tracked as a rolling 12-month comparison.
• Conformance test failures caught in CI before production, not in DR or IR.

Success Criteria

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

Maturity Level 3

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

At this level, the reference patterns are open artifacts that the industry adopts, forks, and builds on. The org contributes pattern-derived mitigations to MITRE ATLAS (AML.M00xx), to CNCF AI security working groups, and to OpenSSF AI. Pattern adoption telemetry is operational. Regulatory engagement on EU AI Act implementing acts and sector architecture guidance is active. Internal practice is aligned to the published external versions.

Dependencies

• SA-Infrastructure L2 (required): IaC-encoded patterns and conformance test suites are the substrate L3 publishes and maintains externally.
• SM-Infrastructure L3 (alignment): automation and benchmarking substrate supports the telemetry and benchmarking activities at L3.
• IM-Infrastructure L2+ (required): incident-to-pattern feedback loop must be operational before incident data drives external contributions.

Desired Outcomes

• At least two SA-Infrastructure reference patterns are cited or forked by recognized industry bodies (CNCF, OpenSSF AI, MITRE ATLAS, CSA AI Safety Initiative, or sector equivalents).
• MITRE ATLAS mitigation library carries at least two AML.M00xx entries attributable to SA-Infrastructure patterns (GPU residual-state clearing, signed-artifact enforcement, per-tenant partitioning, or equivalent).
• Internal practice is aligned to the published external version, not an aspirational document the org once published and no longer follows.
• Regulatory bodies and sector organizations reference SA-Infrastructure patterns in architecture guidance or implementing-act consultations.

Activities

A) Publish reference patterns as open artifacts

• Patterns published under Apache 2.0 or equivalent open license via CNCF AI working groups, OpenSSF AI, CSA AI Safety Initiative, or equivalent.
• Maintained upstream in the public repository; internal use aligns with the external version; internal deviations are proposed as upstream changes rather than silent forks.
• Pattern adoption telemetry tracked: GitHub forks, citations in published work, documented adopters.
• New archetypes or overlays developed internally are proposed for inclusion in the external catalog within 90 days of internal publication.

B) Contribute to MITRE ATLAS mitigation library

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

C) Engage regulators, CNCF, and OpenSSF on architecture norms

• Active participation in CNCF AI working group, contribute the SA-Infrastructure reference patterns as practitioner input to AI workload security guidance for Kubernetes; submit the GPU isolation pattern, orchestrator signing pattern, and vector-store partitioning pattern for community adoption.
• OpenSSF AI, submit the AI CI/CD pattern (signed pipeline definitions, SLSA provenance, eval-gate enforcement) as a practitioner contribution to OpenSSF AI supply-chain security guidance.
• EU AI Act implementing-act consultations, submit SA-Infrastructure patterns as evidence of "state of the art" infrastructure practice under Art. 9 and Art. 15 for high-risk AI systems.
• Sector-specific engagement, submit sector-relevant pattern variants to relevant sector bodies (FS-ISAC, H-ISAC, sector AI working groups); seek inclusion in sector architecture guidance documents.

Outcome Metrics (L3)

Process Metrics (leading)

• External contribution pipeline, ≥2 pattern items in-flight (draft, in-review, or in-publication) at all times.
• Internal-external alignment audit, quarterly diff between internal pattern versions and published external versions; unexplained divergence queued for resolution.
• ATLAS contribution cadence, at least one contribution or validation per 6 months.
• Regulatory and community engagement calendar maintained with active items and target timelines.

Effectiveness Metrics (business value)

• Industry recognition, invitations to working groups, citations in published standards, peer adoption of SA-Infrastructure patterns.
• Regulatory benefit, SA-Infrastructure patterns referenced in implementing-act or guidance documents reduce compliance uncertainty for the org and the industry.
• Talent, external publication and standards participation attracts experienced MLOps security architects and platform engineers with AI infrastructure security expertise.
• Faster infrastructure provisioning, industry adoption of patterns means external teams the org integrates with arrive already familiar with the architecture norms; integration and audit friction decreases.

Success Criteria

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

Key Success Indicators

Level 1: - Seven reference patterns published, one per archetype (inference endpoint, model registry, GPU/accelerator fleet, orchestrator/control plane, vector-store infra, AI-specific CI/CD, feature store), each with a labeled architecture diagram, scope, identity and auth model, isolation spec, traffic path, logging spec, and row-by-row mapping to SR-Infrastructure requirements and TA-Infrastructure threats; HAI TTP tags (EA / AGH / TM / RA), MITRE ATLAS mitigation IDs, and HCT threat roots addressed present where applicable. - Anti-pattern catalog published (minimum 8 entries), each linked to a reference pattern element that replaces it; linked from the AI Acceptable Use Policy, the SM intake gate, and EG-Infrastructure training. - ≥85% of active AI/HAI infrastructure assets in the SM inventory classified as "on pattern" or "deviation with review"; no silent deviations. - 100% of inference endpoints and model registries with workload-identity-only access (no long-lived API keys in service principals) confirmed by IAM audit. - Deviation-review path operational with a named architect-reviewer population, ≤5 BD SLA, and a repeat-deviation signal that queues pattern updates.

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

Level 3: - ≥5 reference patterns published as open artifacts under a recognized open license; ≥2 cited or forked by recognized industry or sector bodies. - ≥2 MITRE ATLAS AML.M00xx mitigation entries proposed or validated, traceable to SA-Infrastructure pattern controls aligned to TA0006 / TA0007 / TA0008. - Internal practice 100% aligned to published external versions; all deviations proposed as upstream contributions, none silently forked. - At least one documented reference to SA-Infrastructure patterns in a regulatory implementing-act, sector guidance document, or standards text.

Common Pitfalls

Level 1: - ❌ Patterns are written but not linked from the SM inventory record or the intake gate, platform teams skip them because they are hard to find, not because they disagree with them. - ❌ The GPU fleet pattern mentions residual-state clearing but provides no guidance on implementation (device reset vs. memory zeroing vs. namespace teardown), teams interpret "clearing" as whatever is cheapest and easiest, which may not actually prevent residual-state leakage. - ❌ The model registry pattern requires signed artifacts but the inference endpoint pattern does not include an admission-hook requirement to verify signatures, unsigned artifacts can still reach serving without triggering a violation. - ❌ Anti-patterns remain theoretical; they are not tied to real incidents or to the specific pattern element that replaces them, so engineers do not recognize the hazard when they encounter it. - ❌ Deviations are approved individually but the repeat-deviation signal is never wired, patterns never update because nobody aggregates the pattern-update trigger. - ❌ Vector-store pattern covers per-tenant partitioning but omits classification labeling at index time, queries return unclassified chunks to lower-trust consumers because the corpus was never labeled. - ❌ Pattern controls are mapped to SR requirements in the document but the mapping is never validated against an actual deployed asset, the traceability is aspirational.

Level 2: - ❌ IaC patterns are forked once and then hand-edited at each deployment, drift is immediate and the IaC substrate provides no baseline enforcement; conformance tests are skipped. - ❌ Tier-conditional patterns exist in documents but the IaC modules do not enforce the tier-specific controls, the Critical overlay exists on paper; deployed Critical-tier assets lack dedicated-node isolation IaC or kill-switch infrastructure. - ❌ Anti-pattern catalog grows from incidents but is only accessible as a reference document; teams encounter the anti-pattern again before they encounter the catalog entry. - ❌ Multi-region pattern covers residency in the diagram but does not include the GDPR international-transfer mechanism selection step, teams deploy cross-region inference pipelines without a documented legal basis. - ❌ The per-tier IaC modules for GPU fleets enforce node affinity at provisioning time but do not wire the residual-state clearing mechanism, nodes are dedicated, but clearing is absent; cross-tenant residual-state risk persists. - ❌ Pattern-drift detection fires on low-signal configuration noise; the platform team ignores it within a month; meaningful drift goes undetected.

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

Practice Maturity Questions

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

Level 2: 1. Are the five tier-conditional extended patterns (Critical overlay, High overlay, multi-region, multi-tenant, per-tier IaC modules) published as forkable IaC modules with conformance test suites, and are ≥80% of Critical and High-tier AI/HAI infrastructure assets running on IaC-encoded patterns as confirmed by the IaC and SM inventory registries? 2. Has the anti-pattern catalog been updated from ≥3 real IM-Infrastructure incidents in the last 12 months, with new entries surfaced at intake time rather than stored only in a reference document, and is conformance testing covering 100% of IaC-encoded asset deployments with findings tracked to resolution? 3. Are 100% of Critical-tier assets carrying explicit EU AI Act Art. 9 and Art. 15 control mappings in the pattern documentation, and is the tier-treatment matrix from SM-Infrastructure L2 reflected in the pattern variants (Critical assets get the Critical overlay, High assets get the High overlay, Medium/Low follow the base pattern)?

Level 3: 1. Have ≥5 reference patterns been published as open artifacts under a recognized open license via at least one industry body (CNCF AI, OpenSSF AI, CSA, or equivalent), and have ≥2 of those patterns been cited or forked by recognized industry or sector bodies, with documented adoption evidence and internal practice aligned to the published version? 2. Have ≥2 MITRE ATLAS AML.M00xx mitigation entries been proposed or validated, traceable to specific SA-Infrastructure pattern controls aligned to ATLAS primary tactics TA0006 Persistence, TA0007 Privilege Escalation, and TA0008 Defense Evasion, and is there an active ATLAS practitioner engagement cadence? 3. Is there at least one documented reference to SA-Infrastructure patterns in a regulatory implementing-act, sector guidance document, CNCF AI community document, OpenSSF AI guidance, or published standards text, and is the regulatory and community engagement calendar maintained with active items, target timelines, and evidence of substantive (not declaratory) participation?

Document Version: HAIAMM v3.0 Practice: Secure Architecture (SA) Domain: Infrastructure Last Updated: 2026-05-14 Author: Verifhai