Education & Guidance (EG)

Infrastructure Domain - HAIAMM v3.0

Practice Overview

Objective: Build the AI-assurance literacy every platform engineer, SRE, and cloud architect touching AI/HAI infrastructure needs and the practitioner skills the smaller population performing infrastructure security reviews, IaC security assessments, and platform hardening of AI/HAI systems must have, with shadow AI infrastructure awareness as the primary L1 cultural outcome.

Description: EG-Infrastructure covers two audiences. The first is the platform and SRE workforce who provision, operate, and maintain the seven AI/HAI infrastructure archetypes (inference endpoints / model-serving clusters, model registries, GPU / accelerator fleets, orchestrator control planes, vector-store infrastructure, AI-specific CI/CD, feature stores / online serving caches), they need AI infrastructure literacy: what the archetypes are, what the GPU fleet operational risks mean for the workloads they manage, how IaC for AI differs from general-purpose IaC, what region/residency constraints apply to AI serving infrastructure, and how to provision observability-compliant infrastructure from the start. The second is the practitioner population, platform security engineers, SRE on-call leads, and cloud architects performing AI infrastructure security reviews (DR, IR, TA), who need deep, hands-on skills covering inference-endpoint attack surface, model-registry attack surface, GPU-fleet IAM hardening, vector-store hardening, orchestrator control-plane security (EA/TM/RA through the control plane), AI-specific CI/CD pipeline attacks, IaC review patterns for AI infra, and per-archetype security baseline verification. EG-Infrastructure defines the outcomes the program must produce and how the organization measures whether those outcomes are reached.

Context: AI-specific infrastructure risks, model extraction at inference endpoints (ATLAS AML.T0015 / AML.T0024), model-registry tampering that injects malicious artifacts into the supply chain, GPU fleet IAM over-privilege enabling lateral movement to training data, vector-store inversion recovering sensitive content from embeddings, orchestrator control-plane compromise enabling EA/AGH/TM/RA at scale, AI-specific CI/CD attacks that promote poisoned models to production, are not covered by classic cloud-hardening or CSPM curricula. Platform engineers who have only taken generic AWS/GCP/Azure hardening training will provision an inference cluster without thinking about model-extraction resistance, and a cloud architect trained only on VPC security and IAM least-privilege will not recognize a vector-store namespace boundary failure or an orchestrator tool-scope misconfiguration. Without a deliberate EG practice targeted at these gaps, AI infrastructure risk surfaces late, at model-extraction incident time, in external audits, or in regulatory reviews of Art. 15 cybersecurity obligations. L1 EG-Infrastructure ships the minimum viable literacy for everyone provisioning AI/HAI infrastructure and the minimum viable practitioner track for those who review it. L2 extends into cloud-provider-specific tracks (AWS/GCP/Azure AI infra) and scenario-based platform reviewer training. L3 externalizes the curriculum through CNCF, OpenSSF AI, and cloud-provider partner programs.

Maturity Level 1

Objective: Deliver foundational AI infrastructure literacy to ≥95% of the platform/SRE workforce touching AI/HAI infrastructure and role-based practitioner training to 100% of the reviewer population, with an active shadow-AI-infrastructure awareness campaign

At this level, the organization ensures that every platform engineer and SRE who provisions or operates AI/HAI infrastructure can identify AI-specific infrastructure risks and navigate the program's policies and provisioning gate, and that the reviewer population can perform consistent infrastructure threat modeling, IaC review, and security baseline verification across AI/HAI archetypes.

Dependencies

• PC-Infrastructure L1 (required): the three priority policies (AI Infrastructure Standards Policy, GPU / Accelerator AUP, AI Infra Intake / Provisioning Gate) and the priority compliance map are the primary teaching object, training without published policies is hollow. EG-Infrastructure L1 cannot precede PC-Infrastructure L1.
• SM-Infrastructure L1 (required): the AI/HAI infrastructure inventory and archetype taxonomy define what the training is about and which archetypes platform engineers will encounter.
• Alignment (not a hard dependency): enterprise LMS and existing security-awareness program; platform engineering all-hands cadence for shadow-AI-infra awareness campaign launch.
• Supports / unblocks: every downstream Infrastructure-domain practice, reviewers who cannot distinguish an inference cluster from a vector store will not produce useful threat models (TA), requirements (SR), design reviews (DR), or implementation reviews (IR) for AI/HAI infrastructure.

Desired Outcomes

• Any platform engineer or SRE provisioning AI/HAI infrastructure can name the seven archetypes the org sanctions, cite the two or three AUP rules most relevant to their archetype, describe one infrastructure-specific risk relevant to what they are building, and submit an intake ticket or disclose prior unsanctioned provisioning in under 5 minutes.
• The reviewer population (platform security engineers, SRE on-call leads, cloud architects performing AI infra reviews) produces consistent, evidence-backed reviews, two practitioners independently reviewing the same inference cluster intake arrive at the same threat snapshot and the same SR gap list.
• Shadow AI infrastructure disclosures increase in the first two quarters after the campaign launches (awareness working), then decrease as the sanctioned-archetype program grows (adoption working).
• Region/residency obligations under GDPR Art. 44–49 are not abstract, every reviewer can map a cross-border inference endpoint to the transfer basis it requires and the residency constraint it triggers.
• Training content is owned, dated, and updated within 30 days of any change to the AUP, provisioning gate policy, archetype list, or priority compliance map.

Activities

A) Ship workforce AI infrastructure literacy training

A single short course (≤20 minutes) every platform engineer, SRE, and cloud architect touching AI/HAI infrastructure takes on hire and refreshes annually, tied to the AI Infrastructure Standards AUP attestation from PC-Infrastructure L1. This is not a comprehensive cloud-hardening course, it is the minimum AI infrastructure literacy needed to participate in the AI/HAI infrastructure program without creating compliance exposure.

Content (minimum): - What the AI/HAI infrastructure archetypes are, the seven archetypes sanctioned by the org (inference endpoint / model-serving cluster, model registry, GPU / accelerator fleet, orchestrator / control plane, vector-store infrastructure, AI-specific CI/CD, feature store / online serving cache). Concrete examples from the org's own inventory, with the AI/HAI software artifacts each type of infrastructure hosts. - GPU fleet operational risk in plain terms, GPU fleet credentials as high-value targets; training-data access scope as a blast-radius control; isolation between workloads on shared fleets; GPU-spend tagging as a shadow-infra detection signal; what happens when a researcher provisions GPU resources outside the sanctioned fleet. - IaC for AI infra, three key differences from general IaC, model artifacts require signing/checksum; inference endpoints require auth at every interface; GPU workload isolation requires explicit namespace or VM-level controls in the IaC module; the three most common misconfigurations in AI infra IaC modules and how to spot them in a pull-request review. - Region/residency for AI serving infrastructure, why a cross-border inference endpoint processing personal data triggers GDPR Art. 44–49; what residency means for a vector store indexed with user-generated content; the two-line IaC attribute that pins a deployment to a declared region; how to flag a cross-border deployment in the intake form. - Observability minimums for AI workloads, the structured logs every inference endpoint must emit (inference access logs); what an orchestrator state log captures vs. a general application log; why prompt/completion log retention is different from general request logging; the difference between "logging enabled" and "logging-baseline compliant." - The provisioning gate, how to submit intake, what the per-archetype artifacts checklist requires, what "provisional approval" means, and how the amnesty path works for infrastructure already in production. - Shadow AI infra decision aid, a 10-second check: is this archetype in the inventory? Is the data classification permitted for this fleet? Does this scope require intake approval before I deploy?

Delivery: LMS module + 1-page reference card pinned in platform/SRE Slack/Teams + brief at platform all-hands when the program launches. No role gating, every engineer provisioning or operating AI/HAI infrastructure takes the same workforce-level module.

B) Deliver role-based practitioner training for the reviewer population

A deeper module (~2 hours) for the practitioner population only: platform security engineers performing TA and SR intake reviews for AI infrastructure, SRE on-call leads responsible for AI infra incident response, and cloud architects reviewing AI infrastructure designs in DR. This is where the specific AI/HAI infrastructure security review skill gets built. Completion is a prerequisite to approving infrastructure intakes, not optional.

Content (minimum): - Inference-endpoint attack surface, model-extraction techniques (ATLAS AML.T0015 ML Model Access via Physical Environment, AML.T0024 Exfiltration via ML Inference API); prompt injection at the serving layer as an AGH vector; how inference access log completeness verifies observability compliance; no-public-endpoint enforcement at the IaC level; authentication bypass patterns on serving APIs. - Model-registry attack surface, supply-chain compromise via registry (ATLAS AML.T0010 ML Supply Chain Compromise); artifact unsigned or unverified promotion; how a two-party promotion gate prevents unilateral model promotion; what a registry audit log should capture and how to verify it in an IR. - GPU fleet IAM hardening, what "no standing human IAM on production GPU fleet" means at the cloud-provider policy level (AWS IAM, GCP IAM, Azure RBAC); how secrets-vault integration for fleet credentials works; training-data access scoping as a blast-radius control; GPU-spend anomaly as a shadow-infra detection signal. - Vector-store hardening, embedding inversion: how high-dimensional embeddings can reconstruct sensitive source content; namespace/collection boundary failures; what "no collection with public read access" means in Weaviate, Qdrant, and pgvector; TLS enforcement on client connections; how to verify collection access control in an IR. - Orchestrator control-plane security, EA/TM/RA TTPs at the orchestrator level: an orchestrator with a too-broad tool scope is an EA vector; a crafted workflow input that redirects orchestrator execution is an AGH vector; recursive tool invocation that exceeds declared scope is a TM vector; long-running agent sessions drifting from intended behavior in Temporal/Airflow/LangGraph is an RA vector; how to assess tool-scope boundary in an SR REM for an orchestrator; what control-plane authentication enforcement looks like in a DR review. - AI-specific CI/CD attacks, model poisoning through the training pipeline (ATLAS AML.T0020 Poison Training Data); malicious model promotion via compromised CI/CD credentials; eval-gate bypass (manipulating threshold configuration to promote a degraded model); artifact signing verification gaps; pipeline credential vault gaps; what a sound AI-specific CI/CD security baseline looks like in an IaC review. - IaC review patterns for AI infra, a checklist-driven IaC review for each archetype: which Terraform / Pulumi resource attributes indicate public endpoints, missing encryption, missing auth, missing isolation, missing logging; how to run the review in a pull-request context within 15 minutes per archetype; how to generate the SR REM gap list from an IaC review. - Priority compliance map in practice, given an archetype, which requirements from PC's map apply, where the evidence lives in the provisioning gate record, and what an auditor will ask: EU AI Act Art. 15 cybersecurity evidence, GDPR Art. 32 processing-security record, SOC 2 CC6/CC7/CC8 evidence, FedRAMP evidence for applicable instances. - Calibration exercise, three sample archetype intakes (e.g., a customer-facing inference cluster, a multi-tenant GPU fleet for training runs on confidential data, a cross-border vector store indexed with user-generated content) scored independently; facilitated debrief on tier assignment, risk identification, and SR gap list.

Delivery: instructor-led or recorded workshop + role-specific reference job aids (one per archetype: "what to look for in a [inference cluster / GPU fleet / orchestrator / vector store / AI CI/CD] intake") + quarterly calibration session. Completion gated on intake-approval permissions.

C) Run the shadow-AI-infrastructure awareness campaign

An always-on communications program making it uncomfortable to provision AI/HAI infrastructure outside the program and easy to surface it. L1 target is a sustainable, lightweight cadence.

Campaign elements: - Launch moment, executive sponsor message naming shadow AI infrastructure, announcing the amnesty window, and publishing the sanctioned-archetype catalog. Explicit framing: the program is an enabler (fast-track for Low-tier) not a blocker. - Recurring short content, monthly one-paragraph pieces: new archetype approved and available, a fast-track provisioning win (intake to provisional approval in 3 BD for an internal vector store), an anonymized example of a risk caught during intake review (with team permission), an external incident reframed as "what would we find if we checked our own GPU fleet or inference endpoints?" - "Is this AI infra?" series, periodic call-outs of GPU workloads launched for side projects, inference endpoints added to Kubernetes without intake, vector collections created by engineering teams for features in development, with clear instruction on whether existing gate coverage applies. - Amnesty visibility, the path to disclose prior unsanctioned AI/HAI infrastructure is linked from the AUP, the intake form, and the platform engineering Slack/Teams channel pins. Amnesty is prominent, not buried. - Feedback channel, a visible channel for platform engineers to nominate new archetype patterns or IaC module patterns for the sanctioned catalog; nominations triaged and acknowledged within 5 BD. - Region/residency micro-content, short explainers for teams deploying cross-border inference infrastructure: what residency pinning means in Terraform, which GDPR Art. 44–49 transfer basis applies, how to flag cross-border deployment in the intake form.

Measurement: campaign channel links are tagged so attribution of intake submissions and amnesty disclosures to campaign touchpoints is tracked.

Outcome Metrics (L1)

Process Metrics (leading)

• Workforce training content reviewed quarterly; updated within 30 days of any change to the AUP, archetype list, or priority compliance map.
• New-hire coverage SLA, AI infrastructure literacy completed within 30 days of start.
• Reviewer calibration cadence, at least once per quarter; drift trends reported to the program sponsor.
• Campaign content cadence, at least one piece of shadow-AI-infra content published per month.

Effectiveness Metrics (business value)

• Reviewer throughput, infrastructure intakes closed per reviewer per week should rise after practitioner training lands without sacrificing calibration quality.
• Sanctioned-archetype adoption, % of new AI/HAI infrastructure instances using a sanctioned IaC module or reference architecture rather than a bespoke provisioning approach; rising reuse signals literacy plus catalog together reducing shadow infra.
• Avoided-incident stories, documented cases where practitioner training enabled a reviewer to catch an inference-endpoint auth gap, GPU fleet IAM over-privilege, vector-store public-endpoint misconfiguration, or orchestrator tool-scope violation at intake that would otherwise have been provisioned.

Success Criteria

• Workforce AI infrastructure literacy module launched; ≥95% current-year completion sustained.
• Practitioner training launched, completion gated on intake-approval permissions, and calibration drift inside target for two consecutive quarters.
• Shadow AI infrastructure awareness campaign running with at least monthly content cadence and measurable attribution of intake submissions and amnesty disclosures to campaign channels.
• Region/residency micro-content deployed for every cross-border or regulated-data-processing AI/HAI infrastructure archetype active in the inventory.
• Training content owner named; content updated within 30 days of any change to policies, archetype list, or compliance map.

Maturity Level 2

Objective: Deepen practitioner skill through scenario-based training from real infrastructure intake cases, deliver cloud-provider-specific tracks (AWS/GCP/Azure AI infra) calibrated to SM-Infrastructure L2 risk tiers, and run seasonal shadow-AI-infra campaigns tied to provisioning cycles

At this level, training stops being one-size-fits-all. Reviewer skill deepens through scenario-based exercises built from anonymized real intakes from the org's own provisioning queue. Platform and SRE teams receive cloud-provider-specific tracks aligned to the AI infrastructure they actually operate. Shadow-AI-infra campaigns become behavior-driven and seasonal rather than standing background noise.

Dependencies

• EG-Infrastructure L1 (required): workforce literacy and base practitioner training must be in place.
• SM-Infrastructure L2 (required): the risk-tier rubric defines which archetype instances go to which reviewer track depth and at what cadence.
• TA-Infrastructure L2 (required for Critical-tier scenarios): per-instance deep threat models provide the scenario source material for Critical-tier reviewer exercises.
• Supports / unblocks: PC-Infrastructure L2 (tier-calibrated reviewers enforce tier-specific policies and sign-off requirements); SA-Infrastructure L2 (engineering-track trainees learn the reference architectures they will build against); DR-Infrastructure L2 (scenario-trained reviewers produce faster, more consistent DR decisions).

Desired Outcomes

• Reviewer calibration on Critical-tier infrastructure intake scenarios is visibly tighter than at L1, the practitioner investment is measurable.
• Cloud-provider-specific tracks ensure that teams operating AWS SageMaker / Bedrock infrastructure, GCP Vertex AI infrastructure, and Azure OpenAI / AML infrastructure can independently identify the cloud-provider-specific AI infrastructure risks and defend their provisioning choices in a DR.
• Shadow-AI-infra campaigns run on a behavior-driven, seasonal cadence (large provisioning cycles, hiring surges, post-external-incident moments) with pre-measured behavior targets and post-campaign measurement.
• Training content refreshes monthly from program telemetry, real calibration drifts, real intake anomalies, real near-incidents, not from annual curriculum reviews.

Activities

A) Scenario-based reviewer training from real infrastructure intakes

• Scenario library built from anonymized real infrastructure intakes from the org's own provisioning queue: each scenario includes the as-submitted archetype description, the original reviewer decisions (tier, risk identifications, SR gaps), any reviewer disagreement, and the resolved outcome after calibration or post-deployment review.
• Scenarios organized per archetype (inference cluster scenarios, GPU fleet scenarios, orchestrator scenarios, vector-store scenarios, AI CI/CD scenarios) and per risk cluster (model-extraction-exposure-heavy, IAM-over-privilege-heavy, tool-scope-violation-heavy, cross-border-transfer-heavy).
• Paired calibration exercises: two reviewers independently score the same scenario; instructor-facilitated debrief on tier delta, risk identification deltas, and SR gap list differences.
• Tier-weighted curriculum: Critical-tier customer-facing inference cluster and GPU-fleet-processing-regulated-data scenarios dominate the advanced modules; Medium/Low scenarios streamlined to fast-track calibration.
• Capstone: practitioners graduate the advanced module by running three live intakes end-to-end with a senior-reviewer shadow and producing a passing TA snapshot and SR REM for each archetype.

B) Cloud-provider-specific AI infrastructure tracks

Distinct training tracks for platform/SRE teams operating AI/HAI infrastructure on each major cloud provider. These are not generic cloud-hardening tracks, they cover the AI-specific services and their security configurations.

• AWS AI infra track, SageMaker endpoint security (auth, VPC-private, model encryption, inference access logs in CloudWatch); Bedrock provisioned-throughput security (IAM policies, VPC endpoints, CloudTrail audit); EKS GPU workload isolation (node pools, namespaces, RBAC, GPU plugin security); ECR image signing for ML base images; SageMaker Model Registry two-party promotion gate; AWS Secrets Manager for GPU fleet and inference-endpoint credentials; AWS PrivateLink for vector-store backends (OpenSearch Serverless, pgvector on RDS). Common AWS AI infra misconfigurations from the org's own provisioning queue.
• GCP AI infra track, Vertex AI endpoint security (VPC Service Controls, IAM, Private Service Connect); GKE GPU node pool isolation (node taints, namespaces, Workload Identity); Vertex AI Model Registry promotion gate; Cloud KMS for model artifact encryption; Secret Manager for fleet credentials; GCS bucket ACLs for training corpus access scope; Vertex AI Feature Store access control. Common GCP AI infra misconfigurations.
• Azure AI infra track, Azure OpenAI deployment security (managed identity, private endpoints, Azure Policy for no-public-access); Azure ML compute cluster security (managed identity, network isolation, key vault credentials); AKS GPU node pool isolation (node pools, namespaces, pod security admission); Azure Container Registry (ACR) image signing for ML images; Azure AI Search (vector store) network isolation and RBAC; Azure Key Vault for secrets. Common Azure AI infra misconfigurations.
• Each cloud-provider track is paired with the SA-Infrastructure reference architecture for the relevant cloud, the training teaches the "green path" the team will implement and defend in DR.
• Required for any team owning a Critical or High-tier infrastructure instance on the applicable cloud; target ≥1 trained practitioner per archetype instance.

C) Seasonal, behavior-driven shadow-AI-infra campaigns

• Campaigns tied to observed shadow-infra risk windows in the provisioning cycle: large infrastructure provisioning windows (quarter-start GPU reservation cycles), Q1 OKR-planning (teams add AI serving infrastructure to roadmaps without intake), hiring surges (new platform engineers arrive with cloud-account habits from prior employers), post-external-incident moments (a public model-extraction or GPU-credential-leak incident creates a teachable window).
• Each campaign has a pre-measured behavior target (e.g., "reduce untagged GPU workloads in the AWS account by 50% in Q3," "increase Critical-tier inference cluster intake submissions before sprint start by 30%") and a post-campaign measurement.
• Amnesty windows run alongside campaigns; disclosure volume and source attributed to campaign channels.
• Campaign effectiveness reviewed by the program sponsor; campaigns that miss behavior targets by >20% are redesigned.

Outcome Metrics (L2)

Process Metrics (leading)

• Scenario library freshness, scenarios reviewed quarterly; retired when provisioning patterns make them obsolete.
• Cloud-provider training attendance tracked per instance in the inventory monthly.
• Campaign pipeline, always ≥1 campaign in-flight tied to a measurable behavior target.
• Calibration debrief findings routed back to the scenario library within 30 days.

Effectiveness Metrics (business value)

• Reduction in intake submissions missing key risk identifications or SR gaps at first submission (caught earlier as reviewer skill rises, reviewers coach submitters before they reach the queue).
• Cloud-provider-trained teams' infrastructure instances require fewer DR re-submissions vs. untrained teams.
• Sanctioned-IaC-module reuse rate for trained platform teams rises vs. control group (trained teams reach for the reference module; untrained teams write bespoke IaC).

Success Criteria

• Scenario library of ≥30 real-sourced scenarios across archetypes in use; reviewer calibration drift inside target for two consecutive quarters.
• Cloud-provider-specific tracks (AWS / GCP / Azure as applicable) delivered; ≥1 trained practitioner per Critical/High-tier instance.
• ≥2 behavior-driven shadow-AI-infra campaigns run in the last 12 months with measured outcomes.
• Training content refresh cadence met; ≥80% of content updated in last 90 days.

Maturity Level 3

Objective: Operate continuous calibration at scale, externalize the AI infrastructure assurance curriculum and reviewer rubric through CNCF and OpenSSF AI, and contribute to cloud-provider partner programs and emerging AI infrastructure security certification pathways

At this level, the organization's training posture is visible outside its own walls. The practitioner curriculum, scenario library, and reviewer rubric are published externally through CNCF AI/ML Working Group, OpenSSF AI, CNCF TAG Security, or cloud-provider partner programs. The program contributes to emerging AI infrastructure security certification pathways as they solidify. Internally, calibration is continuous and live rather than quarterly.

Dependencies

• EG-Infrastructure L2 (required): scenario library, cloud-provider tracks, and behavior-driven campaigns must be in place.
• PC-Infrastructure L3 (required for regulatory-track content): continuous attestation and policy-refresh infrastructure provides the real compliance scenarios the external curriculum demonstrates.
• SM-Infrastructure L3 (required): automated inventory and tier data feed the continuous calibration exercises with current instance examples.

Desired Outcomes

• External practitioners recognize and use the program's curriculum and rubric; citations and adoption are tracked.
• Reviewer certification exists (internally aligned with external credentials where credentials have emerged, CNCF, OpenSSF, cloud-provider security partner programs) and is held by a majority of the org's Critical-tier infrastructure reviewers.
• Monthly live calibration, reviewers re-calibrated against anonymized real intakes from the live provisioning queue each month; drift trends are a managed metric.
• Training content evolution is auditable and evidence-driven (telemetry from IM-Infrastructure, ML-Infrastructure, and DR-Infrastructure feeds the curriculum rather than annual scheduled reviews).
• MITRE ATLAS TTPs observed in own-operated AI/HAI infrastructure are contributed back as new technique candidates or confirmed technique instances.

Activities

A) Externalize the curriculum, scenario library, and reviewer rubric

• Publish the following under a permissive license or as a consortium deliverable through CNCF AI/ML Working Group, OpenSSF AI supply-chain security, CNCF TAG Security AI guidance, or applicable cloud-provider partner security programs:
• Workforce AI infrastructure literacy module (learning objectives, GPU fleet operational risk module, IaC-for-AI module, region/residency module, observability module, provisioning gate workflow).
• Practitioner role-based training curriculum (module outlines, per-archetype attack surface coverage, IaC review patterns, cloud-provider-specific hardening checklists, ATLAS technique coverage matrix).
• Anonymized scenario library (scenario format, per-archetype examples, calibration debrief format).
• Reviewer rubric (tier-assignment criteria for infra, risk-identification scoring, SR-gap-list completeness scoring for each archetype).
• Community contributions accepted; changes to the external artifact flow back into the internal content within 30 days.
• Adoption tracked: citations in external publications, forks, downloads, direct adoption acknowledgment from other organizations.

B) Continuous live calibration

• Monthly calibration round: a current anonymized infrastructure intake sampled from the program's live provisioning queue is shared with the reviewer cohort; each reviewer independently scores tier, risks, and top 3 SR gaps; drift reported to the program sponsor.
• Individual reviewer drift is a development signal, not a performance metric; reviewers with persistent drift on specific archetype types receive targeted coaching and additional scenario exposure.
• Calibration results feed the scenario library directly, new scenarios drawn from intakes where calibration revealed drift are added within 30 days.

C) AI infrastructure security certification contribution

• Contribute to AI infrastructure and cloud security certification pathways as they emerge: CNCF Kubernetes and cloud-native security certifications (CKS / CKAD AI infra extension), OpenSSF AI Practitioner path, cloud-provider security partner programs (AWS Security Competency AI track, GCP Security Partner AI track, Microsoft MISA AI track), ISACA AI Risk certificates where infrastructure scope is covered.
• Align the org's practitioner capstone with certification-grade rubrics where credentials exist; support reviewers pursuing external credentials.
• Contribute MITRE ATLAS new-technique candidates and confirmed-technique instances from own-operated AI/HAI infrastructure (inference-endpoint extraction, model-registry tampering, orchestrator control-plane compromise enabling EA/TM/RA), minimum 1 per year where novel observations exist.
• Target: ≥2 substantive contributions per year to industry curriculum, certification working groups, or cloud-provider partner security programs.

Outcome Metrics (L3)

Process Metrics (leading)

• Curriculum refresh pipeline: ≥1 change per quarter driven by IM/ML telemetry or external cloud-provider security update.
• Reviewer certification pathway participation tracked per reviewer.
• External outreach: ≥2 CNCF / OpenSSF / cloud-provider security forum engagements per year on AI infrastructure security education topics.
• Calibration debrief findings fed to scenario library within 30 days.

Effectiveness Metrics (business value)

• Talent acquisition, the program is a named draw for platform security and ML platform engineer hires who want to work on AI infrastructure security at a mature organization.
• Reduced on-boarding time for new reviewers who arrive with CNCF / OpenSSF / cloud-provider credentials.
• Industry recognition, program cited by CNCF, OpenSSF, or cloud-provider partner teams as a reference for AI infrastructure security education.
• Internal re-submission rate for infrastructure intakes continues to decline as external curriculum adoption provides pre-trained practitioners from outside the org.

Success Criteria

• Curriculum, scenario library, and reviewer rubric published externally (CNCF / OpenSSF AI / cloud-provider partner programs) with documented adoption.
• Monthly live calibration operating; drift inside target for two consecutive quarters.
• ≥50% of Critical-tier reviewers credentialed where credentials exist (CNCF / OpenSSF / cloud-provider security partner).
• ≥2 substantive contributions to industry certification / curriculum per year.
• ≥1 MITRE ATLAS TTP contribution or confirmation per year where novel observations exist in own-operated AI/HAI infrastructure.

Key Success Indicators

Level 1: - Workforce AI infrastructure literacy module launched; ≥95% current-year completion across platform engineers, SREs, and cloud architects provisioning or operating AI/HAI infrastructure; content tied to the AI Infrastructure Standards AUP attestation. - Practitioner role-based training launched, gated on intake-approval permissions, covering inference-endpoint attack surface (ATLAS AML.T0015/AML.T0024), model-registry supply-chain attacks (ATLAS AML.T0010), GPU-fleet IAM hardening, vector-store hardening (embedding inversion), orchestrator control-plane security (EA/AGH/TM/RA TTPs), AI-specific CI/CD pipeline attacks, and IaC review patterns for all seven archetypes. - Reviewer calibration drift inside target (≤1 tier step and ≤2 risk misclassifications per sample) for two consecutive quarters. - Shadow-AI-infra awareness campaign running with monthly content cadence; amnesty disclosures attributable to campaign channels rising in Q1–Q2 then declining as the sanctioned-archetype catalog grows. - Training content owner named; content updated within 30 days of any change to policies, archetypes, or compliance map.

Level 2: - Scenario library of ≥30 anonymized real-sourced infrastructure intakes powering reviewer training across archetypes; Critical-tier calibration drift inside target. - Cloud-provider-specific engineering tracks (AWS / GCP / Azure) delivered; ≥1 trained practitioner per Critical/High-tier infrastructure instance. - ≥2 behavior-driven shadow-AI-infra campaigns run in the last 12 months with measured outcomes; ≥70% of campaigns hit pre-set behavior target. - Training content refreshed in last 90 days for ≥80% of modules.

Level 3: - Curriculum, scenario library, and reviewer rubric published externally (CNCF / OpenSSF AI / cloud-provider partner programs) with documented adoption or citation. - ≥50% of Critical-tier reviewers hold an external AI infrastructure or cloud security credential (where one exists). - Monthly live calibration operating with drift inside target; calibration results feeding the scenario library continuously. - ≥2 substantive contributions to industry AI infrastructure security certification or curriculum working groups per year; ≥1 MITRE ATLAS contribution or confirmation per year where novel observations exist in own-operated infrastructure.

Common Pitfalls

Level 1: - ❌ Workforce training covers generic cloud hardening (VPC, IAM, encryption) but not the AI infrastructure-specific risks, platform engineers know how to harden an EC2 instance but not how to prevent model extraction from an inference endpoint or embedding inversion from a vector store. - ❌ Practitioner training is a one-hour "intro to ML security" rather than a hands-on module covering per-archetype attack surfaces, IaC review patterns, ATLAS technique coverage, and calibration exercises against real intake examples. - ❌ Reviewer training is optional, intake-approval permissions granted without training completion; calibration drift never measured; two reviewers regularly arrive at different tiers for the same inference cluster. - ❌ Shadow-AI-infra campaign launches once with an exec message, then goes silent, no monthly content, no amnesty attribution, no feedback channel; platform engineers never hear about it again. - ❌ Training is archetype-agnostic, "AI infrastructure security" without distinguishing between an orchestrator (EA/TM/RA control-plane risks) and a vector store (embedding inversion, namespace boundary risks); practitioners apply the wrong threat lens. - ❌ Region/residency micro-content never ships for cross-border inference infrastructure, teams deploy inference endpoints outside the declared region without understanding GDPR Art. 44–49 implications. - ❌ Training content owner is unnamed, content goes stale within a quarter; platform engineers find outdated AUP references and stop trusting the module.

Level 2: - ❌ Scenario library built from invented examples rather than anonymized real infrastructure intakes, reviewers learn the shape of a "good" intake but not the actual misconfigurations the org's platform teams make. - ❌ Cloud-provider tracks are optional; platform teams skip them and then produce IaC in DR that misses cloud-provider-specific AI security controls; DR catches the gaps late and at high cost. - ❌ Campaigns launched without pre-measured behavior targets, "shadow AI infrastructure awareness" claimed as a success without data on whether untagged GPU workloads decreased or amnesty disclosures increased. - ❌ Content "refreshes" are cosmetic, module covers updated, scenario descriptions wordsmithed, but cloud-provider-specific IaC review patterns go stale while actual service APIs and security controls evolve. - ❌ Calibration drift measured but not acted on, reviewers with persistent drift on specific archetype types never receive coaching; the calibration exercise becomes a box-check.

Level 3: - ❌ External publication without ongoing maintenance, other organizations find stale IaC review patterns and ATLAS coverage that no longer reflects current cloud-provider APIs; citations dry up. - ❌ Credentialing becomes performative, reviewers pursue generic cloud security certifications that do not map to the org's AI-infra-specific tier-treatment rubric; credential acquisition celebrated but calibration drift stays unchanged. - ❌ Live calibration becomes a gotcha rather than a development signal, reviewers game the monthly exercise and improve their calibration scores without improving their actual intake quality. - ❌ Contributions to CNCF / OpenSSF working groups do not loop back, what is published externally drifts from what reviewers use internally; practitioners cite the external artifact and contradict the internal rubric. - ❌ ATLAS contributions are aspirational ("we plan to contribute") but never actually submitted, the org observes novel inference-endpoint extraction or orchestrator-compromise patterns in own-operated infrastructure but does not complete the ATLAS submission process.

Practice Maturity Questions

Level 1: 1. Have all platform engineers, SREs, and cloud architects provisioning or operating AI/HAI infrastructure completed a current-year AI infrastructure literacy course covering the seven in-scope archetypes, GPU fleet operational risk, IaC-for-AI differences, region/residency for AI serving infrastructure, observability minimums, and the provisioning gate, with ≥95% completion and content updated within 30 days of any policy or archetype change? 2. Has the practitioner population (platform security engineers, SRE on-call leads, cloud architects performing AI infrastructure reviews) completed role-based training covering inference-endpoint attack surface (ATLAS AML.T0015/AML.T0024), model-registry supply-chain attacks (ATLAS AML.T0010), GPU-fleet IAM hardening, vector-store hardening (embedding inversion), orchestrator control-plane security (EA/AGH/TM/RA TTPs), AI-specific CI/CD attacks, and IaC review patterns for all seven archetypes, with completion gated on intake-approval permissions and calibration drift ≤1 tier step and ≤2 risk misclassifications per sample for two consecutive quarters? 3. Is a shadow-AI-infra awareness campaign running with at least monthly content, a visible amnesty path linked from the AUP and intake form, and measurable attribution of intake submissions and amnesty disclosures to campaign channels, with disclosures rising in Q1–Q2 after launch then declining as the sanctioned-archetype program grows?

Level 2: 1. Is there a scenario library of ≥30 anonymized real infrastructure intake cases powering practitioner training across the org's in-scope archetypes, with paired calibration exercises showing Critical-tier drift ≤1 tier step and ≤1 risk misclassification per sample for two consecutive quarters? 2. Have cloud-provider-specific engineering tracks (AWS / GCP / Azure AI infra as applicable) been delivered to ≥1 practitioner per Critical/High-tier infrastructure instance, with team-level training coverage tracked in the SM-Infrastructure inventory? 3. Are shadow-AI-infra campaigns running on a seasonal, behavior-driven cadence with pre-set behavior targets (not just "awareness") and post-campaign measurement, and is ≥70% of campaigns hitting their target, and is ≥80% of training content updated in the last 90 days?

Level 3: 1. Has the practitioner curriculum, anonymized scenario library, and reviewer rubric been published externally (CNCF, OpenSSF AI, CNCF TAG Security, or cloud-provider partner security programs) with documented adoption, citations, forks, or direct acknowledgment, and do contributions loop back into internal content within 30 days? 2. Is a monthly live calibration cadence operating (anonymized infrastructure intake from the live provisioning queue, independent reviewer scoring, drift reported to sponsor), with calibration results feeding the scenario library within 30 days, and do ≥50% of Critical-tier reviewers hold an external AI infrastructure or cloud security credential where one exists? 3. Does the program contribute ≥2 substantive artifacts per year to industry AI infrastructure security certification or curriculum working groups (CNCF / OpenSSF AI / cloud-provider partner programs), and ≥1 MITRE ATLAS TTP contribution or confirmation per year where novel observations exist in own-operated AI/HAI infrastructure?

Document Version: HAIAMM v3.0 Practice: Education & Guidance (EG) Domain: Infrastructure Last Updated: 2026-05-14 Author: Verifhai