Environment Hardening (EH)

Endpoints Domain - HAIAMM v3.0

Practice Overview

Objective: Harden the identity, endpoint-runtime, data-flow, mobile/edge integrity, and customer-facing envelopes that surround every AI/HAI-enabled endpoint and user-facing AI interface the organization deploys or offers, so sanctioned AI use is frictionless, unsanctioned use is observable, and regulated data cannot silently transit unapproved AI surfaces.

Description: EH-Endpoints tunes the organization's existing MDM, DLP, browser policy, SaaS-admin governance, and identity controls for the specific surfaces that seven AI/HAI endpoint archetypes create: (1) AI assistant / copilot on managed endpoint; (2) browser-based AI tool; (3) chatbot / conversational UI; (4) multi-modal AI interface; (5) AI-augmented productivity (SaaS-AI on endpoint); (6) mobile AI app; (7) edge AI device. Five envelope dimensions are in scope: the identity envelope (SSO, MFA, managed-endpoint requirement, conditional access by device posture); the endpoint-runtime envelope (MDM-enforced AI-tool allowlist, DLP tuned for AI-specific exfiltration patterns, EDR signatures, browser policy, SaaS-admin AI-feature governance); the data-flow envelope (classification-aware egress, no-train flag verification, per-archetype data-class boundaries); the mobile/edge integrity envelope (signed app and model, signed firmware, on-device model integrity attestation, secure enclave, physical-tamper detection); and the customer-facing envelope (rate-limit and abuse-detection, EU AI Act Art. 50 disclosure UX, escalation-to-human routing, brand-safety filter). At L2, hardening is calibrated per the SM-Endpoints risk tier (Critical / High / Medium / Low). At L3, all controls are expressed as MDM / browser-policy / SaaS-admin IaC with adaptive tightening driven by ML-Endpoints detections and IM-Endpoints incident patterns.

Context: AI/HAI endpoints accumulate risks that classic endpoint management was not designed to address. An employee pastes regulated PII into a consumer GenAI in a browser tab because the DLP rule matches credit-card numbers, not LLM prompt text. A chatbot shipped without an EU AI Act Art. 50 disclosure UX ships to customers. A SaaS vendor silently enables an AI-summarization feature tenant-wide; the feature ingests emails including customer contracts, and nobody noticed because SaaS-admin governance did not cover AI-feature enablement. A mobile AI app performs on-device inference with an unsigned model that has been quietly swapped. An edge AI device is physically tampered with and continues to operate with a compromised firmware. EH-Endpoints closes these gaps not by adding new tooling but by tuning what the organization already has, MDM, DLP, browser policy, SaaS admin, identity, for the seven endpoint archetypes.

Maturity Level 1

Objective: Harden the five envelope dimensions for all seven AI/HAI endpoint archetypes so each endpoint type operates under a baseline that prevents the most dangerous data-egress, identity, and integrity failures

At this level, every AI/HAI-enabled endpoint archetype in the SM-Endpoints inventory has a named baseline control set. SSO and MFA are enforced on AI consoles accessed from managed endpoints. MDM enforces an AI-tool allowlist. DLP is tuned for AI-specific exfiltration patterns. Customer-facing chatbots display EU AI Act Art. 50 disclosures. Mobile apps ship with signed models. Edge devices ship with signed firmware and integrity attestation. Regulated data cannot flow to unapproved AI surfaces without triggering a detection.

Dependencies

• SM-Endpoints L1 (required): the AI/HAI endpoint inventory and archetype taxonomy identify which endpoint types exist and which envelope dimensions apply to each; without the inventory, hardening scope is guesswork.
• PC-Endpoints L1 (required): the AI Acceptable Use Policy and Endpoint AI Standards define what to enforce at the identity and endpoint-runtime envelopes; the priority compliance map anchors EU AI Act Art. 50 disclosure requirements and GDPR Art. 32 security obligations.
• SA-Endpoints L1 (required): reference patterns define the "green path", MDM policy, DLP rule set, browser extension allowlist, SaaS-admin AI-governance checklist, that hardening controls must enable for sanctioned archetypes and detect deviations from for unsanctioned use.
• Supports / unblocks: ML-Endpoints L1 (the access, DLP-decision, and attestation signals these controls emit feed monitoring); ST-Endpoints L1 (tests exercise the hardening controls directly); IM-Endpoints L1 (endpoint incidents originate at the control surfaces hardened here).

Desired Outcomes

• Every AI/HAI endpoint archetype in production operates under a named baseline hardening status recorded in the SM-Endpoints inventory; no archetype is unclassified.
• SSO and MFA are enforced for all AI consoles and AI-provider administrative interfaces accessed from managed endpoints; personal-account access to org-data AI surfaces is prohibited by policy and by conditional-access rule.
• MDM enforces an AI-tool allowlist on all managed endpoints; unauthorized AI tools are blocked or detected; SaaS-admin AI-feature enablement requires intake approval before tenant-wide activation.
• DLP is tuned for AI-specific exfiltration patterns, regulated-PII paste into LLM prompts, bulk customer-data export via AI assistant, source-code paste outside the approved coding assistant, on all managed endpoints and managed browsers.
• Every customer-facing chatbot and conversational UI displays a compliant EU AI Act Art. 50 AI-interaction disclosure before or at the start of the interaction; escalation-to-human routing is operational.
• Mobile AI apps ship with signed apps and signed local models; edge AI devices ship with signed firmware and boot-time integrity attestation.

Activities

A) Harden the identity and endpoint-runtime envelopes

For every AI/HAI endpoint archetype registered in the SM-Endpoints inventory, establish and enforce the minimum identity and endpoint-runtime baseline:

• Identity envelope:
• SSO + MFA enforced on all AI consoles accessed from managed endpoints: AI provider management consoles (OpenAI, Anthropic, Gemini, Copilot, SaaS-AI admin), internal AI assistant admin consoles, edge device management consoles; local-account access disabled for org-domain identities; conditional access policy requires managed-device posture (MDM-enrolled, compliant) before granting access to AI console sessions.
• Personal-account prohibition for org data: browser policy and DLP rule prevent employees from authenticating to consumer AI services (personal ChatGPT, personal Claude, personal Gemini) with a personal account while org data is present in the browsing context; org-issued AI service accounts are the only sanctioned credential path.

• Managed-endpoint requirement for Critical AI use: Critical-tier AI assistant and copilot use (access to regulated data via AI, coding assistant with source-code scope) is restricted to MDM-enrolled, compliant managed endpoints; unmanaged devices cannot access Critical-tier AI surfaces.

• Endpoint-runtime envelope:

• MDM-enforced AI-tool allowlist: the MDM platform (Intune, Jamf, VMware Workspace ONE, or equivalent) enforces an application allowlist that permits only approved AI tools and blocks installation or execution of unsanctioned AI applications; the allowlist is governed by the SM-Endpoints intake process.
• DLP tuned for AI-specific exfiltration patterns: extend existing DLP rules to cover patterns specific to AI/HAI endpoint use, regulated-PII paste into LLM prompt fields (web and API contexts), bulk customer-data export via AI assistant (large structured exports via conversational interface), source-code paste outside the approved coding assistant (detected by file-type and content heuristics in the DLP engine), and bulk personal-data queries via AI assistant. DLP rules alert or block based on data class.
• EDR signatures for AI-data-exfiltration patterns: configure EDR (CrowdStrike, SentinelOne, Microsoft Defender, or equivalent) with process-behavior signatures tuned to AI-data-exfiltration patterns, LLM-client-process network connections to unapproved AI provider endpoints, bulk file upload from a system to an AI API endpoint, browser-extension process accessing sensitive local files and initiating AI provider API calls.
• Browser policy and extension allowlist: managed-browser policy (Chrome Enterprise, Edge Enterprise, or equivalent) restricts AI browser extensions to the approved allowlist; unapproved AI browser extensions are blocked at the browser policy layer; the allowlist is reviewed quarterly with the SM-Endpoints working group.
• SaaS-admin AI-feature governance: before a vendor AI feature (Notion AI, Slack AI, Zoom AI Companion, M365 Copilot, Salesforce Einstein, or equivalent) is enabled tenant-wide, it must pass through the SM-Endpoints intake; the SaaS admin console reflects only approved AI features; any AI feature found active without intake approval is a shadow-AI finding routed to IM-Endpoints.

B) Harden the data-flow envelope

• Classification-aware egress: regulated data (PII, PHI, PCI card numbers, classified source code) cannot flow to a no-train-unverified AI surface; DLP policy enforces the boundary by data class; vendor no-train flags for all sanctioned AI tools are verified at intake via IR-Endpoints review and recurrently (at minimum annually) thereafter; any AI tool whose no-train status cannot be confirmed is classified as unverified and regulated data routing to it is blocked.
• Per-archetype data-class boundaries: each of the seven endpoint archetypes has a declared data-class boundary, the maximum classification of data it may process, recorded in the SM-Endpoints inventory; the DLP policy enforces that boundary; boundary violations are routed to IM-Endpoints.
• Vendor no-train flag verified recurrently: for every sanctioned AI endpoint tool, the vendor's no-train commitment (contractual and technical) is confirmed at intake and at the annual IR-Endpoints review; confirmation is documented in the SM-Endpoints inventory record; tools where the no-train flag cannot be technically verified carry a compensating-control flag requiring an additional DLP rule that blocks regulated-data classes from the tool's endpoint surface.

C) Harden the mobile/edge integrity and customer-facing envelopes

• Mobile/edge integrity envelope:
• Signed app and signed local model: mobile AI apps distributed to managed devices are code-signed; local on-device models bundled with or downloaded by mobile AI apps carry a cryptographic signature verified at app launch; unsigned models are rejected; the app store distribution path is restricted to the enterprise mobile app store or approved public stores only.
• Signed firmware on edge AI devices: edge AI devices managed by the org ship with signed firmware; the firmware signing certificate is managed in the secrets vault; unsigned firmware is rejected at the boot sequence by the device's secure boot policy.
• On-device model integrity attestation: at each boot or model-load event, the edge device and mobile AI app perform an integrity check of the local model against a reference hash registered in the SM-Endpoints inventory; integrity failure is reported to the MDM platform and to ML-Endpoints as an alert event.
• Secure enclave for sensitive operations: mobile AI apps that process regulated data use the device's secure enclave (iOS Secure Enclave, Android StrongBox) for key storage and sensitive-operation execution; plain-memory storage of encryption keys on mobile AI apps processing regulated data is a blocking finding.

• Physical-tamper detection for edge: edge AI devices in physically accessible environments are configured with hardware-tamper detection (TPM attestation, sealed PCR values, or vendor-equivalent); tamper events trigger an alert to IM-Endpoints and MDM quarantine action.

• Customer-facing envelope:

• Rate-limit and abuse-detection on customer-facing chatbots and AI interfaces: all customer-facing chatbot and conversational UI endpoints enforce rate limits per session, per user, and per IP range; abuse-detection rules (jailbreak attempt patterns, prompt injection signatures, unusual volume) are active; detection events route to ML-Endpoints.
• EU AI Act Art. 50 disclosure UX templates centrally managed: a centrally managed, legally reviewed disclosure template library covers all seven endpoint archetypes with a customer-facing component; the applicable template is rendered before or at the start of every customer AI interaction; the rendering is verified by automated test in the ST-Endpoints test battery.
• Escalation-to-human routing: every customer-facing conversational AI interface has a documented escalation-to-human path; the escalation trigger conditions (regulatory-adjacent questions, complaint expressions, explicit human-request) are tested in the ST-Endpoints battery; escalation is logged as an ML-Endpoints event.
• Brand-safety filter: customer-facing chatbot and multi-modal AI interface outputs are filtered against a brand-safety ruleset (harmful content, off-topic material, reputationally risky outputs) before delivery to the customer; the filter configuration is reviewed quarterly by the Legal and Brand teams.

Outcome Metrics (L1)

Process Metrics (leading)

• MDM AI-tool allowlist review cadence, quarterly; new AI tool requests assessed within 5 business days of submission to SM-Endpoints intake.
• DLP AI-specific rule false-positive review cadence, monthly; tuning changes logged.
• Browser extension allowlist review cadence, quarterly; unapproved extensions discovered in telemetry routed to IM-Endpoints within 2 business days.
• SaaS-admin AI-feature governance sweep, monthly; AI features active in SaaS admin consoles reconciled against the SM-Endpoints approved list; shadow-AI features blocked within 5 business days of discovery.
• Vendor no-train flag recurrent verification cadence, annual per tool; tools approaching annual review date flagged 30 days in advance.

Effectiveness Metrics (business value)

• Regulated-data-to-unapproved-AI incidents trending down after DLP AI-specific rules activated, documented blocks where regulated PII was prevented from reaching an unapproved AI surface.
• Shadow-AI-in-SaaS findings trending down as SaaS-admin governance matures, AI features caught before tenant-wide activation versus after.
• Customer-facing AI compliance incidents avoided, EU AI Act Art. 50 disclosure coverage confirmed by test, with zero disclosure-suppression incidents in the last 90 days.

Success Criteria

• 100% of AI/HAI endpoint archetypes in the SM-Endpoints inventory have a named baseline hardening status; no archetype is unclassified.
• MDM-enforced AI-tool allowlist active on ≥95% of managed endpoints; DLP rules tuned for AI-specific exfiltration patterns deployed and active.
• SSO + MFA enforced on all AI consoles from managed endpoints; personal-account prohibition active via policy and conditional-access rule; managed-endpoint requirement enforced for Critical-tier AI assistant use.
• 100% of customer-facing chatbots and conversational UIs display a compliant EU AI Act Art. 50 disclosure; escalation-to-human routing operational and tested.
• 100% of mobile AI apps ship with signed app and signed local model verified at launch; 100% of managed edge AI devices ship with signed firmware and boot-time integrity attestation.
• Vendor no-train flag confirmed at intake for all sanctioned AI endpoint tools; annual recurrent verification schedule in place.

Maturity Level 2

Objective: Calibrate hardening depth per SM-Endpoints L2 risk tier; apply dedicated rate-limiting for Critical customer-facing endpoints, mandatory managed-endpoint enforcement for Critical AI assistant use, and HSM-backed attestation for Critical edge devices; and enforce SaaS-admin governance at policy-as-code depth

At this level, hardening is no longer one-size-fits-all. Critical-tier customer-facing endpoints receive dedicated rate-limit rules and abuse-detection profiles not shared with other tiers. Critical AI assistant use is restricted to MDM-enrolled managed endpoints by conditional-access enforcement at the identity layer. Critical edge devices use HSM-backed attestation rather than software-only TPM. Medium and Low-tier archetypes remain on the L1 baseline. The tier-treatment matrix from SM-Endpoints L2 drives every hardening decision.

Dependencies

• EH-Endpoints L1 (required): the five-envelope baseline controls are the substrate L2 tier calibration differentiates.
• SM-Endpoints L2 (required): the risk-tier rubric (Critical / High / Medium / Low) and tier-treatment matrix determine which hardening depth applies to each endpoint archetype; without tier assignments, per-tier calibration has no substrate.
• SA-Endpoints L2 (required): tier-conditional reference patterns define the "green path" for hardened Critical and High-tier endpoint architectures; EH-Endpoints L2 enforces those patterns at the MDM / browser-policy / SaaS-admin layer.
• Supports / unblocks: ML-Endpoints L2 (enhanced identity signals and DLP decisions at Critical tier feed tier-calibrated monitoring); IM-Endpoints L2 (tier-calibrated incident response depends on tier-calibrated hardening for containment speed and blast-radius assessment).

Desired Outcomes

• Hardening depth is visibly differentiated: Critical-tier endpoint archetypes operate under tighter, more observable controls than Low-tier; reviewers and regulators can verify the differentiation from the SM-Endpoints inventory record.
• Critical customer-facing chatbots and multi-modal AI interfaces have dedicated rate-limit and abuse-detection profiles that do not share capacity or threshold tables with lower-tier endpoints; abuse spikes on a Critical customer-facing endpoint do not silently degrade another tier's protection.
• Critical AI assistant use on managed endpoints enforces managed-endpoint requirement at the conditional-access layer (not honor-system); unmanaged-device access to Critical-tier AI surfaces is blocked by identity policy, not only by MDM policy.
• Critical edge devices use HSM-backed attestation; software-only TPM attestation is not sufficient for Critical-tier edge AI devices at L2.
• SaaS-admin AI-feature governance is enforced as MDM / browser-policy / SaaS-admin IaC configuration rather than documented process only.

Activities

A) Tier-conditional hardening calibration

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

Each endpoint archetype record in the SM-Endpoints inventory carries its tier's hardening status; gaps between required and actual controls are open IM-Endpoints findings with an SLA matching the archetype's tier.

B) Critical customer-facing endpoint hardening and managed-endpoint enforcement

• Dedicated rate-limit for Critical customer-facing endpoints: for every Critical-tier chatbot, conversational UI, and multi-modal AI interface, provision a dedicated rate-limit configuration (not shared with non-Critical tiers) covering: per-session message rate, per-user daily token budget, per-IP connection rate, and per-tenant-segment cumulative volume; rate-limit thresholds are reviewed quarterly against actual traffic baselines and adjusted before abuse patterns can destabilize the endpoint.
• Dedicated abuse-detection for Critical customer-facing endpoints: jailbreak-attempt detection, prompt-injection-pattern matching, and volume-anomaly detection are configured as dedicated detection rules for each Critical-tier customer-facing endpoint; detection alerts route to ML-Endpoints within 1 minute of trigger; false-positive threshold reviewed monthly.
• Managed-endpoint mandatory for Critical AI assistant use at the identity layer: for Critical-tier AI assistant and copilot endpoints that can access regulated data or perform consequential actions, conditional-access policy at the IdP layer (Azure AD Conditional Access, Okta Device Trust, Google BeyondCorp, or equivalent) enforces MDM-enrolled, MDM-compliant device posture before granting the session; the enforcement is an identity-layer control, not only an MDM policy control; gaps between the MDM policy and the identity-layer enforcement are identified and closed.

C) HSM-backed attestation for Critical edge devices and SaaS-admin IaC

• HSM-backed attestation for Critical-tier edge AI devices: Critical-tier edge AI devices use an HSM (hardware security module embedded in the device, TPM 2.0 backed by HSM, or vendor-equivalent secure element) as the root of trust for boot-time attestation; attestation keys are generated and stored in the HSM and are non-exportable; the remote attestation service verifies the sealed PCR values at each boot; attestation failures route to IM-Endpoints within 5 minutes.
• Physical-tamper detection with HSM seal: Critical-tier edge device HSM seals the system state; any physical attempt to access the device internals triggers an HSM-detected tamper event; the tamper event routes to IM-Endpoints and initiates remote-disable if the device is network-accessible.
• SaaS-admin AI-feature governance as IaC: SaaS-admin AI-feature configuration (approved features, approved scopes, tenant-wide enablement flags) is expressed as configuration-as-code (SaaS admin API scripts, Terraform SaaS provider modules, or equivalent) and stored in version-controlled configuration management; any deviation between the declared IaC configuration and the live SaaS admin console state is detected at the next daily drift check and routed to IM-Endpoints; new AI-feature enablement requests trigger a pull-request workflow against the IaC repository, not an ad hoc admin console change.

Outcome Metrics (L2)

Process Metrics (leading)

• Critical-tier rate-limit threshold review cadence, quarterly against traffic baseline; deviations from declared threshold are IM-Endpoints findings within 5 business days.
• Conditional-access policy drift audit, monthly; unmanaged-device sessions reaching Critical-tier AI surfaces are immediate IM-Endpoints findings.
• HSM attestation failure response cadence, Critical-tier edge device attestation failure receives IM-Endpoints triage within 1 hour; device remote-disable confirmed within 4 hours of unresolved failure.
• SaaS-admin IaC drift queue, daily drift detection; open high-risk drift findings human-reviewed within 2 business days; low-risk within 5 business days.

Effectiveness Metrics (business value)

• Reduced regulated-data egress to unapproved AI surfaces via managed-endpoint enforcement, documented blocks where identity-layer conditional access prevented unmanaged-device AI access.
• Critical customer-facing abuse incidents caught by dedicated detection before customer impact, detection events that triggered containment before brand or regulatory exposure.
• Edge device integrity failures detected and contained before downstream AI output corruption, documented tamper-detection events and response time.

Success Criteria

• 100% of Critical-tier AI assistant endpoints enforce managed-endpoint requirement at the identity-layer conditional-access policy; gaps between MDM policy and identity-layer enforcement closed.
• 100% of Critical-tier customer-facing AI endpoints have dedicated rate-limit and abuse-detection profiles; profiles reviewed quarterly against traffic baselines.
• 100% of Critical-tier edge AI devices with HSM-backed attestation and physical-tamper detection; attestation failures route to IM-Endpoints within 5 minutes.
• SaaS-admin AI-feature configuration expressed as IaC for Critical and High-tier SaaS-AI; daily drift detection active; deviations trigger IM-Endpoints findings.
• Tier-hardening matrix published and enforced; SM-Endpoints inventory records show hardening status per tier; gaps are open IM-Endpoints findings.

Maturity Level 3

Objective: Express all EH-Endpoints controls as MDM / browser-policy / SaaS-admin IaC modules; implement adaptive tightening driven by ML-Endpoints detections and IM-Endpoints incidents; and contribute AI/HAI endpoint hardening baselines to CSA, OWASP MASVS, and sector ISACs

At this level, hardening is code. Every EH-Endpoints control, MDM AI-tool allowlist, browser policy, SaaS-admin AI-feature configuration, DLP rule set, rate-limit configuration, edge attestation policy, is expressed as a version-controlled IaC module. Drift is detected continuously; low-risk drift is auto-remediated. Adaptive tightening fires when ML-Endpoints detection trends or IM-Endpoints incident patterns signal an emerging risk. Hardening baselines are contributed to CSA AI Safety Initiative, OWASP MASVS, and sector ISACs.

Dependencies

• EH-Endpoints L2 (required): tier-conditional hardening, dedicated rate-limit and abuse-detection for Critical customer-facing endpoints, HSM-backed edge attestation, and SaaS-admin IaC must be operational before automation and adaptive tightening are trustworthy.
• ML-Endpoints L2+ (required): ML-Endpoints detections (regulated-data paste blocks, abuse-pattern detection, edge-device integrity failures, SaaS-AI shadow-enablement) are the upstream source for adaptive policy-tightening proposals.
• IM-Endpoints L2+ (required): incident patterns from post-incident reviews feed adaptive tightening proposals and drive hardening-baseline updates.
• SM-Endpoints L3 (alignment): automated inventory signals trigger auto-provisioning of hardening controls for new endpoint archetypes; tier-change signals trigger hardening-profile upgrades.

Desired Outcomes

• All EH-Endpoints controls are reviewable as code; a security engineer can open the IaC registry and understand exactly what hardening applies to any endpoint archetype without reading an MDM, browser-policy, or SaaS admin 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-Endpoints detection trend ID or IM-Endpoints incident ID), a human-approval record, and a downstream notification to affected endpoint and product teams.
• AI/HAI endpoint hardening baselines published by this program are adopted by at least one industry body (CSA, OWASP MASVS, or a sector ISAC).
• New AI/HAI endpoint archetypes are automatically provisioned with their tier-appropriate hardening profile at archetype registration in the SM-Endpoints inventory, not retroactively after an IR or IM finding.

Activities

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

Express every EH-Endpoints control as a version-controlled, forkable IaC module parameterized by archetype and tier:

• Identity envelope module: IdP conditional-access policy module (managed-endpoint device-posture requirement, MFA enforcement, personal-account prohibition rule, AI-console session scope); parameterized by archetype and tier; applied at the IdP configuration layer (Azure AD, Okta, Google Workspace, or equivalent policy API).
• Endpoint-runtime module: MDM configuration profile module (AI-tool allowlist policy, app blocking policy, browser extension allowlist, screen-capture policy for AI sessions); expressed as MDM configuration profiles deployable via Intune, Jamf, or equivalent MDM API; DLP rule configuration module (AI-specific rule sets, content-inspection policies for Critical tier); browser policy configuration module (Chrome Enterprise / Edge Enterprise policy templates).
• Data-flow module: DLP egress-rule configuration for per-archetype data-class boundaries; vendor no-train flag verification schedule and alert rule; classification-aware routing policy configuration.
• Mobile/edge integrity module: mobile app signing policy configuration; local-model hash registry and launch-time attestation rule; edge device attestation policy (HSM configuration, sealed PCR value registry, tamper-alert routing rule); expressed as device-management configuration templates deployable via MDM API and edge device management console API.
• Customer-facing module: rate-limit configuration module (per-archetype, per-tier, parameterized threshold table); abuse-detection rule module (jailbreak and prompt-injection pattern library, volume-anomaly threshold); EU AI Act Art. 50 disclosure template registry (version-controlled, Legal-reviewed, per-archetype); brand-safety filter configuration.

IaC modules version-pinned; module updates notify consuming endpoint and product teams with a required-remediation flag. A drift-detection pipeline runs daily against all deployed endpoint configurations; low-risk drift (allowlist entry noise) is auto-remediated; high-risk drift (MFA disabled on AI console, rate-limit removed from Critical-tier chatbot, edge attestation policy deleted) triggers a human-review alert within 2 business days and an IM-Endpoints finding.

B) Adaptive policy tightening from ML-Endpoints and IM-Endpoints signals

Wire ML-Endpoints detection signals and IM-Endpoints incident patterns to a human-approved adaptive-tightening pipeline:

• ML-Endpoints signals:
• Regulated-data paste-attempt volume spike → DLP rule sensitivity increase proposal for the affected archetype.
• Customer-facing chatbot abuse-pattern detection (jailbreak attempts at scale) → rate-limit tightening proposal and prompt-injection corpus update proposal for the affected endpoint.
• SaaS-AI feature silently enabled (shadow-AI-in-SaaS detection) → SaaS-admin IaC rollback proposal and intake-amnesty trigger.
• Edge-device integrity failure rate above threshold → attestation policy tightening proposal (e.g., reduce attestation interval, require additional PCR sealing).
• Mobile-app local-model integrity failure cluster → model signing re-pin proposal and MDM force-update trigger proposal.
• IM-Endpoints signals: post-incident review records that identify a hardening gap → hardening-baseline update proposal; Critical-tier incident involving a DLP bypass → DLP rule tuning proposal with IM incident reference.
• Adaptive tightening pipeline: proposals are human-reviewed before deploy (security platform engineer approval); the change log is machine-readable; downstream endpoint and product teams are notified within 24 hours of a tightening change that affects their archetype's hardening profile.
• Feedback loop to TA-Endpoints and SR-Endpoints: hardening changes that reflect a new threat pattern are fed back to the TA-Endpoints threat library and to the SR-Endpoints requirements pack as potential new requirements.

C) Contribute hardening baselines to industry

• Contribute anonymized EH-Endpoints hardening baseline modules to:
• CSA AI Safety Initiative, AI endpoint allowlist governance, DLP AI-specific pattern library, SaaS-AI feature governance baseline, EU AI Act Art. 50 disclosure UX template standards.
• OWASP MASVS (Mobile Application Security Verification Standard), mobile AI app signing and local-model integrity attestation controls; on-device model integrity verification requirements; secure enclave usage for sensitive AI operations.
• Sector ISACs (FS-ISAC, H-ISAC, IT-ISAC AI working groups), sector-relevant hardening patterns for AI/HAI endpoint use (BYOD AI governance in financial services, mobile AI app controls in healthcare, edge AI device hardening in critical infrastructure).
• Target: ≥2 substantive contributions per year; maintained upstream; internal practice aligns with the published external version.
• Auto-provisioning trigger: when a new AI/HAI endpoint archetype is registered in the SM-Endpoints inventory, the IaC automation automatically provisions its tier-appropriate hardening profile (MDM policy, DLP rules, browser policy, rate-limit configuration) within 24 hours of registration.

Outcome Metrics (L3)

Process Metrics (leading)

• IaC coverage growth rate, % of EH-Endpoints controls migrated to IaC month-over-month; target ≥90% before the quarter closes.
• Adaptive-policy pipeline freshness, ML-Endpoints and IM-Endpoints signal feeds checked weekly; stale feeds (>7 days without a processed event) flagged.
• Industry contribution pipeline, ≥1 hardening artifact (CSA contribution, OWASP MASVS PR, 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 endpoint hardening-configuration change drop quarter-over-quarter as IaC and adaptive-policy automation absorb manual review cycles.
• External recognition, CSA, OWASP MASVS, or sector ISAC adoption of contributed AI/HAI endpoint hardening baselines; citations in sector publications.
• Time-to-hardened for new AI/HAI endpoint archetypes decreases from "days after IR review" to "hours after SM-Endpoints registration" as auto-provisioning operates.
• Incident rate on IaC-encoded endpoint deployments lower than on hand-configured deployments, tracked as a rolling 12-month comparison.

Success Criteria

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

Key Success Indicators

Level 1: - 100% of AI/HAI endpoint archetypes in the SM-Endpoints inventory have a named baseline hardening status across all five envelope dimensions; no archetype is unclassified. - MDM-enforced AI-tool allowlist active on ≥95% of managed endpoints; DLP tuned for AI-specific exfiltration patterns (regulated-PII paste into LLM, bulk customer-data export via assistant, source-code paste outside approved coding assistant) deployed and active. - SSO + MFA enforced on all AI consoles from managed endpoints; personal-account prohibition active via conditional-access rule; managed-endpoint requirement enforced for Critical-tier AI assistant use. - 100% of customer-facing chatbots and conversational UIs display a compliant EU AI Act Art. 50 AI-interaction disclosure; escalation-to-human routing operational and tested in the ST-Endpoints battery. - 100% of mobile AI apps ship with signed app and signed local model verified at launch; 100% of managed edge AI devices ship with signed firmware and boot-time integrity attestation.

Level 2: - 100% of Critical-tier AI assistant endpoints enforce managed-endpoint requirement at the identity-layer (conditional-access policy); gaps between MDM policy and identity-layer enforcement confirmed closed. - 100% of Critical-tier customer-facing AI endpoints operate under dedicated rate-limit and abuse-detection profiles reviewed quarterly against traffic baselines. - 100% of Critical-tier edge AI devices with HSM-backed attestation and physical-tamper detection; attestation failures route to IM-Endpoints within 5 minutes. - SaaS-admin AI-feature configuration expressed as IaC for Critical and High-tier SaaS-AI; daily drift detection active; tier-hardening matrix published and enforced.

Level 3: - ≥90% of EH-Endpoints 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-Endpoints and IM-Endpoints signal sources; change log machine-readable and traceable. - New AI/HAI endpoint archetypes auto-provisioned with tier-appropriate hardening within 24 hours of SM-Endpoints inventory registration. - ≥2 industry hardening baseline contributions per year (CSA AI Safety Initiative, OWASP MASVS, sector ISACs) with documented adoption.

Common Pitfalls

Level 1: - ❌ MDM AI-tool allowlist deployed but not enforced at the browser level, an employee installs a consumer AI browser extension that is not on the allowlist; the MDM policy blocks app installation but has no visibility into browser extension installs; the extension exfiltrates pasted source code to an unsanctioned AI provider. - ❌ DLP rules tuned for credit-card numbers and SSNs but not for AI-specific patterns, an employee pastes a CSV of 5,000 customer email addresses into a chatbot prompt field; the DLP engine scans for credit-card patterns, not structured bulk-data paste into AI prompt contexts; the exfiltration goes undetected. - ❌ EU AI Act Art. 50 disclosure UX implemented once at launch and never tested again, a chatbot update removes the disclosure step because a sprint team treated it as a bug fix; the regression is discovered when a regulator reviews a complaint six months later. - ❌ Vendor no-train flag accepted at intake based on DPA text and never re-verified, the AI productivity vendor silently updates its data-processing terms to include model training on input data; the no-train commitment is void; regulated data has been flowing to training for 90 days before the annual IR review catches it. - ❌ SaaS-admin AI-feature governance process documented but not enforced, a SaaS admin enables Slack AI tenant-wide on a Friday afternoon without an intake ticket; the feature ingests all Slack channels including those carrying customer PII; it is discovered Monday morning by a data classification alert, not by the governance process. - ❌ Edge AI device firmware signed at manufacture but not verified at boot, tampered firmware is loaded via a physical access event; the device passes the MDM enrollment check because the MDM does not verify firmware signatures at runtime; the tampered device continues to submit poisoned sensor data to the AI pipeline.

Level 2: - ❌ Managed-endpoint requirement for Critical AI assistant use implemented in MDM policy but not at the identity layer, a user on an unmanaged personal device authenticates to the AI assistant using their org SSO credentials (which are not blocked by any conditional-access rule), bypasses the MDM policy, and accesses regulated customer data via the assistant; the MDM policy was a UI control, not an identity control. - ❌ Dedicated rate-limit profiles created for Critical-tier chatbots but the profile table is shared with High-tier, an abuse spike on a High-tier chatbot consumes the shared rate-limit pool and reduces the effective limit on the Critical-tier endpoint below its declared threshold; the tiers are not actually isolated at the rate-limit infrastructure layer. - ❌ HSM-backed attestation declared for Critical-tier edge devices but the attestation service accepts software-signed attestation tokens as a fallback, an attacker presents a software-signed token when the HSM is "unavailable"; the fallback is never removed; the HSM attestation is a UI control with a software bypass. - ❌ SaaS-admin AI IaC implemented for AI-feature enablement flags but not for AI-feature scope settings, the IaC controls whether Copilot is "on" or "off" but not which data scopes it can access; an admin manually expands the data scope to include financial records without triggering a drift detection or an IM finding.

Level 3: - ❌ IaC coverage declared at ≥90% but the registry counts endpoint archetypes that have an IaC stub, not archetypes whose IaC is the authoritative deployed source, drift accumulates between the stub and the live MDM or SaaS admin configuration; the auto-remediation pipeline fires on the stub's expected state, not the real deployed state. - ❌ Adaptive-policy pipeline wired to ML-Endpoints detections but not to IM-Endpoints incidents, post-incident hardening opportunities (a chatbot jailbreak incident that identified a missing output-filter rule) are never converted to tightening proposals. - ❌ Industry hardening baselines contributed but not maintained upstream, internal practice advances (new archetype, new DLP pattern for multi-modal inputs) while the published CSA or OWASP MASVS contribution reflects a 14-month-old state; external adopters find the published version conflicts with advice from the program's engineers. - ❌ Auto-provisioning trigger fires but uses a stale tier assignment from a cached SM-Endpoints record, a Medium-to-Critical tier upgrade is reflected in the inventory but the hardening profile is not updated because the IaC pipeline reads a cached tier field; the archetype runs on Medium-tier baseline controls while classified as Critical. - ❌ Drift auto-remediation for low-risk findings runs without a change log visible to the MDM and SaaS admin 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 endpoint archetype in the SM-Endpoints inventory (AI assistant / copilot on managed endpoint, browser-based AI tool, chatbot / conversational UI, multi-modal AI interface, AI-augmented productivity SaaS-AI, mobile AI app, edge AI device) have a named baseline hardening status across all five envelope dimensions, and are MDM-enforced AI-tool allowlists and DLP rules tuned for AI-specific exfiltration patterns (regulated-PII paste into LLM, bulk customer-data export via assistant, source-code paste outside approved coding assistant) deployed and actively monitored on ≥95% of managed endpoints? 2. Is SSO + MFA enforced on all AI consoles accessed from managed endpoints, with personal-account prohibition active via conditional-access rule and managed-endpoint requirement enforced for Critical-tier AI assistant use, and is vendor no-train flag confirmation documented at intake for all sanctioned AI endpoint tools with an annual recurrent verification schedule? 3. Do 100% of customer-facing chatbots and conversational UIs display a compliant EU AI Act Art. 50 AI-interaction disclosure before or at session start, confirmed by the ST-Endpoints test battery, and do 100% of mobile AI apps and edge AI devices ship with signed apps, signed local models, and signed firmware with boot-time integrity attestation?

Level 2: 1. Is the managed-endpoint requirement for Critical-tier AI assistant use enforced at the identity (conditional-access) layer, not only at the MDM policy layer, so that an unmanaged device cannot authenticate to a Critical-tier AI surface regardless of MDM policy state; and are 100% of Critical-tier customer-facing AI endpoints operating under dedicated (non-shared) rate-limit and abuse-detection profiles reviewed quarterly against traffic baselines? 2. Do 100% of Critical-tier edge AI devices use HSM-backed attestation with physical-tamper detection, with attestation failures routing to IM-Endpoints within 5 minutes and device remote-disable confirmed within 4 hours of unresolved failure, and is the SaaS-admin AI-feature configuration expressed as IaC for Critical and High-tier SaaS-AI with daily drift detection active? 3. Is a tier-hardening matrix published and enforced at provisioning, with all five envelope dimensions calibrated per the SM-Endpoints L2 tier-treatment matrix, and are gaps between required and actual controls tracked as open IM-Endpoints findings with tier-appropriate SLAs?

Level 3: 1. Are ≥90% of EH-Endpoints controls expressed as authoritative IaC (not stubs) in a version-controlled registry, covering MDM AI-tool allowlist, browser policy, SaaS-admin AI-feature configuration, DLP rule set, rate-limit configuration, and edge attestation policy, with drift detected continuously and ≥70% of low-risk drift auto-remediated, and high-risk drift human-reviewed within 2 business days? 2. Is the adaptive-policy pipeline operational, with ML-Endpoints detections and IM-Endpoints incidents generating human-approved policy-tightening proposals on a tracked cadence, every change traceable to a source signal, and downstream endpoint and product teams notified within 24 hours of a tightening change affecting their archetype's hardening profile? 3. Does the program contribute ≥2 AI/HAI endpoint hardening baselines per year to industry bodies (CSA AI Safety Initiative, OWASP MASVS, sector ISACs) with documented adoption, and are new AI/HAI endpoint archetypes auto-provisioned with their tier-appropriate hardening profile within 24 hours of SM-Endpoints inventory registration?

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