Environment Hardening (EH)

Software Domain - HAIAMM v3.0

Practice Overview

Objective: Harden the compute, build, model-supply-chain, engineering-endpoint, and data-flow envelopes in which AI/HAI software the organization builds is developed, trained, and served, so each artifact runs in a least-privilege, observable perimeter and unsanctioned AI development is detectable before it reaches production.

Description: EH-Software tunes the organization's existing perimeter, identity, and pipeline controls for the specific surfaces that AI/HAI software development creates. The five envelope dimensions are: (1) the compute/runtime envelope around each artifact's service account, secrets, egress, and resource limits; (2) the build-time envelope covering CI/CD secrets management, signed builds, SLSA-style model-artifact provenance, and AI SDK supply-chain scanning; (3) the model-supply-chain envelope governing model registry access control, signed model artifacts, provenance tracking, and deny-listing for known-poisoned upstream weights; (4) the engineering-endpoint envelope enforcing SSO + MFA on the model registry and LLM provider consoles, DLP tuned for AI-specific exfiltration patterns (bulk embeddings, prompt/completion bulk exports, model-weight exfiltration), and browser policy that prevents unsanctioned LLM use on engineer workstations; and (5) the data-flow envelope requiring PII redaction at the prompt/completion logging layer and classification labels carried through training and inference pipelines. At L2, hardening is calibrated per risk tier: Critical artifacts get per-tenant isolation, dedicated VPC, enhanced DLP, and zero-trust AI access; Low artifacts get baseline controls. At L3, all controls are expressed as Terraform / Pulumi IaC modules with adaptive tightening driven by ML-Software detection signals and IM-Software incident patterns.

Context: Engineering teams adopting AI move faster than platform and security teams can follow. An LLM API key ends up hardcoded in a Jupyter notebook committed to the monorepo. A fine-tuning job runs against a training dataset it has no business touching, with no egress constraints. An agent ships with a service account that has org-wide read access "because that's what the demo used." A model-serving endpoint has no version pinning, so when the provider quietly swaps the underlying model family the artifact's behavior regresses without anyone noticing. EH-Software closes these gaps not by adding new tooling but by tuning controls the organization already has, secrets scanning in CI, model registry access control, egress allowlists, SSO enforcement on LLM provider consoles, DLP rules on engineer workstations, for the specific surfaces AI/HAI software development creates.

Maturity Level 1

Objective: Harden the compute/runtime, build-time, model-supply-chain, engineering-endpoint, and data-flow envelopes for all AI/HAI software the organization builds, so each artifact runs in a least-privilege, observable perimeter and AI-specific exfiltration paths are controlled

At this level, existing platform and security controls are AI/HAI-software-aware. Secrets scanning in CI catches LLM provider keys before they reach the repository. Model registry access requires SSO. Egress from AI/HAI service accounts is allowlisted to the declared LLM provider domains. DLP on engineer workstations is tuned for AI-specific exfiltration patterns. Every AI/HAI software artifact in the SM inventory has a named service account, no shared credentials, with least-privilege IAM.

Dependencies

• SM-Software L1 (required): the AI/HAI software inventory and archetype taxonomy identify which artifacts exist and which envelope dimensions apply to each; without the inventory, hardening scope is guesswork.
• PC-Software L1 (required): the AI Acceptable Use & Engineering Standards policy defines what to enforce at the engineering-endpoint and build-time envelope; the AI Engineering Standards policy defines the archetype-level controls the runtime envelope must implement.
• SA-Software L1 (required): reference patterns define the "green path", secrets vault, egress allowlist, service-account model, logging spec, that hardening controls must enable for sanctioned artifacts and detect deviations from for unsanctioned ones.
• Supports / unblocks: ML-Software L1 (the log events and egress signals these controls emit feed monitoring), ST-Software L1 (ST battery tests exercise the hardening controls directly), IM-Software L1 (incidents often originate at control surfaces hardened here).

Desired Outcomes

• Every AI/HAI software artifact in production has a named, least-privilege service account; no shared or overprivileged credentials.
• LLM provider API keys are in a secrets vault; CI secrets scanning actively enforced; hardcoded keys blocked before they reach the main branch.
• Egress from AI/HAI service accounts is allowlisted to declared LLM provider domains; unexpected egress to AI provider domains from unregistered services triggers an alert.
• The model registry requires SSO + MFA; model artifacts carry signed provenance; unauthenticated model promotion is blocked.
• Engineer workstations have DLP rules tuned for AI-specific exfiltration patterns and browser policy that prevents unsanctioned LLM use during work sessions.
• Prompt/completion logs do not store regulated data in clear-text unless required, protected, and documented.

Activities

A) Harden the compute/runtime envelope per artifact

For every AI/HAI software artifact registered in the SM inventory, establish and enforce a minimum runtime hardening baseline:

• Per-artifact service account (not shared): each artifact, LLM-integrated app, agent, RAG pipeline, fine-tuning workload, eval harness, model-serving service, classical ML model, runs under a dedicated service account (IAM role, Kubernetes service account, Workload Identity, or equivalent); no artifact shares credentials with another.
• Least-privilege IAM: the service account has access only to the resources the artifact requires, the specific LLM provider API endpoint, the specific vector store namespace, the specific model registry path, the specific secrets vault path; no wildcard policies; no inherited org-level read.
• Secrets vault for LLM provider API keys: all LLM provider API keys (OpenAI, Anthropic, Bedrock, Vertex, self-hosted OSS endpoints, HuggingFace model-download tokens) are managed in the secrets vault (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, or equivalent); no keys in source code, CI/CD environment variables, container image layers, or plaintext configuration files; confirmed by secrets-scanning CI check on every PR.
• Egress allowlist: each artifact's service account or network namespace has an explicit egress allowlist allowing traffic only to declared LLM provider domains, vector store endpoints, and model registry endpoints; all other outbound traffic is denied or alerted; new undeclared AI provider egress from an existing service triggers a shadow-AI discovery alert.
• Per-tenant isolation for multi-tenant artifacts: artifacts serving multiple tenants enforce per-tenant namespacing at the prompt/context layer and at the vector store; one tenant's prompts, completions, and retrieval context are not accessible to another tenant at rest or in transit.
• Runtime resource limits: GPU/CPU/memory limits set for inference and training workloads; no unbounded GPU jobs from unsanctioned identities; resource-limit enforcement prevents cost-abuse and accidental over-provisioning by unsanctioned workloads.

B) Harden the build-time and model-supply-chain envelopes

• CI/CD secrets management: secrets scanning runs on every PR and every commit to the main branch; any LLM provider API key, HuggingFace token, or model-registry credential detected as a plaintext string blocks the PR. Tools: truffleHog, gitleaks, detect-secrets, or equivalent wired as CI checks.
• Signed builds: build artifacts (container images, Python packages, model artifacts) are signed at build time; downstream consumers verify the signature before deployment; unsigned artifacts are rejected at the deploy gate.
• SLSA-style provenance for model artifacts: model artifacts promoted to the model registry carry a provenance attestation (training data sources, training job identity, eval suite result reference, build system identity); any model promotion without a signed provenance attestation is blocked by the registry access-control policy.
• AI SDK dependency pinning and supply-chain scanning: AI SDK dependencies (openai, anthropic, langchain, llama_index, transformers, vllm, etc.) are version-pinned in all manifest files (requirements.txt, pyproject.toml, package.json, go.mod); a software-composition analysis (SCA) tool runs in CI and alerts on known-vulnerable versions and on new AI SDK imports not yet reviewed by the program. CI blocks on critical SCA findings for Critical/High-tier artifacts.
• Reproducible builds where feasible: training and fine-tuning workloads are configured to produce reproducible outputs from pinned data, pinned model versions, and pinned hyperparameters; reproducibility is a gate for model promotion in the eval harness.

C) Harden the engineering-endpoint and data-flow envelopes

• SSO + MFA on AI/HAI-specific consoles: model registry, LLM provider management consoles (OpenAI org console, Anthropic console, Bedrock console, Vertex AI console), CI/CD, and code repositories all require SSO/SAML/OIDC; local-account access to AI provider admin consoles is disabled for org-domain identities; MFA always enforced.
• DLP tuned for AI-specific exfiltration patterns on engineering endpoints: extend existing DLP rules to cover patterns specific to AI/HAI software development, large embedding exports (bulk vector exports from a vector store to an external destination), prompt/completion bulk exports (CSV/JSON bulk exports of logged prompt/completion pairs), model-weight exfiltration (upload of model checkpoint files to external file-sharing services or consumer cloud storage), and training-dataset exports (bulk export of training data to unmanaged storage). DLP rules alert or block based on data class of the content being exported.
• Browser policy on engineering endpoints: a managed-browser policy prevents engineers from sending work data (source code, internal documents, customer data) to unsanctioned consumer LLM services (personal ChatGPT, personal Claude, personal Gemini) during managed work sessions; browser extensions that act as AI coding assistants are governed by the sanctioned-AI-assistant policy from PC-Software.
• Data-flow envelope, PII redaction at logging: prompt/completion logging pipelines for AI/HAI software artifacts are configured with a PII redaction layer before logs are written to the long-term log store; regulated data classes (PII, PHI, PCI card numbers) are either redacted, tokenized, or stored in a separately-controlled log tier with stricter access controls; the redaction configuration is reviewed quarterly by Privacy/Legal; any artifact logging regulated data in clear-text without Privacy/Legal sign-off is flagged as an open IM finding.
• Classification labels in training and inference pipelines: data classification labels (public, internal, confidential, regulated) are attached to datasets at ingest and carried through ETL, fine-tuning, and inference pipelines; a pipeline that promotes data to a higher-sensitivity context without a classification check is a blocking finding.

Outcome Metrics (L1)

Process Metrics (leading)

• CI secrets-scanning cadence, runs on every PR and every main-branch commit; zero PRs merged without a passing secrets-scan check.
• AI SDK SCA cadence, runs in CI; open critical SCA findings for Critical/High-tier artifacts reviewed and resolved within 7 days.
• Egress allowlist review cadence, monthly; new LLM provider domains added to the allowlist within 5 business days of a new sanctioned provider being added to the SM inventory.
• DLP rule tuning cadence, quarterly review of AI-specific rule false-positive/false-negative rates; tuning changes logged.

Effectiveness Metrics (business value)

• Secrets-in-code incidents trending down after CI secrets-scanning activation, documented cases where hardcoded API keys were caught before reaching the main branch.
• Unsanctioned AI egress events detected and attributed, new AI provider egress from unregistered services caught by the egress alert and routed to SM inventory for intake.
• Frictionless sanctioned adoption, the time-to-productive for engineers using a sanctioned AI/HAI software stack (vault-backed keys, declared egress, signed builds) does not regress as hardening tightens.

Success Criteria

• 100% of AI/HAI software artifacts in production running under a named, dedicated, least-privilege service account; confirmed by SM inventory × IAM audit reconciliation.
• CI secrets-scanning enforced on every PR; zero LLM provider API keys in source code, CI/CD environment variables, or container image layers, confirmed by last secrets-scan run with zero findings.
• Model registry requires SSO + MFA; 100% of Critical/High-tier model promotions carry a signed provenance attestation.
• DLP rules tuned for AI-specific exfiltration patterns deployed and active on ≥95% of managed engineering endpoints.
• PII redaction layer active on prompt/completion logging pipelines for all artifacts processing regulated data; Privacy/Legal sign-off documented where clear-text regulated data is retained.

Maturity Level 2

Objective: Calibrate hardening depth per risk tier using the SM L2 tier-treatment matrix, apply SASE / zero-trust controls for AI access on Critical-tier artifacts, and enforce per-tenant isolation and enhanced DLP at the tier level

At this level, hardening is no longer one-size-fits-all. Critical-tier artifacts get a hardened envelope that would be excessive for Low-tier: dedicated VPC or private link for inference, per-tenant isolation enforced at the infrastructure layer, zero-trust AI access with continuous session validation, and enhanced DLP with content-inspection for prompt/completion patterns. Low-tier artifacts stay on the baseline controls from L1. The tier-treatment matrix drives every hardening decision.

Dependencies

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

Desired Outcomes

• Hardening depth is visibly differentiated: Critical-tier artifacts run in a more constrained, more observable envelope than Low-tier; reviewers and regulators can verify the differentiation from the artifact's configuration record.
• SASE egress per-artifact granularity: each Critical-tier artifact's service account has its own egress policy rather than sharing a service-wide allowlist; policy applies at the workload identity level.
• Per-tenant isolation enforced at the infrastructure layer for Critical-tier multi-tenant artifacts, not just at the application layer.
• Enhanced DLP policies on engineering endpoints for Critical-tier artifact development: content inspection on outbound AI-provider calls from engineer workstations, alert on bulk embeddings or model-weight transfers.
• Zero-trust AI access for Critical-tier: no standing access to the model registry, LLM provider admin consoles, or fine-tuning pipelines; access is granted on-demand, scoped, time-limited, and logged.

Activities

A) Tier-conditional hardening calibration

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

Each downstream artifact record in the SM inventory carries its tier's hardening status; gaps between required and actual controls are open IM findings.

B) SASE egress governance and zero-trust AI access

• SASE per-artifact egress: for Critical-tier artifacts, replace per-service egress allowlists with per-artifact (per-workload-identity) egress rules in the SASE platform; each artifact's service account has its own outbound-traffic policy; unexpected outbound traffic from one artifact does not affect another artifact's allowlist.
• Content-inspection where permissible: for Critical-tier artifact service accounts, enable API-content inspection on outbound calls to LLM provider endpoints where the DPA and provider terms permit; alert on bulk-export patterns (large prompt/completion payloads, embedding batch exports) that exceed the declared operational profile.
• Zero-trust AI access for Critical-tier:
• No standing access to the model registry with write/promote permissions; access is just-in-time, time-limited (≤4 hours), scoped to the specific model artifact, and requires an approval gate before grant.
• No standing access to LLM provider admin consoles (OpenAI org admin, Anthropic console, Bedrock console, Vertex AI console) with billing or API-key management permissions; access via just-in-time mechanism with approval gate and full session audit log.
• Fine-tuning and training pipeline execution requires: identity of the submitter logged, training-data classification pre-flight check passed, and a privacy sign-off reference for any regulated data in scope, all enforced at pipeline submission time, not honor-system.

C) Per-tenant isolation at infrastructure layer and enhanced DLP

• Infrastructure-layer per-tenant isolation for Critical-tier: multi-tenant artifacts at Critical tier must enforce tenant boundaries at the infrastructure level, dedicated namespace or VPC per tenant, or a separate encryption key per tenant in the shared infrastructure; the tenant boundary is verified by the IR-Software implementation review and confirmed by a ST-Software isolation test.
• Enhanced DLP for Critical-tier artifact development:
• Content inspection on engineer workstation outbound traffic to LLM provider domains, prompt/completion pairs exceeding a size threshold trigger a DLP review alert (bulk prompt export detection).
• Model-weight exfiltration detection: alert on any upload of files matching model checkpoint file extensions (.bin, .safetensors, .gguf, .pt, .ckpt) to external destinations from engineering endpoints.
• Embedding export detection: alert on bulk exports of vector embedding files to destinations outside the declared data pipeline.
• Classification-label enforcement in pipelines: enforce that classification labels propagate through all ETL, fine-tuning, and inference pipeline stages; a pipeline stage that drops or downgrades classification labels without explicit policy authorization is a blocking finding.

Outcome Metrics (L2)

Process Metrics (leading)

• SASE / IAM policy drift audit, quarterly; per-artifact egress rule deviations from declared policy are open IM findings within 5 business days.
• Just-in-time access logs reviewed monthly; any access grant exceeding the 4-hour time limit triggers an alert.
• Per-tenant isolation conformance test wired into CI for Critical-tier multi-tenant artifacts (from SA-Software L2 IaC conformance test suite).
• Enhanced DLP review cadence, monthly false-positive/false-negative rate reviewed; tuning changes logged.

Effectiveness Metrics (business value)

• Reduced unsanctioned AI-provider egress volume from Critical-tier artifacts after SASE per-artifact rules enforced.
• Fewer cross-tenant findings in IR reviews for Critical-tier artifacts after infrastructure-layer isolation enforced.
• Insider-risk signal quality, enhanced DLP detection of bulk-embedding and model-weight exfiltration patterns provides the IM team with actionable signals that were previously invisible.

Success Criteria

• 100% of Critical-tier artifacts under per-artifact SASE egress rules with just-in-time model registry and LLM provider admin access.
• ≥90% of Critical-tier multi-tenant artifacts with infrastructure-layer per-tenant isolation confirmed by IR review and ST isolation test.
• Enhanced DLP policies for AI-specific exfiltration patterns active on engineering endpoints for Critical-tier artifact development.
• Tier-hardening matrix published and enforced; SM inventory records show hardening status per tier; gaps are open IM findings.

Maturity Level 3

Objective: Express all EH controls as IaC modules, implement adaptive policy tightening driven by ML-Software detections and IM-Software incidents, and contribute AI/HAI software hardening baselines to industry bodies

At this level, hardening is code. Every EH control, service account configuration, egress policy, secrets management, model registry access policy, DLP rule set, per-tenant isolation module, zero-trust access policy, is expressed as a Terraform or Pulumi module in a version-controlled IaC registry. Drift is detected continuously; low-risk drift is auto-remediated. Adaptive tightening fires when ML-Software detection trends or IM-Software incident patterns signal an emerging risk (e.g., rate-limit tightening when abuse is detected, egress narrowing when shadow AI is discovered). Hardening baselines are contributed to CIS, CSA AI Safety Initiative, and sector ISACs.

Dependencies

• EH-Software L2 (required): SASE per-artifact rules, zero-trust AI access, per-tenant isolation, and enhanced DLP must be operational before automation and adaptive tightening are trustworthy.
• ML-Software L2+ (required): ML detections (prompt-injection attempts, abuse-pattern signals, shadow-AI egress signals) are the upstream source for adaptive policy tightening proposals.
• IM-Software L2+ (required): incident patterns feed adaptive tightening and drive hardening-baseline updates.
• SM-Software L3 (alignment): automated inventory signals trigger auto-provisioning of hardening controls for new artifacts; tier-change signals trigger hardening-profile upgrades.

Desired Outcomes

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

Activities

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

Express every EH-Software control as a version-controlled, forkable IaC module: - Runtime envelope module: Terraform / Pulumi module for per-artifact service account creation, least-privilege IAM policy attachment, egress allowlist rule, resource limits, and secrets vault path provisioning; parameterized by archetype and tier. - Build-time envelope module: CI/CD pipeline template additions for secrets scanning, SCA on AI SDKs, signed-build configuration, and SLSA provenance attestation; encoded as reusable pipeline components (GitHub Actions composite actions, GitLab CI templates, or equivalent). - Model-supply-chain module: model registry access policy module (SSO enforcement, just-in-time access configuration for Critical/High-tier, provenance-attestation requirement), version-pinning enforcement, and signed-model-artifact verification; parameterized by tier. - Engineering-endpoint module: DLP policy configuration (AI-specific rule sets), browser-policy enforcement, managed-endpoint AI-tool allowlist; expressed as configuration-as-code for MDM/EDR, CASB/DLP platforms (Palo Alto Prisma, Zscaler, Netskope, or equivalent). - Data-flow module: PII redaction pipeline configuration, classification-label propagation enforcement rules, regulated-data log tier access policy; expressed as data-pipeline configuration templates.

IaC modules version-pinned; module updates notify consuming artifact teams with a required-remediation flag. A drift-detection pipeline runs hourly against all deployed artifact configurations; findings classified low-risk (configuration noise) are auto-remediated; findings classified high-risk (service account over-permissioning, egress allowlist expansion, MFA disabled on model registry) trigger a human-review alert within 2 business days and an IM-Software finding.

B) Adaptive policy tightening from ML and IM signals

Wire ML-Software detection signals and IM-Software incident patterns to a human-approved adaptive-tightening pipeline: - ML-Software signals: abuse-pattern detection (token-spend spikes from a specific service account indicating prompt-bomb or cost-abuse) → rate-limit tightening proposal for the affected artifact's service account; shadow-AI egress detection (unexpected outbound call to an undeclared AI provider domain from an existing service) → egress-narrowing proposal and SM inventory shadow-AI alert. - IM-Software signals: post-incident review records that identify a hardening gap → hardening-baseline update proposal; Critical-tier incident involving a misconfigured service account → zero-trust access upgrade proposal for affected tier. - Adaptive tightening pipeline: proposals are human-reviewed before deploy (security platform engineer approval); the change log is machine-readable; downstream artifact teams are notified within 24 hours of a tightening change that affects their artifact's hardening profile. - Feedback loop to TA and SR: hardening changes that reflect a new threat pattern are fed back to the TA-Software library as a potential new threat entry and to the SR-Software requirements pack as a potential new requirement, the adaptive loop is bidirectional.

C) Contribute hardening baselines to industry

• Contribute anonymized EH-Software hardening baseline modules to:
• CIS benchmarks for AI workloads, service-account least-privilege, model-registry access control, AI SDK supply-chain scanning standards.
• CSA AI Safety Initiative, compute/runtime and build-time envelope controls.
• Sector ISACs (FS-ISAC, H-ISAC, IT-ISAC AI working groups), sector-relevant hardening patterns for AI/HAI software development environments.
• Target: ≥2 substantive contributions per year; maintained upstream; internal practice aligns with the published external version.
• Auto-provisioning trigger: when a new AI/HAI software artifact is registered in the SM inventory, the IaC automation automatically provisions its tier-appropriate hardening profile within 24 hours, no manual hardening backlog.

Outcome Metrics (L3)

Process Metrics (leading)

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

Effectiveness Metrics (business value)

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

Success Criteria

• ≥90% of EH controls expressed as IaC; drift detected continuously with ≥70% of low-risk drift auto-remediated.
• Adaptive-policy pipeline operational, ML-Software and IM-Software signals generate human-approved policy-tightening proposals on a tracked cadence; change log traceable to source signals.
• New AI/HAI software artifacts auto-provisioned with tier-appropriate hardening within 24 hours of SM inventory registration.
• ≥2 industry hardening baseline contributions per year (CIS AI workloads, CSA AI Safety Initiative, sector ISACs) with documented adoption.
• Quarterly adaptive-policy change log traceable to ML-Software detections and IM-Software incident patterns.

Key Success Indicators

Level 1: - 100% of AI/HAI software artifacts in production running under a named, dedicated, least-privilege service account; no shared credentials; confirmed by SM inventory × IAM audit reconciliation quarterly. - CI secrets-scanning enforced on every PR; zero LLM provider API keys in source code, CI/CD environment variables, or container image layers, confirmed by last secrets-scan run. - Model registry requires SSO + MFA; 100% of Critical/High-tier model promotions carry a signed SLSA-style provenance attestation; unauthenticated promotions blocked. - DLP rules tuned for AI-specific exfiltration patterns (bulk embeddings, prompt/completion bulk exports, model-weight exfiltration) deployed and active on ≥95% of managed engineering endpoints. - PII redaction layer active on prompt/completion logging pipelines for all artifacts processing regulated data; Privacy/Legal sign-off documented where clear-text regulated data is retained.

Level 2: - 100% of Critical-tier artifacts under per-artifact SASE egress rules; just-in-time access (≤4-hour time-limited, approval-gated) enforced for model registry write permissions and LLM provider admin consoles. - ≥90% of Critical-tier multi-tenant artifacts with infrastructure-layer per-tenant isolation confirmed by IR review and ST isolation test. - Enhanced DLP policies for AI-specific exfiltration patterns (content inspection, bulk-embedding and model-weight-transfer alerts) active for Critical-tier artifact development; false-positive rate monitored and trending down. - Tier-hardening matrix published and enforced; every SM inventory artifact record shows its hardening status; gaps are open IM findings.

Level 3: - ≥90% of EH controls expressed as IaC; drift detected continuously; ≥70% of low-risk drift auto-remediated; high-risk drift human-reviewed within 2 business days. - Adaptive-policy pipeline operational with ML-Software and IM-Software signal sources; change log machine-readable and traceable. - New AI/HAI software artifacts auto-provisioned with tier-appropriate hardening within 24 hours of SM inventory registration. - ≥2 industry hardening baseline contributions per year (CIS, CSA, sector ISACs) with documented adoption.

Common Pitfalls

Level 1: - ❌ Service-account policy is "per-team" rather than per-artifact, one service account covers 12 microservices including 3 AI features and 9 classic services; an overprivileged AI feature shares credentials with a high-trust service and no one notices until an incident. - ❌ Secrets scanning declared active but never wired as a blocking CI check, engineers merge PRs with hardcoded API keys because the scan runs as an informational check that produces a report nobody reads. - ❌ Model registry requires SSO on the web console but the API endpoint accepts long-lived service tokens without MFA, attackers pivot through the API endpoint; the SSO enforcement is a UI control, not a policy control. - ❌ Egress allowlist covers LLM provider domains for one service but not for fine-tuning and training workloads that run under a separate pipeline identity, training jobs exfiltrate embeddings to unmonitored destinations because they were never in scope for the egress policy. - ❌ DLP rules are a copy of the generic "sensitive data" template with no AI-specific patterns, bulk prompt/completion exports and model-weight transfers go undetected because the DLP engine does not recognize them. - ❌ PII redaction layer is documented in the design but not deployed, prompt/completion logs for a customer-facing LLM feature contain customer names and email addresses in clear-text; the issue is discovered during an IR review 8 months after launch.

Level 2: - ❌ Per-artifact SASE egress rules created for Critical-tier artifacts but implemented at the service level, not the workload-identity level, multiple artifacts share the same egress rule and an incident in one artifact's context creates noise for all. - ❌ Just-in-time access for model registry declared as policy but the tooling to enforce it is not implemented, engineers continue using standing service tokens; the JIT policy exists on paper only. - ❌ Infrastructure-layer per-tenant isolation documented in architecture but only the application-layer isolation is deployed, tenant A's embeddings are in a shared vector store with only application-level key filtering; a SQL injection at the application layer bypasses the "isolation." - ❌ Enhanced DLP is scoped to web browser traffic but the bulk-embedding exfiltration vector is the CLI or a background Python script, the DLP controls the browser-based surface and misses the programmatic exfiltration path entirely. - ❌ Tier-hardening matrix exists but is never enforced at provisioning, engineers self-provision a Critical-tier artifact with Low-tier baseline controls because the provisioning tooling does not gate on tier.

Level 3: - ❌ IaC coverage declared at ≥90% but the registry counts artifacts that have an IaC stub, not artifacts whose IaC is the authoritative deployed source, drift accumulates between the stub and the live config; the auto-remediation pipeline fires on the stub's expected state, not the real deployed state. - ❌ Adaptive-policy pipeline wired to ML-Software detections but not to IM-Software incidents, post-breach hardening opportunities (where an IR review identified a hardening gap) are never converted to tightening proposals. - ❌ Industry hardening baselines contributed but not maintained upstream; internal practice advances while the published baseline ages; external adopters find the published version conflicts with advice from the program's engineers at conferences. - ❌ Auto-provisioning trigger fires but uses the previous tier assignment; a Medium→Critical tier upgrade is reflected in the SM inventory 24 hours after the upgrade but the hardening profile is not updated because the provisioning pipeline reads a stale tier field. - ❌ Drift auto-remediation for low-risk findings runs without a change log visible to the network and identity teams, they observe unexpected configuration resets with no traceable source; they disable the auto-remediation rather than fix the sensitivity.

Practice Maturity Questions

Level 1: 1. Does every AI/HAI software artifact in the SM inventory (across all seven archetypes) run under a named, dedicated, least-privilege service account, confirmed by a quarterly IAM audit reconciliation, and are all LLM provider API keys and model-registry credentials managed via a secrets vault with CI secrets-scanning enforced as a blocking PR check with zero current findings? 2. Does the model registry require SSO + MFA for all access, with 100% of Critical/High-tier model promotions gated by a signed SLSA-style provenance attestation, and is there an egress allowlist for each AI/HAI service account scoped to declared LLM provider and model registry domains, with unexpected AI-provider egress from unregistered services triggering a shadow-AI discovery alert? 3. Are DLP rules tuned for AI-specific exfiltration patterns (bulk embeddings, prompt/completion bulk exports, model-weight exfiltration) active on ≥95% of managed engineering endpoints, and are prompt/completion logging pipelines for artifacts processing regulated data configured with a PII redaction layer, with Privacy/Legal sign-off documented where clear-text regulated data is retained?

Level 2: 1. Are 100% of Critical-tier AI/HAI software artifacts under per-artifact SASE egress rules (not per-service) at the workload-identity level, and is just-in-time access (≤4-hour time-limited, approval-gated) enforced for model registry write permissions and LLM provider admin console access, with standing service tokens deprecated for Critical-tier? 2. Are ≥90% of Critical-tier multi-tenant AI/HAI software artifacts enforcing per-tenant isolation at the infrastructure layer (dedicated namespace, VPC endpoint, or per-tenant encryption key), confirmed by IR-Software implementation reviews and ST-Software isolation tests, and is a hardening tier-treatment matrix published and enforced at provisioning with gaps tracked as open IM findings? 3. Are enhanced DLP policies for AI-specific exfiltration patterns (content inspection on outbound AI-provider calls, bulk-embedding and model-weight-transfer alerts) active for Critical-tier artifact development on engineering endpoints, with false-positive rates actively monitored and trending down through monthly review cadences?

Level 3: 1. Are ≥90% of EH controls expressed as authoritative IaC (not stubs) in a version-controlled IaC registry, with drift detected continuously and ≥70% of low-risk drift auto-remediated, with a machine-readable change log visible to downstream network and identity teams, and high-risk drift human-reviewed within 2 business days? 2. Is the adaptive-policy pipeline operational, with ML-Software detections and IM-Software incidents generating human-approved policy-tightening proposals on a tracked cadence, every change traceable to a source signal, and downstream artifact teams notified within 24 hours of a tightening change affecting their artifact's hardening profile? 3. Does the program contribute ≥2 AI/HAI software hardening baselines per year to industry bodies (CIS AI workloads, CSA AI Safety Initiative, sector ISACs) with documented adoption, and are new AI/HAI software artifacts auto-provisioned with their tier-appropriate hardening profile within 24 hours of SM inventory registration?

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